Hi there,
we are looking for best practices to design public services with EJBs.
With public service we meen one enterprise application is useing one or more EJBs from other enterprise applications. In the same container or another.
The biggest problems we face are:
1) loose coupling (how to get as few dependencies as possible?)
2) backward compatibility (how to keep the clients stable if the service is updated?)
Is there a (good) way to call an
EJB of another enterprise application without the need to have .class files of the other app?
If it is necessary, how can these classes be build that you don't run into class loader issues? Especially if you want to upgrade the public service without updating its clients.
We thought of designing a public service EJB with just an execute() method with a HashMap (with basic data types and java.lang.* Objects only) as input and output. But is this really a good design? Does it really solve the dependency problems we have?
We first tried it the "normal" way. Just define your stateless session bean. Build a .jar file for your service users and deploy your and the other enterprise applications in the same appserver. Then we got more and more applications using more and more services between each other (dependencies!).
Then it comes the time that one service or some utility classes which where used by the service needs to be upgraded (e.g. for bug fixing or further improvement).
Then we face the need to upgrade "all" other applications to solve class loading issues even if the service interface didn't change.
And if the different enterprise applications were built by different projects with separate budgets it's even more difficult to say: hey you have to update your app because we updated our app. Even if they don't get more features they have to update, regression
test, redeploy there applications. That means spend money for nothing.
Are there solutions to these problems? Can you point me to resources to get more information?
Thanks!