Overview

Enterprise Java Beans (EJB) technology is part of a larger framework-- the Java 2 Platform, Enterprise Edition (J2EE). This platform is an architecture for developing, deploying, and executing applications in a distributed environment. These applications require system-level services, such as transaction management, security, client connectivity, and database access. The J2EE platform provides these services, allowing you to focus on the business logic in your applications, not the system-level plumbing. You code the business logic in enterprise beans, reusable components that can be accessed by client programs. Enterprise beans run on a J2EE server, which functions as a middle-tier server in a three-tier client/server system.

A middle-tier server plays a vital role in a three-tier application. It handles requests from clients, shielding them from the complexity involved in dealing with back office systems and databases. The middle-tier server might support a variety of clients, such as Web browsers, Java applications, and hand held devices. The clients handle the user interface. They do not query databases, execute complex business rules or connect to legacy applications. They let the middle-tier server do these jobs for them transparently. Figure 1-1 illustrates a three-tier application. Tier 1 is composed of multiple clients, which request services from the middle-tier server in tier 2. The middle-tier server accesses data from the existing systems in tier 3, applies business rules to the data, and returns the results to the clients in tier 1.

FIGURE 1-1 A Three-Tier Client/Server Application

Middle-tier servers also provide system-level services:

• Remote access to clients and back-office systems
  
• Session and transaction management
  
• Security enforcement
  
• Resource pooling
  

Since the middle-tier provides these services, the clients can be thin, simple, and rapidly developed. You can integrate new clients with existing applications and databases, protecting your investment in legacy systems. Middle-tier servers enable you to create large-scale distributed applications for the enterprise. The architecture of the J2EE platform makes it the ideal choice for developing middle-tier servers.

J2EE Architecture

FIGURE 1-2 J2EE Architecture

J2EE Server

• Naming and Directory - allows programs to locate services and components through the Java Naming and Directory Interface (JNDI) API
  
  
• Authentication - enforces security by requiring users to log in
  
  
• HTTP - enables Web browsers to access servlets and Java Server Pages (JSP) files
  
  
• EJB - allows clients to invoke methods on enterprise beans
  
  

EJB Container

• Transaction Management
  
  
• Security
  
  
• Remote Client Connectivity
  
  
• Life Cycle Management
  
  
• Database Connection Pooling
  
  

Transaction Management

The container permits only authorized clients to invoke an enterprise bean's methods. Each client belongs to a particular role and each role is permitted to invoke certain methods. You declare the roles and the methods they may invoke in the enterprise bean's deployment descriptor. Due to  this declarative approach, you need  not code routines that enforce security.

An enterprise bean passes through several states during its lifetime. The container creates the enterprise bean, moves it between a pool of available instances and the active state and finally removes it. Although the client calls methods to create and remove an enterprise bean, the container performs these tasks behind the scenes.

The Web container is a runtime environment for JSP files and and servlets. Although these web components are an important part of a J2EE application, this manual focuses on enterprise beans. For more information on developing web components, see the home pages for the Java Server Pages and Java Servlet technologies.

There are two types of enterprise beans: session beans and entity beans.

A session bean represents a client in the J2EE server. A client communicates with the J2EE server by invoking the methods that belong to an enterprise bean. For example, an online shopping client might invoke the enter Order method of its session bean to create an order. A session bean converses with the client, and can be thought of as an extension of the client. Each session bean can have only one client. When the client terminates, its corresponding session bean also terminates. Therefore, a session bean is transient, or non-persistent.

An entity bean represents a business object in a persistent storage mechanism such as a database. For example, an entity bean could represent a customer, which might be stored as a row in the customer table of a relational database. An entity bean's information does not have to be stored in a relational database. It could be stored in an object database, a legacy application, a file, or some other storage mechanism. The type of storage mechanism depends on the particular implementation of EJB technology. The reference implementation (J2EE SDK) uses a relational database. See the section "Database Access"for more information.

The persistence of an entity bean can be managed by either the entity bean itself, or by the EJB container. Bean-managed persistence requires you to write the data access code in the Bean. For example, a customer entity bean would include the SQL commands to access a relational database via JDBC. Container-managed persistence means that the EJB container handles the data access calls automatically.

Comparing Session and Entity Beans

Although both sesion and entity beans run in an EJB container, they are quite different. The following table contrasts session and entity beans:

TABLE 1-1 Differences Between Session and Entity Beans

	Session Bean	Entity Bean
Purpose	Performs a task for a client.	Represents a business entity object that exists in persistent storage.
Shared Access	May have one client.	May be shared by multiple clients.
Persistence	Not persistent. When the client terminates its session bean is no longer available.	Persistent. Even when the EJB container terminates, the entity state remains in a database.

The flexibility of the EJB architecture allows you to build applications in a variety of ways. The following illustration shows how you might create an online shopping application with both session and entity beans. An HTML form displayed in a Web browser accesses a servlet in a Web container. The servlet is the client of a shopping session bean. When the HTML form needs to find a product or enter an order, it instructs the servlet to call the appropriate business methods in the session bean. The session bean is the client of the order, product, and customer entity beans. Because entity beans are persistent, their state is stored in the database.

FIGURE 1-3 Using Session and Entity Beans

Java Beans Components and Enterprise Beans

JavaBeans components and enterprise beans are not the same. Although both components are written in the Java programming language, they are not interchangeable. JavaBeans components define a convention for making a Java class instance customizable by design tools, allowing the tools to link these customized objects via events. Enterprise beans implement multi-user, transactional services.

Enterprise beans make use of the services provided by the EJB container, such as life-cycle management. To avoid conflicts with these services, enterprise beans are restricted from performing certain operations:

