When you build a simple Java class, you need a Java Virtual Machine (JVM) to execute it. In a similar way (as you learned in the previous section) to execute session beans and MDBs you need an EJB container, and to run your entities you need a persistence provider. In this section we give you a bird’s-eye view of containers and persistence providers and explain how they are related.
In the Java world, containers aren’t just limited to the realm of EJB 3. You’re probably familiar with a web container, which allows you to run web-based applications using Java technologies such as servlets, JSP, or JSF. A Java EE container is an application server solution that supports EJB 3, a web container, and other Java EE APIs and services. BEA WebLogic Server, Sun Microsystems’s GlassFish, IBM WebSphere, JBoss Application Server, and Oracle Application Server 10g are examples of Java EE containers. The relationship between the Java EE container, web container, EJB container, and JPA persistence provider is shown in figure 1.7.
If you install a Java EE-compliant application server such as GlassFish, it will contain a preconfigured web container, EJB container, and a JPA provider. However, some vendors and open source projects may provide only a web container such as Tomcat or an EJB 3-compliant persistence provider such as Hibernate. These containers provide limited functionality compared to what you get with a complete Java EE 5 container.
In this section, we’ll focus on how the EJB container and the persistence provider work, and we’ll finish with a more complete discussion of EJB services. First, let’s tackle the EJB container.
Figure 1.7 Java EE container typically contains web and EJB containers and a persistence provider. The stateless session bean (Credit Check EJB) and stateful session bean (Cart EJB) are deployed and run in the EJB container. Entities (Customer and Catalog) are deployed and run within an EJB persistence provider and can be accessed by either web or EJB container components.
Accessing EJB services: the EJB container
Think of the container as simply an extension of the basic idea of a JVM. Just as the JVM transparently manages memory on your behalf, the container transparently provides EJB component services such as transactions, security management, remoting, and web services support. As a matter of fact, you might even think of the container as a JVM on steroids, whose purpose is to execute EJBs. In EJB 3, the container provides services applicable to session beans and MDBs only. The task of putting an EJB 3 component inside a container is called deployment. Once an EJB is successfully deployed in a container, it can be used in your applications.
The persistence provider is the container counterpart in JPA. We’ll briefly talk about it next.
Accessing JPA services: the persistence provider
In section 1.2.3, we mentioned that the persistence provider’s job is to provide standardized JPA services. Let’s explore how it does that. Instead of following the JVM-like container model, JPA follows a model similar to APIs, like JDBC. JPA provides persistence services such as retrieving, adding, modifying, and deleting JPA entities when you explicitly ask for them by invoking EntityManager API methods.
The "provider" terminology comes from APIs such as JDBC and JNDI too. If you’ve worked with JDBC, you know that a "provider" is essentially the vendor implementation that the JDBC API uses under the covers. Products that provide JPA implementation are persistence providers or persistence engines. JBoss Hibernate and Oracle TopLink are two popular JPA providers.
Since JPA is completely pluggable and separable, the persistence provider and container in an EJB 3 solution need not come from the same vendor. For example, you could use Hibernate inside a BEA WebLogic container if it suits you better, instead of the Kodo implementation WebLogic ships with.
But without services, what good are containers? In the next section, we explore the services concept critical to EJB.
Gaining functionality with EJB services
The first thing that should cross your mind while evaluating any technology is what it really gives you. What’s so special about EJB? Beyond a presentation-layer technology like JSP, JSF, or Struts, couldn’t you create your web application using just the Java language and maybe some APIs like JDBC for database access? The plain answer is that you could—if deadlines and cutthroat competition were not realities. Indeed, before anyone dreamed up EJB this is exactly what people did. What the resulting long hours proved is that you tend to spend a lot of time solving very common system-level problems instead of focusing on the real business solution. These bitter experiences emphasized the fact that there are common solutions that can be reused to solve common development problems. This is exactly what EJB brings to the table.
EJB is a collection of "canned" solutions to common server application development problems as well as a roadmap to common server component patterns. These "canned" solutions, or services, are provided by either the EJB container or the persistence provider. To access those services, you build the application components and deploy them into the container. Most of this topic will be spent explaining how you can exploit EJB services.
In this section, we briefly introduce some of the services EJB offers. Obviously, we can’t explain the implementation details of each service in this section. Neither is it necessary to cover every service EJB offers right now. Instead, we briefly list the major EJB 3 services in table 1.1 and explain what they mean to you from a practical perspective. This topic shows you how to use each of the services shown in table 1.1 in your application.
Despite its robust features, one of the biggest beefs people had with EJB 2 was that it was too complex. It was clear that EJB 3 had to make development as simple as possible instead of just continuing to add additional features or services. If you have worked with EJB 2 or have simply heard or read that it is complex, you should be curious as to what makes EJB 3 different. Let’s take a closer look.
Table 1.1 Major EJB 3 component services and why they are important to you. The persistence services are provided by the JPA provider.
|
Service |
Applies To |
What It Means for You |
|
Integration |
Session beans and MDBs |
Helps glue together components, ideally through simple configuration instead of code. In EJB 3, this is done through dependency injection (DI) as well as lookup. |
|
Pooling |
Stateless session beans, MDBs |
For each EJB component, the EJB platform creates a pool of component instances that are shared by clients. At any point in time, each pooled instance is only allowed to be used by a single client. As soon as an instance is finished servicing a client, it is returned to the pool for reuse instead of being frivolously discarded for the garbage collector to reclaim. |
|
Thread-safety |
Session beans and MDBs |
EJB makes all components thread-safe and highly performant in ways that are completely invisible. This means that you can write your server components as if you were developing a single-threaded desktop application. It doesn’t matter how complex the component itself is; EJB will make sure it is thread-safe. |
|
State management |
Stateful session beans |
The EJB container manages state transparently for stateful components instead of having you write verbose and error-prone code for state management. This means that you can maintain state in instance variables as if you were developing a desktop application. EJB takes care of all the details of session maintenance behind the scenes. |
|
Messaging |
MDBs |
EJB 3 allows you to write messaging-aware components without having to deal with a lot of the mechanical details of the Java Messaging Service (JMS) API. |
|
Transactions |
Session beans and MDB |
EJB supports declarative transaction management that helps you add transactional behavior to components using simple configuration instead of code. In effect, you can designate any component method to be transactional. If the method completes normally, EJB commits the transaction and makes the data changes made by the method permanent. Otherwise the transaction is rolled back. |
|
Security |
Session beans |
EJB supports integration with the Java Authentication and Authorization Service (JAAS) API, so it is very easy to completely externalize security and secure an application using simple configuration instead of cluttering up your application with security code. |
|
Interceptors |
Session beans and MDBs |
EJB 3 introduces AOP in a very lightweight, accessible manner using interceptors. This allows you to easily separate out crosscutting concerns such as logging, auditing, and so on in a configurable way. |
|
Remote access |
Session beans |
In EJB 3, you can make components remotely accessible without writing any code. In addition, EJB 3 enables client code to access remote components as if they were local components using DI. |
