advantages of multiple endpoints but same shared service

[Mohit Sinha]

Hi All,

I have a single web service (SOAP/WSDL) with several operations which caters to two distinct types of audience. I was thinking of having separate endpoints based on audience type to group them by logical function.
I haven't tried the multiple endpoints for a single service approach before and wanted to understand if there are any up/down sides to this from a security, availability, contention of resources standpoint.

Let know your thoughts.

Regards,

[Hikari Shidou]

Did you create your WebServide with Axis2 from a java class?

If you did so, you'd need to develop 2 distinct classes for each endpoint. You could make original class a singleton and make both classes use its instance to dispatch their operations to it, so that you don't need to handle implementated codes again.

If they be on the same Eclipse project, they can run as a unique "process", therefore sharing resources (the singleton object). What would differ from current solution would be only those 2 classes, and that's it. Both WebServices would share /services/ and be listed in it together with the Version service, but have distinct WSDL. I don't know how their endpoints would look like, but for sure they'd be distinct WebServices with their own operations. By having both original classes consuming original one, it'd be easy also to have them sharing a operation...

Now, if you wanna deploy each WebService separatedly, each on its own Eclipse project and its own war, this may be challenging. They won't be able (at least not easily) to share resources, so you'd need to make changes on current software architeture. Either each of them have a full and independant and complete Application Server instance (and those 2 share a DBMS for example), or you'd need to have Application Server on another layer and have them both sendind RPCs to it. Not recommended at all since all you want is 2 WebServices with separated operations.

[Mohit Sinha]

Thanks Hikari. I am following contract-first web service development approach.
My thought was to generate the java binding classes from the respective WSDL's and then channelize the web service call from the generated (controlling Impl) classes to the singleton domain logic class (which represents common functionality for both web services). From the domain logic class point onward the functionality is 95% common between the two services. For the remaining 5% there is dynamism in the code to handle it. Even the underlying database is common for both services.

Another reason to go the multiple endpoints route is to spawn and bundle separate war files if the need ever arose without having to later restructure the application project heavily. Below you seem to suggest this can't be achieved easily. Contention is one of the concerns of the future I foresee requiring us to have the option of creating and bundling separate war files easily available. If the demand for one of the web service goes through the roof we don't want the second web service to be impacted in any manner.

Let know your thoughts if there are best practices to deal with such situations.

[Hikari Shidou]

Nothing stops you from deploying the same war in different servers.

The easiest approach I see is having Application Logic developed separately and deployed to your WebService project as a consumable jar. Testing during development sucks in Java for web development, I try to avoid it as much as possible.

The only disadvantage I see in having all operations in a unique WebService is aesthetical. But as I said, in the same eclipse project, you could (at least I think, never tried) create 2 classes that dispatch each operation to Application Logic (it could have a broker) and share some operations, and create a WebService from each of these classes.

Since you have to identify who's consuming your WebService, I suppose you already have authentication and permissions controls, it's better to use them instead of adding complexity to the project. You could create a xml config file and set which roles are allowed to access your WebService, and use your permissions control together with this config to deny access. With that you only need to deploy the same war file to as many servers as you want and set this config, therefore reserving some servers to specific roles.

You also could make your current WebService internal and block it from outside IPs, and create 2 new projects with WebServices that serve outsiders and consume this internal WebService. But that's also extra complexity and performance I'd avoid.

As there are WebSites with pages that return 403, and WebApps with pages that are unaccessible (like backend admin pages), there's nothing wrong having WebServices with operations with limited access. Just handle permissions control and return some access denied exception and some message explaining a) why access was denied, b) who to contact to talk about it and ask for access permissions and more details, c) explicitly saying that other operations should still work.

Your issue is more of a permissions control issue than WebService issue. Imagine if you have 6 roles, would you create 6 WebServices/projects just so that each of them see only their available operations? In WebSites and WebApps it's easy to build menus and links based on roles, but for WebService it's not that easy to hide unaccessible operations.

Also, if your software may require multiple servers, you should seriously think Stateless during its development. It's damn hard to handle multiple servers and balancement while handling sates/sessions/etc that are stored in one server and are needed on another.