All J2EE solutions are developed, tested, and deployed in the context of application servers that are certified with the J2EE platform, such as WebLogic Server. If you are learning to develop J2EE solutions, inarguably you will need to become familiar with a J2EE server.

As illustrated in Figure 5.3, the J2EE server is effectively the nucleus of all J2EE solutions. Depending on the context in which it is used, it either serves as the operating system for a J2EE application, or, if it is part of an application infrastructure solution, as in the case of WebLogic Platform, it serves as an Internet platform/operating system for Web-based solutions.

The primary role of an application server is to provide an environment, through the employment of the Web and EJB containers, for the execution and management of J2EE components (Servlets, JavaServer Pages, and EJBs). The J2EE server containers are the interface between a J2EE component and the low-level platform-specific functionality that supports that component.

J2EE containers are configurable based on the deployment requirements of a J2EE component or application, which can customize the underlying support services provided by the J2EE server, for example security, transaction management, Java Naming and Directory Interface (JNDI) lookups, and remote database connectivity. The J2EE containers can also provide non-configurable services such as enterprise bean and servlet life cycle management, database connection pooling, data persistence management, and access to the J2EE platform APIs.

The bottom layer of a J2EE server is the native operating system (OS) on which it runs. The OS ultimately controls the memory, I/O, and CPU resources assigned to the J2EE server. Even though all J2EE servers are configurable, they generally consume large amounts of these resources, so the OS may have to be configured to accommodate this.

The objective of the JVM layer is to make the choice of the OS development and deployment environments transparent to the Java developer. To enable this transparency to the developer, JVMs are hardware- and OS-dependent because they must interface with the native OS APIs.

At a high-level, the primary job of the JVM is to load Java class files that contain pre-execution Java byte code and translate them into native machine instructions, which are then executed by the respective operating system. The JVM controls memory management by garbage collecting unreferenced memory and providing heap and stack memory allocation. The JVM also provides classes that the application developer uses to interact with the OS.

There are many JVMs that are available in the marketplace today providing different techniques in the compilation and execution of Java code and the overall management of the loaded Java class files. The most popular JVM is the Java HotSpot VM provided by Sun, which is installed with most J2EE servers. However, BEA has opted to select the WebLogic jRockit JVM, which is more performance-oriented in its design and architecture to support enterprise applications.

The execution environment uses the JVM to control applications running within the J2EE server, which are primarily Web-based EJB applications. These applications require resources and services such as memory, threads, database connections, and network connections, which are controlled by the J2EE server execution environment. The server execution environment is also responsible for bootstrapping the system, handling failover, and the clustering of Web and EJB containers.

The J2EE Application Programming Model shown in Figure 5.3 essentially wraps the application tiers in the context of containers (Application Client, Web, and EJB containers) through the use of interfaces and APIs. This approach implies that you need only communicate with the container through a familiar interface or API rather than attempting to manage the complexities of the enterprise environment.

The J2EE containers have access to this J2EE service layer, which consists of two parts: the API and the service implementation. The APIs are the interfaces or contracts used by the application programmer to use the services. The service implementation is the underlying Java software classes, such as JDBC and JMS, providing the service, which is provided by a J2EE server vendor as long as it adheres to the J2EE service API specification.

In this section only the J2EE APIs in the J2EE Services Layers will be discussed because the service provider classes are only relevant to J2EE software vendors.

The Remote Method Invocation (RMI) Service

Remote Method Interface (RMI) is Java’s native mechanism for object-oriented JVM to JVM synchronous communication. RMI enables an object in one JVM to access an object in another JVM using the same semantics for accessing local Java objects, with the exception that RMI-based objects must catch exceptions associated with network failures (that is, java.rmi.RemoteException).

Where Is RMI Used in J2EE?

RMI is the principle mechanism used by clients to access EJBs. Clients are usually servlets, JSPs, or Java applications, but they can also be CORBA applications and Java applets. The EJB container does not support HTTP and cannot be accessed directly over the Web. RMI is also used by Web containers and EJB container components to access CORBA or RMI-based services external to a J2EE server.