• Managing or synchronizing threads
  
• Accessing files or directories with the java.iopackage
  
• Using AWT functionality to display information or to accept information from a keyboard
  
• Listening on a socket, accepting connections on a socket, or using a socket for multicast
  
• Setting a socket factory used by ServerSocket, Socket, or the stream handler factory used by the URLclass
  
• Loading a native library
  

Database Access

The Enterprise JavaBeans specification does not require an implementation to support a particular type of database. Therefore, the databases supported by different J2EE implementations may vary. See the Release Notes for a list of the databases currently supported by the J2EE SDK. Both session and entity beans can access a database. The type of enterprise bean you choose depends on your application. You might want to include SQL calls in a session bean under the following circumstances:

• The application is relatively simple.
  
• The data returned by the SQL call will not be used by multiple clients.
  
• The data does not represent a business entity.
  

You should probably access a database from an entity bean if any of the following conditions are true:

• More than one client will use the data returned by the database call.
  
• The data represents a business entity.
  
• You want to hide the relational model from the session bean.
  

J2EE Applications

You assemble a J2EE application from three kinds of modules: enterprise beans, Web components, and J2EE application clients. These modules are reusable-- you can build new applications from existing enterprise beans and components. And because the modules are portable, the application they comprise will run on any J2EE server that conforms to the specifications.

Figure 1-4 shows the hierarchy of a J2EE application. A J2EE application may contain one or more enterprise beans, Web components, or J2EE application client components. An enterprise bean is composed of three class files-- the EJB class, the remote interface, and the home interface. (The next chapter discusses these class files in more detail.) A Web component may contain files of the following types: servlet class, JSP, HTML, and GIF. A J2EE application client is a Java application that runs in an environment (container) which allows it to access J2EE services.

Each J2EE application, Web component, enterprise bean, and J2EE application client has a deployment descriptor. (Figure 1-4 abbreviates a deployment descriptor as DD.) A deployment descriptor is an .xml file that describes the component. An EJB deployment descriptor, for example, declares transaction attributes and security authorizations for an enterprise bean. Because this information is declarative, it can be changed without requiring modifications to the bean's source code. At run time, the J2EE server reads this information and acts upon the bean accordingly.

FIGURE 1-4 Contents of a J2EE Application

You bundle each module into a file with a particular format-- a J2EE application in a .ear file, an enterprise bean in an EJB .jar file, a Web component in a .war file, and a J2EE application client in a .jar file. An .ear file, for example, contains an .xml file for its deployment descriptor, and one or more EJB .jar and .war files. An EJB .jar contains its deployment descriptor and the .class files for the enterprise bean. The following table lists the file type of every element residing in a J2EE application.

TABLE 1-2 Files Used in a J2EE Application

Element	File Type
J2EE Application	.ear
J2EE Application Deployment Descriptor	.xml
Enterprise Bean	ejb .jar
EJB Deployment Descriptor	.xml
EJB Class	.class
Remote Interface	.class
Home Interface	.class
Web Component	.war
Web Component Deployment Descriptor	.xml
JSP File	.jsp
Servlet Class	.class
GIF File	.gif
HTML File	.html
J2EE Application Client	.jar
J2EE Application Client Deployment Descriptor	.xml
Java Application	.class

Development Phases of J2EE Applications

As a J2EE application evolves, it passes through these development phases:

• Enterprise Bean Creation
• Web Component Creation
• J2EE Application Client Creation
• J2EE Application Assembly
• J2EE Application Deployment

In a large organization, each phase might be executed by different individuals or teams. This division of labor works because each of the earlier phases outputs a portable file that is the input for a subsequent phase. For example, in the Enterprise Bean Creation phase, a software developer delivers EJB .jar files. In the J2EE Application phase, another developer combines these EJB .jar files into a J2EE application and saves it in an .ear file. In the final phase, J2EE Application Deployment, a system administrator at the customer site uses the .ear file to install the J2EE application into a J2EE server. Figure 1-5 illustrates these last two phases. The different phases are not always executed by different people. If you work for a small company, for example, or if you are protyping a sample application, you might peform the tasks in every phase.

FIGURE 1-5 J2EE Application Assembly and Deployment

The sections that follow summarize the development phases for J2EE applications. Because a J2EE application is not required to have every type of module, only one of the first three phases is required. The final two phases are necessary. Since this manual focuses on enterprise beans, it does not discuss the Web Component Creation phase.

Tasks:

• Codes and compiles the Java source code needed by the enterprise bean
  
• Specifies the deployment descriptor for the enterprise bean
  
• Bundles the .class files and deployment descriptor into an EJB .jar file
  

Persons: Web designer (JavaServer Pages components), software developer (servlets)

Tasks:

• Codes and compiles Java source code for the servlet
  
• Writes .jsp and .html files
  
• Specifies the deployment descriptor for the Web component
  
• Bundles the .class, .jsp, .html, and deployment descriptor files into the .war file
  

Tasks:

• Codes and compiles the Java source code needed by the client
  
Specifies the deployment descriptor for the client

• Bundles the .class files and deployment descriptor into the .jar file for the client.
  

Tasks:

• Assembles enterprise beans (EJB.jar) and Web components (.war) created in the previous phases into a J2EE application (.ear)

• Specifies the deployment descriptor for the J2EE application

Tasks:

• Adds the J2EE application (.ear) created in the preceding phase to the J2EE server

• Configures the J2EE application for the operational environment by modifying the deployment descriptor of the J2EE application

• Deploys (installs) the J2EE application (.ear) into the J2EE server