I could do with some pointers on how to best handle a multi-client EJB3 setup on one instance of JBoss 5.1.0.GA (possible migration to AS7 in the future). I use the @annotations to handle as much as possible, so i only usually define the interfaces & persistence layers.
Before i go head first into some kind of development, i want a clean, secular deployment plan that saves wasting time or server resources.
An example of my requirements:
- Several clients pushing data through our service constantly with web methods like "submitThis", "updateThat" - each giving synchronous responses about the operation results (db errors or data validation failures).
- Each client has slightly different requirements - some just want the "submitThis" method, others want "updateThat" too, and more.
- They also have their own build cycles, testing plans etc. which makes implementation on our side very specific. i.e. client1 might decide they now want "updateThat" two weeks after i implemented it for client2. Then, client3 might decide they want a new element "aString" on the "submitThis" method due to a process enhancement, which wasn't part of the original spec for any of them. So we have to keep the interfaces client specific for potential enhancements (we are the service provider in very flexible setup, and don't have much grounds for "take it or leave it")
- Our data is seperated at the highest level by the source client itself
- We want all interfaces to call on common methods for the database operations (even though their data set may vary, i think this can be handled in the common persistence layer) i.e. "submitThis" for client3 has one extra element, so the persistence layer will make that element null for the other clients during the db operations. Our data model dictates our interfaces but only when the client is effected
The only way i can think of achieving this is through seperate applications for each client, but i would like to know if its possible to maintain a single persistence layer with (n) methods and expose that to (x) applications (each with its own contextRoot & set of endpoints), so they can persist the data through a common channel which only changes with the data model.
Thanks for reading.