Note

EJB services can be deployed as Web Services automatically in WebLogic Server 7.0; therefore they can be accessed over the Web via HTTP.

Because J2EE is a distributed architecture, RMI is critical to its inner workings. However, the use of RMI is concealed by the EJB container, which generates RMI code and makes RMI calls without the explicit involvement of the application developer.

How Is RMI Used in J2EE?

The RMI service is an environment used by Java applications when performing distributed object computing.

According to the RMI specification from Sun, RMI has the following features:

• Stubs and skeletons allow transparent communication with a J2EE component outside the local JVM. The stub and skeleton classes handle all data marshalling and network transmission issues. The transport protocol used by RMI is either Internet-Inter-Orb-Protocol (IIOP) or Java Remote Method Protocol (JRMP).

• The RMI object registry or RMI naming service maps a name to a remote object. An RMI client program passes the name of the requested RMI object to the Registry. If the name is found, a remote object reference is returned to the client. The client uses the reference to connect to the RMI object.

• Dynamic class loading, which allows objects transmitted over RMI to be loaded when they are discovered.

• HTTP tunneling, which embeds RMI calls within the body of an HTTP post request, and receives the return information in the body of an HTTP response.

• Object activation in RMI allows objects to execute on an as-needed basis. That is, RMI objects that are registered as such can be activated if they are not currently executing. RMI objects can also be set up to be started manually.

• Distributed Garbage Collection (DGC) provides a way for an RMI server to remove unused objects from its address space hence providing lifecycle management for RMI objects. DGC maintains reference counts for objects so that when an object is not referenced it is moved into the JVM garbage collection bin. DGC also performs polling and maintains timers to determine whether connections are alive. If a connection times out, reference counts are decremented and the RMI server object may become eligible for garbage collection.

J2EE servers must implement these features to provide a J2EE-compliant RMI service. The following list shows how a J2EE server uses these RMI features:

• Stubs and skeletons. The J2EE server generates stubs and skeletons for internal use in various places (EJBs, JNDI, and so on).

• RMI object registry. A J2EE server uses JNDI for object reference lookup and persistent storage.

• Dynamic class loading. A J2EE server has its own class loaders for dynamically loading classes.

• HTTP tunneling. A J2EE server provides HTTP tunneling for RMI.

• Object activation. The J2EE server provides object activation for EJB objects by loading them at startup time or by dynamically loading them during live deployment.

• Distributed Garbage Collection (DGC). Object life cycle is controlled by the J2EE server. In particular, DGC lifecycle management is not used by the EJB container.

RMI is implemented using a number of underlying data transfer protocols. The most commonly used protocols are IIOP and JRMP, which do have their differences as follows:

• Both protocols provide the basic stub/skeleton data marshalling and network communication, but JRMP has a timeout mechanism, used with DGC, which is not present in IIOP.

• You cannot use DGC with IIOP.

• IIOP cannot use the RMI object registry and instead must use another mechanism, such as JNDI.

• JRMP uses Java object serialization for data marshalling.

• IIOP uses the Common Data Representation (CDR) standard for data marshalling, which is defined by Object Management Group (OMG).

Because the J2EE server does not explicitly use JRMP features or provides a replacement, it can use IIOP and JRMP interchangeably.

The Details of an RMI Method Call

To make an RMI method call, the RMI developer must first define and create an interface on a remote object that extends the java.rmi.Remote interface, which will describe the methods available to remote client programs. The developer must also write the Java code to implement the methods for that remote interface. This code serves as the server-side RMI object.

The RMI interface and server-side files are compiled by the Java compiler. The class files created from the RMI interface compilation are used by the RMI compiler (rmic) to generate the stub and skeleton proxy object class files. RMI clients use these stub or proxy objects to access RMI objects.

Referencing Figure 5.4, the following steps describe a simple RMI method call:

Figure 5.4. A simple example of an RMI call.

1. The client program obtains an object reference (proxy object) from the RMI object repository.

2. The client program calls a method in the proxy object, passing arguments as native types or Java objects.

3. The proxy object connects to the remote RMI server. Data is marshalled using CDR (for IIOP) or Java object serialization (for JRMP) and the data packet is shipped over the network to the waiting RMI server.

4. The server proxy object unmarshals the data and issues a call down to the corresponding RMI object.

5. The RMI object executes the application’s code and returns the result to the server proxy object.

6. The server’s proxy object marshals the result and transmits it back to the waiting client’s proxy object.

7. The client’s proxy object unmarshals the packet and returns the result to the client application.

8. The client application continues processing as if the call were made in its own address space.

Note

▸ For technical information on RMI in the context of WebLogic Server 7.0, see “Distributed Processing Using RMI,” p. 385.

The Java Naming and Directory Interface (JNDI) API

The Java Naming and Directory Interface (JNDI) is an API that describes hierarchical structures. The “Naming” part associates names with objects. The “Directory” part associates attributes of those objects with the names. JNDI provides a way to store global information available to Web and EJB containers.

Where Is JNDI Used in J2EE?

JNDI is primarily used for looking up J2EE resources. JNDI stores important resources, such as JMS connection factories, JDBC data sources, J2EE resource adapters, environment variables, JavaMail drivers, RMI names, and JTA resource managers.

JNDI is also used for storing state information for session beans.

Tip

JNDI is a convenient place to store singleton objects because EJBs cannot store static objects.

How Is JNDI Used in J2EE?

There are three parts to the namespace hierarchy stored in JNDI, as shown in Figure 5.5.

Figure 5.5. A simple JNDI hierarchical tree presentation.

At the top of the tree is the root context. This defines the start of the namespace. The root context contains objects and subcontexts. A subcontext contains objects and other subcontexts. An object represents the leaf in a tree. This is the information that was stored in the tree; everything else is just organizational information.

For a Web or EJB component program to use JNDI it must first establish a connection to the J2EE server’s JNDI service. The JNDI driver and root context are specified in two JVM system variables, java.naming.factory.initial and java.naming.provider.url. The initial factory context specifies the JNDI driver and the provider URL specifies the root context.

To connect to the JNDI service, the Web or EJB component must get the JNDI initial context. The javax.naming.InitialContext object contains the connection information for JNDI. Once connected to JNDI you can use the Context interface of the javax.naming package for looking up, binding, unbinding, and renaming objects as well as creating and destroying subcontexts.

Note

▸ For technical information on JNDI in the context of WebLogic Server 7.0, see “Locating Named Services Through JNDI,” p. 447.

ejb-jar.xml
<enterprise-beans>
    <entity>
     . . .
      <resource-ref>
        <res-ref-name>jdbc/myPool</res-ref-name>
        <res-type>javax.sql.DataSource</res-type>
        <res-auth>Container</res-auth>
      </resource-ref>
     . . .
</enterprise-beans

web.xml
<web-app>
    <servlet>
     . . .
    </servlet>
    <resource-ref>
        <res-ref-name>jdbc/myPool</res-ref-name>
        <res-type>javax.sql.DataSource</res-type>
        <res-auth>Container</res-auth>
    </resource-ref>
     . . .
</servlet>

Connection con=null;
try
{
     InitialContext ic = new InitialContext();
     //Look up the DataSource in JNDI
     DataSource ds = (DataSource) ic.lookup("myDataPool");
     //Obtain a connection to the database
     con =  ds.getConnection();
     //Create and prepare a statement to access the database
     PreparedStatement ps = con.prepareStatement(
         "select * from MyTable where id=?");
     ps.setString(1,"999");
     //Execute the query and receive the results
     ResultSet rs = ps.executeQuery();
     //Read the ID from the MyTable table in the database
     int id = rs.getInt("id");
}
catch (Exception ex)
{
. . .
}

The Java Transaction (JTA) API

Transactions are used to cause a set of related operations to perform like a single isolated operation—Single Unit of Work. A single operation either succeeds (it is committed) or fails (it is rolled back). There are no partial successes or failures. For isolated operations, data used by the operation is not changed by other programs.

