EJB on the client

Question

I need to develop an application in java, which uses a client[embedded server]-server-(-server)-(...) approach. (data sent on commits, or automaticly)

The workflow (entities, validation, logic, sessions) is everywhere the same. In server-server connections, it looks logical to use EJB-s (entity and session beans, in the future probably message driven beans also). The client speaks with a local "server", or - based on user settings - to one or more real server (servers may speak to many servers too).

Is it possible (and: simple) to use locally the EJB framework (without a local J2EE server running, to avoid installation on the clients, and memory usage), and if, is it considered a good solution? Or should I implement a different logic on the client, and switch based on the settings? Which is easier?

Answer 1

Yes, it is possible. The EJB 3.1 spec defines an embeddable EJB container (Chapter 20) that can be used in Java SE applications without the need of an Java EE application server.

But even prior to EJB 3.1 there are containers that are easily embeddable, e.g. OpenEJB from Apache.

Whether this is good or bad is of course debatable but I think if there are existing EJBs and you want to use them locally then why not. Others would probably prefer Spring but I don't have much experience in it so I can't comment on that.

Answer 2

It is perfectly possible to call your EJB's from a client without having a J2EE server locally.

All JEE servers come with a client jar which contains the needed classes to connect to the J2EE server. You need to provide the configuration for the JNDI server using a jndi.properties file (or setting System properties before getting your initial JNDI context) and that's all.

I think the original spec was made with client/server environments as a target and it ended up by accident in the n-tier web apps.

If you really need to deploy on the local machine you might consider deploying your application IN a JEE server. A JBoss or Glassfish are quite modular and they are not that heavy to run. Throw out the modules you do not need and deploy your app on it.