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?
Is it an option to consider alternatives to the EJB protocol? Web services - XML over HTTP - are great for "lowest common denominator" communications with a variety of other platforms.
Another option is to expose exactly one method on one EJB to the world, and marshall and unmarshall your own payload. The one method can be extremely stable, never changing. You can parse the payload for what function the client wants to run and what version they are running. It's a lot like re-inventing the remote procedure call.
Distributing versions of classes for parameters and return values to clients is just going to be tricky. I'm going to sit back and see what others recommend there.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi