Webservice for different applications

[Anjali S Sharma]

I need to create a Webservice which will be used by various applications.
One of the parameters which the consumers will pass will be the consumer application name. Example, If "A" is the consumer then it'll pass a parameter to the webservice as "A". If "B" is the consumer then it'll pass a parameter to the webservice as "B". Then the webservice, based on application name passed as parameter will execute some business logic. This business logic could be different or same for different consumers. Say, Consumer A and B share the same business logic. But consumer C has completely different business logic. One way to do this is to put if/else conditions in the webservice,

    
 if (app_name == A OR B) 
execute this 
else if (app_name ==c) 
execute this

But the problem with this approach is that when a new consumer comes, I'll have to redeploy the service and also test the webservice for existing applications since the webservice code has changed. So I want to make it kind of generic. Adding a consumer should not change the webservice code.
Please let me know how this can be done.
Thank you

[Ivan Krizsan]

Hi!
First of all, it sounds like a document-based web service with different namespaces for each client type would be a good choice for you. However, and this is quite a substantial "however", your wish not to have to redeploy the web service after having added a handler for a new client requires measures outside the regular web service realm.
As far as I know, there are two choices:
- OSGi
You may want to implement a plugin architecture that uses OSGi to allow plugins to be added and discovered dynamically at runtime.
- Dynamic scripts, for instance Groovy.
Spring has support for implementing Spring beans in Groovy in a script file. Spring can also be configured to periodically check the script file for updates and if an update is discovered, reload the script file.
You could still implement a plugin architecture with the plugins residing in regular JAR files. In order to activate a plugin, you would have to register it in some way in the Groovy script file. Spring would then discover that the file has changed and the plugin configuration would be reloaded.

I've been rather brief, so do not hesitate if there are any additional questions!
Best wishes!

[Stu Quinn]

Just a couple ideas...

If the business logic is closely tied to returning data for the customer perhaps you could manage an underlying meta-data table with the name of the customer and a corresponding piece of SQL, perhaps a stored procedure, to be executed and provide the return value(s). Fetch the sql based upon the customer name, execute and return the result.

Another alternative would be to dynamically create an instance of a class specific to the customer. The class name would incorporate the customer name. You could adopt a command pattern and have each of these classes expose and execute method. If a new customer comes along you can create a new class, easily unit test it, and drop the jar in the /lib.

You may choose to combine these approaches as well.