Because J2EE is a distributed architecture, transactions can span multiple J2EE servers, databases, or other resources. For local transactions, which do not span resources, J2EE resources can manage their own transactions. For distributed transactions, J2EE requires a transaction manager to control the two-phase commit protocol. The two-phase commit protocol is used to guarantee that all participants in a distributed transaction agree to either commit or rollback an operation. Resources participating in a distributed transaction must be XA-compliant.

Where Are Transactions Used in J2EE?

Referencing the J2EE Architecture diagram shown in Figure 5.2, transactions are typically requested from the client tier and then executed and managed by the server-side business tier.

Transactions are controlled either programmatically or declaratively using statements in a deployment descriptor. Because multiple components can be part of a transaction, the J2EE container must forward the transactional context to each participant. JDBC and the Java Transactional API (JTA) provide methods for programmatic transactional control. JDBC transactions are controlled using a java.sql.Connection interface, obtained by calling the getConnection method from the JDBC DataSource. JTA transactions are controlled using an object implementing the javax.UserTransaction interface. These objects are either retrieved from JNDI under the name javax.transaction.UserTransaction, or from the session context of a session bean or from the message context of a message bean.

Entity beans cannot use programmatic transaction controls. Declarative or container-managed transactions are used by session, message, or entity beans. An EJB must be identified as using container-managed transactions in its deployment descriptor. For this style of transaction, each method is assigned a transaction attribute. There are six types of transaction attributes, but the most commonly used value is “Required.” Setting a transactional attribute “Required” for a method implies the method will always run in the context of a transaction. If a transaction is already in effect, the method will use it. If a transaction is not in effect, the method’s entry and exit points demarcate a new transaction. Figure 5.6 illustrates the transaction options available to the J2EE components.

Figure 5.6. The transaction options available to the J2EE components.

These options operate as follows:

• Servlets, JSP, and Java application and applet clients must use programmatic transactions.

• Session and Message beans can use either programmatic transactions or use declarative transactions.

• Entity beans must use declarative transactions.

• Transactions can be programmed using JDBC transactions or the Java Transaction API. JTA supports distributed transactions.

• Declarative transactions, controlled by the EJB container, and programmatic transactions pass transactional context to EIS systems.

Listing 5.3 describes a simple deployment descriptor declaring an EJB that uses container-managed transactions for all its methods. The transaction attributed is set to “Required.” The EJB first has to have its transaction type set to “Container” or “Bean.”

Note

Bean-managed transactions use JDBC or JTA explicitly.

Example 5.3. Transaction Elements in the ejb-jar.xml

<ejb-jar>
  <enterprise-beans>
     <entity>
       <ejb-name>MyBean</ejb-name>
. . .
      <transaction-type>Container</transaction-type>
. . .
    </entity>
  </enterprise-beans>
  <assembly-descriptor>
    <container-transaction>
      <method>
        <ejb-name>MyBean</ejb-name>
        <method-name>*</method-name>
      </method>
      <trans-attribute>Required</trans-attribute>
    </container-transaction>
</assembly-descriptor>

In Listing 5.3, the <container-transaction> keyword defines the method level transaction for EJBs described by the deployment descriptor. The <trans-attribute> keyword describes how the container should manage transactions when executing a method.

Listing 5.4 describes a skeleton Servlet class using programmatic transactions. First an object implementing the UserTransaction is retrieved from JNDI. Next the begin method is called on the object, which starts the transaction. At this point, you can add business logic relating to a transaction, such as an SQL statement. If the business transaction is successful, the commit method is called, which causes all changes to be permanent. If an exception occurs the transaction is rolled back.

Example 5.4. Programming Transactions in J2EE

public class MyBusiness extends HTTPServlet
{
    public void getPost(HttpServletRequest req,
            HttpServletResponse res)
    {
        UserTransaction ut=null;
        try
        {
            Context c = new InitialContext();
            ut = (UserTransaction)c.lookup(
                    "javax.transaction.UserTransaction");
            ut.begin()
            /...do business
            ut.commit();
        }
        catch (Exception e)
        {
            ut.rollback();
        }
    }
}

Container-managed transactions do not require special coding to start and commit or rollback transactions as this is managed by the EJB. However, if a transaction must be aborted, EJBs must call the setRollbackOnly method of the EJBContext object to notify the EJB container. The container will mark the transaction and it will be rolled back at the earliest opportunity.

Note

▸ For technical information on JTA in the context of WebLogic Server 7.0, see “Managing Java Transactions Using JTA,” p. 527.

The Java Messaging Service (JMS)

The Java Messaging Service (JMS) API provides J2EE programs with loosely coupled, loosely typed distributed communication. There are two types of users of JMS: consumers and producers. Producers send messages to a repository where they can later be retrieved by a consumer. This is in contrast to the synchronous, strongly typed mechanism used in remote procedures calls (RPC), such as with RMI. With JMS, the producer only needs to know the message format and the message destination. With RPC, the caller must know the argument data types and the lifecycle of the caller’s methods is intertwined with the receiver’s methods.

The primary functions provided by JMS are as follows:

• Persistent and non-persistent messages: Messages are always delivered unless the provider fails. If persistent messages are sent, messages are written to a reliable data store. If a provider fails, it will retransmit the messages upon restart.

• Asynchronous and synchronous transmission and delivery of messages: Messages are transmitted either using synchronous messaging where the producer waits for the message to be consumed or asynchronous messaging where the producer posts the message to a repository and continues processing. Similarly, the consumer can either wait for incoming messages or specify a receiver thread to be notified when messages arrive.

• Message filtering: Filtering is done using message selectors. Properties are associated with a message and consumers wait for messages matching those properties. Consumers can also specify fields in the message header and only receive messages matching those values.

• Message types: JMS messages consist of a header, optional properties, and an optional body. The header holds the message destination, creation time, priority, and so on. The properties are set by the developer when message filtering is used. The main content of the message is in the body. The consumer receives the message and extracts the header, properties, and body of the message. JMS supports five message types: text, keyword and value pairs, byte streams, mixed primitive data type streams, and Java objects.

• Transactions: JMS supports both local and distributed transactions. Local transactions enable a producer or consumer to identify a group of messages that must be processed as a whole. However, the consumer and producer do not share the transaction. The transaction is only on the producer’s or consumer’s end. The developer must call the commit or rollback methods explicitly. With distributed transactions using JTA or container-managed transactions for EJBs, the message consumer can associate message consumption with database updates and communications with other transaction-aware components.

The JMS API has a number of basic components. The starting point is the connection factory. The connection factory allows a J2EE client to connect to a JMS provider. The connection factory is stored in JNDI. Using the connection factory a developer obtains a connection, which is a virtual link to a JMS provider. Using the connection, a session is created that serves as a single-threaded context for producing and consuming messages as well as maintaining transactional and reliability controls. Using a session, message producers and consumers are created to send and receive messages to a particular destination. After this set-up is complete, messages are exchanged.

JMS supports two models for delivering messages, Point-to-Point (PTP) and Publish/Subscribe (pub/sub).

PTP messages are delivered to one consumer. JMS stores PTP messages in a queue that reside there until a consumer removes them. The receiver sends an acknowledgment to the provider after successfully processing the message.

Publish and subscribe messages are delivered to all consumers who have registered to receive messages. JMS stores pub/sub messages in a topic, which is a subject identity in the message queue. A topic consumer can only receive messages after it subscribes to a topic. A topic consumer must also be active to receive messages, unless it is using a durable subscription.

Topics are commonly used in systems with multiple consumers and a single producer. Queues are commonly used when a single or multiple producers send messages to a single consumer. These scenarios are illustrated in Figure 5.7:

Figure 5.7. A simple illustration of a JMS Provider scenario.

• Several JMS applications send messages to Queue #1.

• Messages for Queue #1 are written to persistent storage so they can be recovered and delivered in case of a system or application failure.

• Messages are delivered to single application handling Queue #1 processing.

• A single producer sends messages to Topic #1. The producer broadcasts messages to all listeners of the topic.

• Messages for Topic #1 are written to persistent storage so they can be recovered and delivered in case of a system or application failure.

• A copy of the topic message is delivered to each listening consumer.

Note

Persisting the messages to a persistent store is optional.

Where JMS Is Used in J2EE?

JMS is primarily used to deliver messages to message-driven beans (MDB). MDBs reside in EJB containers and receive messages asynchronously. MDBs can use container-managed transactions and interact with other J2EE components, such as entity beans, as part of their transactions. They can also participate in distributed transactions.

JMS is also used to integrate legacy applications with J2EE applications. Many legacy applications use messaging products, such as MQSeries and TIBCO that have JMS interfaces. JMS is also used for event notification, where a J2EE component is a producer and a number of client applications are consumers.

How JMS Is Used in J2EE?

To use JMS in a J2EE, a JMS connection factory and destination (queue or topic) must be registered with the J2EE server. This usually is done using a vendor-specific tool. The connection factory and destination objects are stored in JNDI.

After JMS is configured, producers and consumers can exchange messages. Producers, such as servlets and EJBs, deliver messages to a destination. Listing 5.5 shows the code of a producer that connects to a JMS queue and sends a PTP message.

Example 5.5. PTP JMS Producer

//Use JNDI to look up connection factory and destination
Context context = new InitialContext();
QueueConnectionFactory qcf =
    (QueueConnectionFactory)context.
        lookup("weblogic.mydomain.jms.QueueConnectionFactory");
Queue q = (Queue)context.lookup(
    "weblogic.mydomain.jms.MyQueue");

//Set up the message using the following components
//    Connection <== ConnectionFactory
//    Session    <== Connection
//    Producer   <== Session
//    Message    <== Session
// Get connection to JMS service
Connection c = qcf.createQueueConnection();
// Create a session
QueueSession s = c.createQueueSession(false,
        Session.AUTO_ACKNOWLEDGE);
// Create a producer. Create a QueueSender for queues and TopicPublisher for topics.
QueueSender qs = s.createSender(q);
// Create a message.
TextMessage tm = s.createTextMessage("This is a message);
// Send the message. For topics, a message is published
qs.send(tm) ;

There are two types of consumers, synchronous and asynchronous. There is no difference in the administrative set up for each consumer type and the programmatic set up is also similar. Listing 5.6 shows the code for a synchronous PTP receiver.

Example 5.6. JMS PTP Receiver

//Use JNDI to look up connection factory and destination
Context context = new InitialContext();
QueueConnectionFactory qcf =
    (QueueConnectionFactory)context.
        lookup("weblogic.mydomain.jms.QueueConnectionFactory");
Queue q = (Queue)context.lookup(
    "weblogic.mydomain.jms.MyQueue");

//Set up the message using the following components
//    Connection <== ConnectionFactory
//    Session    <== Connection
//    Consumer   <== Session
//    Start the session using the Connection
// Get connection to JMS service
Connection c = qcf.createQueueConnection();
// Create a session
QueueSession s = c.createQueueSession(false,
        Session.AUTO_ACKNOWLEDGE);
// Create a consumer. Create a QueueReceiver for queues and TopicSubscriber for topics
QueueReceiver qr = s.createReceiver(q);
// Start listening on the connection
c.start();
// Wait for a message by issuing a receive method call
Message m = qr.receive();

When using an asynchronous receiver, the following changes must be made:

• Create a class that implements the javax.jms.MessageListener interface. OnMessage is the only method to be implemented.

• Before calling the start method on the connection, call the setMessageListener method on the consumer object, passing an instance of the class created in step 1.

• Remove the receive method call from the consumer object because the onMessage method will now receive all incoming messages.

Message beans are asynchronous message consumers. Most of the programmatic steps to use JMS are performed by the EJB container. The ejb-jar.xml deployment descriptor describes how the message’s bean is going to use JMS. The message bean must implement the Message Listener interface to receive messages in the onMessage method.

Note

▸ For technical information on JMS in the context of the WebLogic Server 7.0, see “The Java Messaging Service (JMS),” p. 471.

<assembly-descriptor>
    <method-permission>
        <role-name>manager</role-name>
        <role-name>boss</role-name>
    <method>
         <ejb-name>BigBean</ejb-name>
         <method-name>*</method-name>
    </method>
    </method-permission>
. . .

<security-role>
    <description>
        This role represents everyone who is allowed
        to access the big bean
    </description>
    <role-name>boss</role-name>
    <role-name>manager</role-name>
</security-role>

The EJB container provides a runtime environment for distributed Java objects, which includes the following features:

Figure 5.8 illustrates a simple scenario on how EJBs are used inside an EJB container, where:

Figure 5.8. A simple interaction scenario of EJBs inside an EJB container.

Session beans are EJB components used for managing client interactions. Generally, they are not used for updating data stores and usually work best as a transactional facade to entity beans. That is, session bean methods conceal the client application from the complexities of business workflow logic. The interfaces provided by session beans should be simple where the client only needs to call a single method or a group of simple methods to achieve a result that has business value.

There are two kinds of session beans: stateless and stateful.

The rule of thumb for determining when to use a stateful or a stateless session bean is as follows: If a transaction can be completed with a single method call use a stateless session bean; otherwise, use stateful session beans. Although session beans do not represent the state of a data attribute in the data store, they can use JMS and JDBC to read and write persistent state information.

Session beans are declared in the ejb-jar.xml file using the <session> and <session-type> tags. The <session> tag identifies the bean as a session bean. The session type tag with a value of Stateless causes the EJB container to create a stateless session bean. Alternatively, a value of Stateful causes the container to create a stateful session bean.

The Home interface for session beans must have a create method because session beans are not persistent. This create method maps to the ejbcreate() method implemented by the EJB bean class. The EJB container takes care of creating new beans according to the EJB pool deployment descriptor.

Entity beans represent persistent data maintained in a database. Entity bean data is usually mapped to a row in a database table. Like stateless session beans, a particular instance is allocated to a client for the duration of a method call. Entity beans are allocated from a free pool by the container when they are needed.

Because entity beans represent data, they need a unique primary key and must support relationships with other entity beans. This mirrors the functionality supported by relational databases with primary and foreign keys.

The Home interface for an entity bean must define create and finder methods matching those in the entity bean.

Entity beans use two persistence mechanisms. Data can be saved and read by either making explicit JDBC calls from the EJB class or declaratively using the entity bean’s deployment descriptors, where the container issues the JDBC calls. Explicit persistence is referred to as bean-managed persistence (BMP) and declarative persistence is called container-manager persistence (CMP).

Message-driven beans (MDB) are asynchronous JMS message consumers. They provide a loosely coupled mechanism to access services and business logic contained in a J2EE server. MDBs can use entity beans, EIS components, and other J2EE components during their processing. Also, MDBs are ideal for B2B and logging applications where requests are delivered without expecting an immediate response.

MDBs are very similar to stateless session beans. They contain no state, are allocated from a free pool when needed, and are placed back in the free pool after a message is processed. They also support container-managed transactions for the lifetime of the onMessage JMS method call. However, unlike session beans, MDBs have no identity information in their messages; all messages are anonymous. In addition, MDBs do not require a Home or Remote/Local interfaces because they can only receive messages via JMS.

The EJB container performs most of the steps necessary to connect to JMS. At startup, the EJB container creates a pool of free MDBs and connects itself to JMS to receive messages on their behalf. When a MDB is created, the container calls the setMessageContext method. The receipt of a message causes the container to remove an MDB from the free pool and call the onMessage method. When the method call completes, the MDB is placed back in the free pool.

MDBs are declared in the ejb-jar.xml deployment description. The <message-driven> tag identifies the EJB as an MDB. The queue or topic receiving messages is specified in the <message-driven-destination> tag.

A Web or HTTP session is a series of related requests from a client to a particular Web site within a given time period. Sessions allow clients to traverse multiple Web pages and retain contextual information across these pages.

A session begins when a client first contacts a Web site. During a session, clients use a number of Web pages. A session can end for a number of reasons, for example:

Servlets are created by the Web container and participate in sessions with Web clients. Each session consists of a series of HTTP requests and responses. Servlets can store and access contextual information regarding their session through the following objects and methods:

Servlets are created by the Web container the first time a request is made for them. Upon the initial servlet request, the Web container loads the servlet class from storage, creates an instance of it, and invokes the init method of the HttpServlet object. The developer can override the init method and perform servlet-specific initialization.

After the servlet is created and initialized, it can handle HTTP requests and responses. An HTTP request generally is a GET or POST operation. A GET operation uses the query-string in the URL to transfer information. The POST operation uses the message body to transfer information and supports larger and more efficient data transfers. An object implementing the HTTServletRequest interface is passed as an argument to the doGet and doPost methods of the servlet. The developer overrides these methods to handle requests.

The HTTPServletRequest object contains cookie information, the query string data, and binary data in the message body. The servlet also uses this information to perform its work. When the request is processed, the servlet using the HTTPServletResponse object (also passed as a parameter to the doGet or doPost methods of a servlet) fills out the response header, setting cookie values if necessary. When this task is complete, the servlet either dynamically builds the content for the response or forwards the request to another servlet or JSP. The response is eventually returned to the requestor by the Web container.

When the servlet is no longer needed, for example if the servlet class changes on disk and must be reloaded, the Web container removes the servlet from memory after calling the destroy method of HttpServlet class.

Servlets support chains of request filters. A filter is an object that transforms the header or body of an HTTP request or response. Hence Servlets, for example, can be used to customize requests and responses, authenticate requests, and transform XML data.

Servlets can dispatch requests to other servlets or to JSPs. The RequestDispatcher object has methods that allow the servlet to forward requests to and include content from other servlets and JSPs. The RequestDispatcher object is obtained from the ServletContext or HTTPServletRequest objects as discussed earlier.

Servlets use the Web container’s authentication mechanism. They can provide authorization by using the getUserPrincipal or isUserInRole methods in the HTTPServletRequest interface. Security roles and constraints are defined the web.xml deployment descriptor. However, the mechanism for mapping users to roles is performed by the Web container provider and hence is vendor-specific.

Cookies provide long-term user-specific information to be maintained on the client side. Cookies are a piece of information that the Web server asks the client browser to save locally on a user’s disk. Each time a browser accesses the same Web server, it sends all the cookies belonging to that site as part of the HTTP request. Cookies are stored as a name, value pair.

The HttpServlet class provides most of the structure needed by a servlet. The application developer primarily has to be concerned with overriding the doGet and doPost methods. These methods handle the incoming HTTP request and prepare an HTTP response.

Servlets are activated by supplying a URL to the Web container using the following URL syntax:

http://host:port/appName/servletPath?query-string

where:

All servlet declarations and configurations are performed via the vendor-neutral web.xml and vendor-specific deployment descriptor XML-based files respectively. Through these deployment descriptor files you can

When a Web browser requests a JSP, the Web container checks if the same JSP has been already been processed. If this is the first time the container has seen the JSP, it is translated into Java servlet code and compiled into a Java Servlet class. The JSP then executes as a Java servlet.

Figure 5.9 depicts the steps the Web container takes to process HTTP requests and provide responses to a calling client.

Figure 5.9. A Web container accepting HTTP requests and providing responses.

Referencing Figure 5.9:

Because JSPs are transformed into Java servlets, they need language statements to interact with the underlying Java classes. As stated earlier, JSP files are composed of HTML content and JSP-specific XML-like elements. JSPs have three types of elements for controlling the JSP servlet: directives, script control statements, and actions:

In addition to the JSP directives there are a number of reserved JSP variables, most of which enable JSP developers to access the servlet environment and control classes. Some of these variables are listed in Table 5.1.