Head First EJB

Make a new Application

The RI is a J2EE server, remember, not just an EJB container. So we have to do a small bit of J2EEish stuff before we can make the ejb-jar and deploy the app. This step is where we create a new J2EE application, and for now, you can think of the J2EE application as something that wraps the beans and adds a little more information for the server. The main difference between a J2EE application and an EJB application is that a J2EE application can include web components (servlets and JSPs) as well as EJB components, all integrated as part of a single app.

Choose File ▸ New ▸ Application

There are no Dumb Questions

Q:

Q: Does this mean that I MUST have a J2EE server if I want to use servlets and EJBs together?

A:

A: No. With a J2EE server, the web components and EJB components are more tightly integrated, which means you can have all of the components respect one another’s transactions and security. But you’re always free to use a servlet as a client to an enterprise bean, even if that bean isn’t running in the same application server (or even the same physical machine). Another advantage of a J2EE server is the ease with which you can deploy both component types as part of one enterprise application. Having said all this, chances are extremely high that if you’re doing EJB 2.0 applications, you are running them in a J2EE server. Remember, there are very few standalone EJB containers today. Virtually all significant vendors run their EJB containers within a J2EE server.

Off the path

A J2EE server vendor must pass a massive pile of compatibility tests before the server can be called “J2EE-compliant”. A J2EE 1.3 server, for example, must include an EJB 2.0 container, and that container must implement the EJB 2.0 specification.