When to prefer EJB over GWT Servlet

Question

My colleague said me that using local EJB isn't good idea, because they act as classes packaged inside JAR (i.e. when EJB used only aslocal they don't have any advantages over normal classes). And I must use EJB only when some piece of code potentially can be used by several applications. But I read about more advantages of EJB (security, thread-safety, trasanctions etc).

So I confused: when to use GWT Servlet (it more convenient than simple HTTPServlet, it offers RPC-style method invocation) and when to use EJB?

P.S. I don't use any futures like JPA 2.0, CDI etc (because I can use only Java EE 5 on WAS 7).

Answer 1

My colleague said me that using local EJB isn't good idea

I strongly disagree with that. Local EJBs are a very good idea, as they are the perfect type of bean for implementing your business logic. The current crop of EJB beans is very light weight so you don't have to avoid them because of any alleged heavyweightness.

The biggest advantage of these types of beans are probably their automatic transaction management, which will come in great use when doing any kind of database work.

It's not just about enterprise applications needing to access JMS queues and complicated EIS systems. Any web application doing more than one write to the database at a time greatly benefits from this. Without transactions, you'll end up with say a User that's only halfway persisted in the database whenever an exception or crash happens. And without EJB you'll have to litter your code with tons of very verbose start\commit\rollback statements, let alone propagate your transaction (typically via a 'Connection') into all your code and have separate cases for when a transaction is or isn't active.

With EJB beans, all that complexity just goes away. It's like garbage collection vs manual memory management.

There are tons of other interesting features that even the simplest of web applications can make use of, like declarative role checking (@RolesAllowed), pooling of beans (to throttle throughput, among others) and thread-safety.

In Java EE 6 they did became easier to use for simple web applications, and there they can appear everywhere in a .war (no separate .jar and umbrella .ear needed anymore).

So I'm confused: when to use GWT Servlet (it's more convenient than a simple HTTPServlet, it offers RPC-style method invocation) and when to use EJB?

So now we're talking about remote EJB. In this case the answer is different.

If clients are connecting from the Internet, you'll almost never use remote EJBs. There are a great number of ports that typically need to be open, including ports on the client.

Likewise, if you have heterogeneous clients (.NET, C++, and even Java clients running a slightly different version of the AS that the remote EJB uses) you will typically not use remote EJBs.

Although theoretically supporting Corba (IIOP) and thus allowing different types of clients, in practice remote EJB communication only works if both client and server are running Java and are either the except same AS (Application Server) or one of them is a Java SE client with the client libraries for the remote server (which can be huge).

It's a bit awkward for a remoting technology, but the EJB spec doesn't even specify how to set up a remote connection in the first place. The de facto standard is remote JNDI, but since this is not the spec, JBoss e.g. wanted to stop supporting this in JBoss AS 7.

In all those cases, you would use a Web Service technology instead of remote EJB. GWT Servlet might be an option, but is not really a canonical example here. Unless you are already using GWT, I would not recommend installing it just for general web/rpc connectivity from arbitrary (non-GWT) clients.

General Java solutions are JAX-WS and JAX-RS, which are a SOAP resp REST implementation (both can be combined with EJB btw). Well known JAX-RS implementations are Jersey (example) and RestEasy. In Java EE 6 you don't have to install anything for them, as they are already part of the platform. For Java EE 5, you have to install JAX-RS separately, but JAX-WS is already there.

People typically find JAX-RS easier to start with and the more modern approach, although JAX-WS has more build-in type-safety features (which is also exactly where most of its complexity comes from).

Finally, when do we use remote EJB? Typically, you would do this for communication between applications on a local network running the same AS. In that case, there are potential performance advantages (binary serialization can be faster than json/xml conversion hence and forth) and there are some powerful options for propagating a security context and coordinating a distributed transaction. Simple web apps will most likely not require the last feature often if at all.

An often seen pattern is that of a JAX-RS resource (bean) that accepts requests from remote (web) clients, and then delegates the work to a local EJB that contains the actual business logic.

Answer 2

EJB is a technology used in the back-end on its own container and gives some features like transactions security etc which are transparent to the developer.

from the Java EE tutorial:

You should consider using enterprise beans if your application has any of the following requirements:

The application must be scalable. To accommodate a growing number of users, you may need to distribute an application’s components across multiple machines. Not only can the enterprise beans of an application run on different machines, but also their location will remain transparent to the clients.

Transactions must ensure data integrity. Enterprise beans support transactions, the mechanisms that manage the concurrent access of shared objects.

The application will have a variety of clients. With only a few lines of code, remote clients can easily locate enterprise beans. These clients can be thin, various, and numerous.

Now, when you are doing only Web development in a single Web server, EJBs will not really help you and there are other easier options like GWT Servlet for example.

However if you want to use managed transactions, connect to JMS queues or do some batch processing in the background then EJB come to play.

For example you got an order and you need to communicate with different departments to fulfill the order. In this case you will need a background process that will do the work while the front-end informs the customer that the order is being prepared. The servlet can send the order to a queue where a Message driven bean can pick it up and do some processing by calling other EJBs.