• Post Reply Bookmark Topic Watch Topic
  • New Topic

Designing EJB public service (best practice)?

 
Peter Storch
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Peter Storch
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
... Web services - XML over HTTP ...

Yes we thought about it, but it feels a little bit strange for company internal java only services.

Originally posted by Stan James:
... re-inventing the remote procedure call...

yes, that is where you end up. So what's ejb good for if not for distributed common services?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Excellent question. We're using EJB call from servlet layer to EJB layer. That has potential for load balancing in a 6 server cluster, gets us transaction management, pooled datasource connections.

EJB is good for remote calls, but has the problems you mentioned. The single-method gateway is one approach to minimize the client side coupling, but comes with its own costs.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!