Working with the EJB Container

Invoking an EJB

One part of interacting with an application server is invoking the Servlets and Java Server Pages (JSPs) that reside inside of the Web container. The other half of the puzzle is interacting with Enterprise Java Beans. This article will deal with the basics of how EJBs are located, the protocol used to access them, and how methods are invoked on them.

To call an EJB, especially one residing on an application server in a galaxy far, far away, we must first connect to the naming service of that remote application server. 

(Note that not all EJB invocations will be to remote components, but since one of the main ideas behind EJBs was to make remote method invocations fairly simple, it’s a pretty good scenario to use for demonstration.)

The naming service is like a gatekeeper for objects running on a server. If someone wants access to a remote EJB, they call on the gatekeeper and ask if an EJB named “com/mcnz/UserEJB” is around. If there is indeed an EJB with that name running around the server, you’re in luck; if not, you get an exception.

So, to call an EJB, we first connect to the EJB’s naming service and ask if it’s Home. If it is, we get a handle to that EJB and can call its methods, just as though it were a regular JavaBean.
So, what will do with this remote EJB? Well, probably tell it what the user typed into text fields that appeared on the user's page. The EJB can then add that information to a message queue, or if it is an Entity Bean, the data might even get saved to a database. The world is your oyster when you’re using EJBs.

As mentioned, EJBs are good at adding data to a queue, persisting data to a database, or even coordinating various complex operations. In line with this thinking, there are three basic types of Enterprise Java Beans, namely, Message Driven Beans (MDBs), Persistent Objects (which have often been referred to in the past as Entity Beans) and of course, Session Beans which are excellent at simply processing data or even being converted into remotely invocable Web services.

Switching Protocols

Now you may not have noticed the little sleight of hand that was played on you there, but there was a switch of protocols when you weren’t looking.

When the client request is routed from the client to the Web server, http/https is the protocol that is used. When the Web server forwards to the Web container of the application server, the protocol remains http/https.

However, when a request is made from the Servlet engine to the EJB container, the protocol switches from http to RMI over IIOP (Remote Method Invocation over the Internet Inter-Orb Protocol). In fact, any remote invocation for an EJB, whether it is from a Servlet or from another EJB or even a standalone client running with an EJB enhanced container, will use RMI over IIOP.

Don’t worry, the whole protocol switch happens behind the scenes, so we don’t have to worry about it in our code, but it is empowering to know what is going on under the covers.

With older implementations of the enterprise Java specification, a home interface create or find method would provide a remote interface upon which the actual methods of the remote EJB would be invoked. While many implementations in existence still use this version of the implementation, this added complexity is no longer needed in Java EE, and the home and remote interface vernacular is no longer needed.

From the Web Container, Back to the Web Server

When a component such as a Servlet or JSP is finished invoking the various methods of the EJB, control is returned from the EJB and back to that component. In our original scenario, we had a Servlet invoking the EJB.

Once a Servlet is done interacting with the EJBs, JavaBeans or other Java components that might help the Servlet implement control logic, it then figures that it has to send some response back to the client. After all, the client always likes to see a Web page that lets them know that everything is working the way it should.

Servlets themselves don’t generate HTML to display to the client. Well, they can, but again, they’re not supposed to. Instead, they forward to a JSP.

The JSP then runs, and when it’s done running, it forwards all of the html it has generated back to the Web server. The Web server then forwards the html back to the client along with any images or other files the html page might need to display properly.

And that’s it, a simple roundtrip for our enterprise application as it leverages the two most important parts of the enterprise Java application server: the Web container and the EJB container.