• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Webservice for different applications

 
Ranch Hand
Posts: 279
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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,



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
 
Ranch Hand
Posts: 2198
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

 
Right! We're on it! Let's get to work tiny ad!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic