Day 2. Understanding EJB Types and Interfaces

Thẻ

One challenge facing a new Enterprise JavaBeans (EJB) developer is to understand EJB types and interfaces, and how the EJB container performs its functionality behind the scenes.

Today, you’ll learn all the different types of Enterprise JavaBeans and their interfaces. You’ll look under the hood of the Enterprise JavaBean, which will help you get a better picture. You’ll also learn the fundamentals of packaging and deploying Enterprise JavaBeans.

Enterprise JavaBean Types

The EJB 2.0 specification defines three types of Enterprise JavaBeans: the session bean, the entity bean, and the message-driven bean. Figure 2.1 shows all three types of Enterprise JavaBeans.

Figure 2.1. Enterprise JavaBean types.

Session beans contain business-processing logic. Entity beans contain data-processing logic. Message-driven beans allow clients to asynchronously invoke business logic. In the following sections, you’ll learn about each type of Enterprise JavaBeans.

Session Beans

As its name suggests, session beans implement a conversation between a client and the server side. Session beans execute a particular business task on behalf of a single client during a single session. They implement business logic such as workflow, algorithms, and business rules.

Session beans are analogous to interactive sessions. Just as an interactive session isn’t shared among users, a session bean is not shared among clients. Like an interactive session, a session bean isn’t persistent (that is, its data isn’t saved to a database). Session beans are removed when the EJB container is shut down or crashes.

You can think of a session bean object as an extension of the client on the server side. It works for its client, sparing the client from complexity by executing business tasks inside the server.

Session beans typically contain business process logic and workflow, such as sending an email, looking up a stock price from a database, and implementing compression and encryption algorithms.

There are two types of session beans: stateless and stateful. A stateless session bean represents a conversation with the client without storing any state. On the other hand, a stateful session bean represents a conversational session with a particular client. Such a session object automatically maintains its conversational state, within its member variables, across multiple client-invoked methods.

In Day 3, “Understanding Session Beans,” we’ll scratch the surface of session beans and look into more details of both of their subtypes. In Day 5, “Developing Stateless Session Beans,” we’ll take a hands-on approach to developing a stateless session bean. Day 6, “Developing Stateful Session Beans,” is dedicated to stateful session beans with a practical example from our University Registration System.

Entity Beans

If you’ve worked with databases, you’re familiar with persistent data. The data in a database is persistent; that is, it exists even after the database server is shut down.

Entity beans are persistent objects. They typically represent business entities, such as customers, products, accounts, and orders. Typically, each entity bean has an underlying table in a relational database, and each instance of the bean corresponds to a row in that table.

The state of an entity bean is persistent, transactional, and shared among different clients. It hides complexity behind the bean and container common services. Because the clients might want to change the same data, it’s important that entity beans work within transactions. Entity beans typically contain data-related logic, such as inserting, updating, and removing a customer record in the database.

Two types of entity beans are relevant to persistence: container-managed persistence (CMP) and bean-managed persistence (BMP). In a CMP entity bean, the EJB container manages the bean’s persistence according to the data-object mapping in the deployment descriptor. Any change in the entity bean’s state will be automatically saved to the database by the container. No code is required in the bean to reflect these changes or to manage the database connection. On the other hand, a BMP entity bean has to manage both the database connections and all the changes to the bean’s state.

In Day 8, “Understanding Entity Beans,” we’ll scratch the surface of entity beans and look into more details of both of their subtypes. Day 10, “Developing Bean-Managed Persistence Entity Beans,” is dedicated to developing a CMP entity bean. BMP is discussed with a hands-on example in Day 11, “Developing Container-Managed Persistence Entity Beans.” We’ll also look into the container-managed relationship of entity beans, a new enhancement to EJB 2.0.

Message-Driven Beans

In synchronous communication, the client blocks until the server-side object completes processing. In asynchronous communication, the client sends its message and does not need to wait for the receiver to receive or process the message. Session and entity beans process messages synchronously.

Message-driven beans, on the other hand, are stateless components that are asynchronously invoked by the container as a result of the arrival of a Java Message Service (JMS) message. A message-driven bean receives a message from a JMS destination, such as a queue or topic, and performs business logic based on the message contents, such as logic to receive and process a client notification.

An example of a message-driven bean is when a shopper makes an online purchase order; an order bean could notify a credit verification bean. A credit verification bean could check the shopper’s credit card in the background and send a notification message for approval. Because this notification is asynchronous, the shopper doesn’t have to wait for the background processing to complete.

In Day 13, “Understanding JMS and Message-Driven Beans,” we’ll explore the JMS architecture and highlight the use of message-driven beans. Developing a message-driven bean will be the subject of Day 14, “Developing Messsage-Driven Beans,” when we’ll choose an example from our University Registration System.

Enterprise JavaBean Types

The EJB 2.0 specification defines three types of Enterprise JavaBeans: the session bean, the entity bean, and the message-driven bean. Figure 2.1 shows all three types of Enterprise JavaBeans.

Figure 2.1. Enterprise JavaBean types.

Session Beans

You can think of a session bean object as an extension of the client on the server side. It works for its client, sparing the client from complexity by executing business tasks inside the server.

Session beans typically contain business process logic and workflow, such as sending an email, looking up a stock price from a database, and implementing compression and encryption algorithms.

Entity Beans

If you’ve worked with databases, you’re familiar with persistent data. The data in a database is persistent; that is, it exists even after the database server is shut down.

Message-Driven Beans

EJB Interfaces

Each session or entity bean has two interfaces (home and component) and a bean class. A message-driven bean has only a bean class and defines no interfaces.

In the following sections, you’ll learn the fundamentals of the home interface, component interface, and bean class.

The Home Interface

Clients use the home interface to create, remove, and find Enterprise JavaBean instances. You can think of the home object as the Enterprise JavaBean factory; you write the interface, the container tools generate the home class that corresponds to it, and the home interface defines the creation methods for the Enterprise JavaBean.

For example, the home interface EnrollmentCartHome is defined as follows:

public interface EnrollmentCartHome extends EJBHome {
  EnrollmentCart create() throws CreateException, RemoteException;
}

Therefore, to create an EnrollmentCart bean instance, you call the create() method with no parameters.

The Component Interface

The component interface exposes an Enterprise JavaBean’s business methods to a client. The client calls the methods defined in the component interface to invoke the business logic implemented by the bean. You can think of the component object as a proxy to the Enterprise JavaBean instance. You write this interface. The container tools generate the component class corresponding to this interface.

The component interface EnrollmentCart is defined as follows:

public interface EnrollmentCart extends EJBObject {
   public void addCourses(String[] courseIds) throws RemoteException;
   public Collection getCourses() throws RemoteException;
   public void empty() throws RemoteException;
 }

Therefore, to add courses to the enrollment cart, you call the addCourses method on the component interface and pass the proper parameters.

Note

The component interface has only the methods that are callable by the client. The Enterprise JavaBean may have other methods in it, but if they aren’t listed in the component interface, clients cannot call them.

When compiling both the home and component interfaces, a class may be generated for each interface by using a vendor-specific EJB compiler.

Caution

You cannot assume that any particular implementation of classes will be generated by the container tools. It is highly vendor-specific. The container might or might not generate a class corresponding to each interface.

The Enterprise JavaBean Class

The Enterprise JavaBean class is where you implement the business logic defined in the component interface. Session beans implement the javax.ejb.SessionBean interface, whereas entity beans implement the javax.ejb.EntityBean interface, and message-driven beans implement the javax.ejb.MessageDrivenBean interface.

For example, the EnrollmentCartEJB session bean is implemented as follows:

public class EnrollmentCartEJB implements javax.ejb.SessionBean  {
      private SessionContext ctx;
      private HashSet cart;
      /*  callback methods  */
      public void setSessionContext(SessionContext ctx) {
         this.ctx = ctx;
      }
      public void ejbCreate() throws CreateException {
         cart = new HashSet();
      }
      public void ejbActivate() {}
      public void ejbPassivate() {}
      public void ejbRemove() {}

     /* Here you implement all business methods
         as defined in the component interface...
     */
     public void addCourses(String[] courseIds) {
         if (courseIds == null) {
            return;
         }
         for (int i = 0; i < courseIds.length ; i ++ ) {
            cart.add(courseIds[i]);
         }
      }
      public Collection getCourses() {
         return cart;
      }
      public void empty() {
         cart.clear();
      }
}

First, the EnrollmentCartBean implements all the business methods it advertised in its interfaces. Because it is a session bean, EnrollmentCartBean implements javax.ejb.SessionBean. The javax.ejb.SessionBean interface provides few callback methods to be implemented by any session bean. In the preceding example, the EnrollmentCartEJB implements the callback methods setSessionContext() and ejbCreate(). The EJB container calls these callback methods to perform some of its functionality and also to notify the instance of important events. Clients will never call such methods.

Note

The Enterprise JavaBean class implements neither the home interface nor the component interface. This is often a source of confusion for new developers.

Note

An Enterprise JavaBean may include other classes, or even other packages, but the classes listed earlier are the minimum.

Java Remote Method Invocation over Internet Inter-ORB Protocol Technology

Java Remote Method Invocation (RMI) over CORBA’s Internet Inter-Orb Protocol (IIOP) combines the best features of Java RMI technology with the best features of CORBA technology. The Enterprise JavaBeans architecture adopted RMI/IIOP as its standard communication protocol. Here we briefly discuss RMI and CORBA’s IIOP and their benefits. This discussion will help you to better understand the next section, “Remote and Local Interfaces.”

In the Java distributed object model, a remote object is one whose methods can be invoked from another Java Virtual Machine (JVM), potentially on a different host. An object of this type is described by one or more remote interfaces, which are Java interfaces that declare the methods of the remote object. A remote interface must at least extend, either directly or indirectly, the interface java.rmi.Remote.

Remote method invocation is the action of invoking a method of a remote interface on a remote object. RMI uses a standard mechanism for communicating with remote objects: stubs and skeletons. A stub for a remote object acts as a client’s local representative or proxy for the remote object. The caller invokes a method on the local stub, which is responsible for carrying out the method call on the remote object. In RMI, a stub for a remote object implements the same set of remote interfaces that the remote object implements.

When a stub’s method is invoked, it does the following:

Initiates a connection with the remote JVM containing the remote object.
Marshals (writes and transmits) the parameters to the remote JVM.
Waits for the result of the method invocation.
Unmarshals (reads) the return value or exception returned.
Returns the value to the caller.

The stub hides the serialization of parameters and the network-level communication in order to present a simple invocation mechanism to the caller.

In a remote JVM, each remote object may have a corresponding skeleton. A skeleton is responsible for dispatching the call to the actual remote object implementation. When a skeleton receives an incoming method invocation, it does the following:

Unmarshals (reads) the parameters for the remote method.
Invokes the method on the actual remote object implementation.
Marshals (writes and transmits) the result (return value or exception) to the caller.

RMI provides the benefit of location transparency. Clients aren’t aware of the location of the remote object. From the client’s perspective, it makes no difference whether the remote object is in the same JVM as the client, in a different JVM but on the same machine as the client, or on a different machine from the client.

CORBA (Common Object Request Broker Architecture) is an industry-developed standard for communication among objects. It includes a communication protocol for interobject communication called Internet inter-orb protocol. A key feature of CORBA is its interoperability across platforms, languages, and vendors.

EJB adopted Java Remote Method Invocation (JRMI) over RMI/IIOP as the standard communication protocol. This allows maximum flexibility such as location transparency and interoperability. Other protocols are permitted, but IIOP is required for conformational EJB implementations to interoperate with one another.

You write the Enterprise JavaBean class itself, plus the bean’s home and component interfaces. The client-side implementations of the home and component interfaces (the home class and component class) are generated by deployment tools, and handle the communication between the client and the EJB container. Clients can access an Enterprise JavaBean only through the bean’s home and component interfaces.

Remote and Local Interfaces

During design, you need to decide on the kind of interfaces you will provide to your enterprise bean. The interfaces you provide can be local or remote. Remote interfaces are RMI interfaces that are provided to allow the clients of a bean to be location-independent. EJB 2.0 introduced local interfaces to improve performance of client access to enterprise beans.

Remote Interfaces

A remote client accesses a session bean or an entity bean through the bean’s remote interface and remote home interface. The remote and remote home interfaces of the bean provide the remote client view of the EJB.

The remote interface extends the javax.ejb.EJBObject interface. Container tools generate the corresponding EJB object implementing this interface.
The remote home interface extends the javax.ejb.EJBHome interface. Container tools generate the corresponding EJB home object implementing this interface.

Figure 2.3 shows a remote client can run in the same or a different JVM as that of the Enterprise JavaBean. The remote client can be a Web component (such as a JSP or servlet) or another Enterprise JavaBean, or an application client.

Figure 2.3. Remote clients.

Local Interfaces

Local interfaces were first introduced in the EJB 2.0 specification. Local interfaces improve the performance of client access to Enterprise JavaBeans that are located in the same JVM. This optimization is achieved by making a direct local process call instead of using remote invocation. Any RMI call is expensive compared to a local call. Local calls don’t incur the communication overhead, such as connection initiation, and stubs and skeletons marshalling and unmarshalling the call parameters, that is associated with remote calls. Local calls are magnitude times faster compared to remote calls.

A local client accesses a session or entity bean through the bean’s local interface and local home interface. A local client is located in the same JVM as the Enterprise JavaBean.

The local interface extends the javax.ejb.EJBLocalObject interface. Container tools generate the corresponding EJB local object implementing this interface.
The local home interface extends the javax.ejb.EJBLocalHome interface. Container tools generate the corresponding EJB local home object implementing this interface.

Figure 2.4 shows a local client must run in the same JVM as that of the Enterprise JavaBean. Unlike a remote client, a local client is not location-transparent. A local client can be a Web component (such as a JSP or servlet) or another Enterprise JavaBean.

Figure 2.4. Local clients.

Note

If you provide remote interfaces, you get maximum flexibility through location transparency. Your clients can be located anywhere. If you provide local interfaces to your Enterprise JavaBean, you get maximum performance, but at the price of location transparency: Your clients must be located in the same JVM as the Enterprise JavaBean instance. On the other hand, with remote interfaces, you can improve the performance by distributing the components among different servers.

Caution

The calling semantics of local interfaces are different from those of remote interfaces. Remote interfaces pass parameters using call-by-value semantics, whereas local interfaces use call-by-reference. For example, an Enterprise JavaBean could pass a large document to the client. With remote interfaces, the system would return a copy of the document to the client. On the other hand, with local interfaces, the client would get a reference to the bean’s document. So, the client could potentially change the Enterprise JavaBean’s state without the bean’s knowledge. If this isn’t acceptable, your Enterprise JavaBean must explicitly copy the data before returning to the client.

Deployment Descriptors

A deployment descriptor is an Extensible Markup Language (XML) document (with an .xml extension) that describes a component’s deployment settings. Because deployment descriptor information is declarative, it can be changed without modifying the Enterprise JavaBean source code. For example, a deployment descriptor declares transaction attributes and security authorizations for an Enterprise JavaBean. You can create the deployment descriptors by hand or use vendor tools to generate them. At deployment time, the J2EE server reads the deployment descriptor and acts on the component accordingly. The following sections describe various deployment descriptors.

Standard `ejb-jar.xml`

This file is the standard deployment descriptor as specified by Sun, and it must contain the Sun Microsystems–specific EJB document type definition (DTD).

The ejb-jar.xml describes the Enterprise JavaBean’s deployment properties, such as its bean type and structure. The file also provides the EJB container with information about where it can find, and then load, the home interface, remote interface, and bean class. It declares its internal dependences and the application assembly information, which describes how the Enterprise JavaBean in the bundled ejb-jar file is assembled into an application deployment unit.

Here is a sample ejb-jar.xml file:

<?xml version="1.0"?>

<!DOCTYPE ejb-jar PUBLIC
'-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN'
'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>

<ejb-jar>
  <enterprise-beans>
    <session>
      <ejb-name>EnrollmentCart</ejb-name>
      <home>EnrollmentCartHome</home>
      <remote>EnrollmentCart</remote>
      <ejb-class>EnrollmentCartEJB</ejb-class>
      <session-type>Stateful</session-type>
       ...
    </session>
  </enterprise-beans>




Packaging and Deploying Enterprise JavaBeans
The process of assembling components into modules, and modules
into applications, is known as packaging. The
Java ARchive (JAR) file format enables you to bundle multiple files into a
single archive file. Enterprise beans use the JAR file format for packaging
Enterprise JavaBeans in a generic and portable way.

The ejb-jar file is the standard format for packaging
Enterprise JavaBeans. Figure 2.5 shows
sample contents of an ejb-jar file. It contains deployment
descriptor(s), one or more Enterprise bean classes, their home and component
interfaces, and related files.
Figure 2.5. Standard
ejb-jar file.


After you have packaged your Enterprise JavaBeans, you need to
install and configure them in an EJB container for loading and execution. This
is known as deployment,
which makes the new functionality available as a service.

During deployment, you'll make several decisions, such as how
clients find the components (naming, security, authorization), concurrency, data
access (which component maps to which database objects, vendor/type of
databases, JDBC drivers), which component lives where (partitioning), and which
component participate in distributed transactions and which ones don't.
Containers provide tools to help you with the deployment process.


</ejb-jar>

The prolog contains the declaration and the DTD for the validation. The document root is the <ejb-jar> tag. The element <enterprise-beans> contains subelements to describe the bean deployment properties. The remote and home interfaces and the bean class name are described using their fully qualified names. The bean’s subtype is declared as a stateful session bean.

Note

The Enterprise JavaBean type is differentiated by the interface implemented and by the subtype declaration in the deployment descriptor.

Vendor-Specific Deployment Descriptor

In addition to standard ejb-jar.xml, an application typically requires a certain amount of additional environment-specific or vendor-specific binding information. In deploying an EJB to a specific application server, you might be required to have a vendor-specific deployment descriptor that provides information about how to map a package name to a JNDI name, and how to handle both security and persistence. For example, jboss.xml is specific to the JBoss server, and weblogic-ejb-jar.xml is specific to BEA WebLogic Server.

Caution

Vendor-specific deployment descriptors aren’t standardized. They are different for different vendors. Also, they could potentially change for a given vendor.

Enterprise JavaBean Restrictions

The EJB container provides functionality such as life cycle management, threading, security, and resource pooling. Enterprise bean instances may be distributed; that is, they may run in separate JVMs or on separate machines. To efficiently manage resources such as memory, the container can swap the instances from memory to disk.

To run properly, the container imposes certain restrictions on the components that live within. This ensures the proper functioning of the container and the Enterprise JavaBean’s portability and scalability.

The following are some of the restrictions imposed on Enterprise JavaBeans:

Must not read/write static fields: It’s okay to use read-only static fields. It is better to declare the static fields as final. Static fields are shared among all instances of a particular class. Updating a static field works if all the instances are running in the same JVM, but it doesn’t work if the instances are distributed in separate JVMs.
Must not use thread synchronization primitives to synchronize execution of multiple instances: Thread synchronization works if all the instances are running in the same JVM, but doesn’t work if the instances are distributed in separate JVMs.
Must not create or manage (start, stop, suspend, resume, change priority) threads: The EJB container is responsible for creating and managing threads. Allowing the Enterprise JavaBean instances to create and manage threads interferes with the container functionality.
Must not read or write files and directories or access file descriptors: Files, directories, and file descriptors are typically local resources to a machine, and can’t be distributed across machines in a portable way. Also, access to the file system is a security hazard because the Enterprise JavaBean could potentially read and write the contents of sensitive files.
Must not listen or accept connections on a socket: This isn’t allowed because if an Enterprise JavaBean is listening on a socket, it can’t be swapped to disk. It’s okay for Enterprise JavaBeans to be network socket clients.

Best Practices

You should consider using a session bean if only one client has access to the bean instance and the state of the bean is not persistent. An entity bean is best used if multiple clients can access the bean and the state of the bean is persistent. You should consider using a message-driven bean when you want to develop loosely coupled systems and process asynchronous messages.

Deciding on remote or local access depends on several factors. If your client runs on a different JVM or machine, you must provide remote access. For example, in large production systems, Web components might run on a different machine. On the other hand, entity beans with container-managed relationships (CMR) with other entity beans (discussed on Day 11) must provide local access. In other situations, when in doubt, prefer remote access. This gives you maximum flexibility to distribute the components across machines to meet a higher load.

Summary

If today was your first exposure to EJB fundamentals, it probably seems theoretical and a bit overwhelming. Don’t be alarmed. You’ll be using these concepts for the rest of this book, and they will become familiar as you gain more experience using them.

Here is the summary of terms and concepts covered today.

A session bean executes a particular business task on behalf of a single client. An entity bean is a persistent business object. A message-driven bean allows clients to asynchronously invoke business logic.

Clients use the home interface to create, remove, and find Enterprise JavaBean instances. A client calls the methods defined in the component interface to invoke the business logic implemented by the Enterprise JavaBean.

The remote home interface is a location-transparent version of the home interface. Container tools generate the corresponding EJB home object. The remote interface is the location-transparent version of the component interface. Container tools generate the corresponding EJB object when implementing this interface.

The local home interface is a non-location-transparent, high-performance version of the home interface. Container tools generate the corresponding EJB local home object when implementing this interface. The local interface is a non-location-transparent, high-performance version of the component interface. Container tools generate the corresponding EJB local object when implementing this interface.

Packaging is the process of assembling components/modules into an application. Deployment is the process of installing and configuring the packaged components and applications in a container.

EJB In 21 Days ?

~ CopyRight Sams Teach Yourself EJB in 21 Days

Day 2. Understanding EJB Types and Interfaces

Enterprise JavaBean Types

Figure 2.1. Enterprise JavaBean types.

Session Beans

Entity Beans

Message-Driven Beans

Enterprise JavaBean Types

Figure 2.1. Enterprise JavaBean types.

Session Beans

Entity Beans

Message-Driven Beans

EJB Interfaces

The Home Interface

The Component Interface

The Enterprise JavaBean Class

Java Remote Method Invocation over Internet Inter-ORB Protocol Technology

Remote and Local Interfaces

Remote Interfaces

Figure 2.3. Remote clients.

Local Interfaces

Figure 2.4. Local clients.

Deployment Descriptors

Standard `ejb-jar.xml`

Packaging and Deploying Enterprise JavaBeans

Figure 2.5. Standard `ejb-jar` file.

Vendor-Specific Deployment Descriptor

Enterprise JavaBean Restrictions

Best Practices

Summary

Bình luận về bài viết này

Enterprise JavaBean Types

Figure 2.1. Enterprise JavaBean types.

Session Beans

Entity Beans

Message-Driven Beans

Enterprise JavaBean Types

Figure 2.1. Enterprise JavaBean types.

Session Beans

Entity Beans

Message-Driven Beans

EJB Interfaces

The Home Interface

The Component Interface

The Enterprise JavaBean Class

Java Remote Method Invocation over Internet Inter-ORB Protocol Technology

Remote and Local Interfaces

Remote Interfaces

Figure 2.3. Remote clients.

Local Interfaces

Figure 2.4. Local clients.

Deployment Descriptors

Standard ejb-jar.xml

Packaging and Deploying Enterprise JavaBeans

Figure 2.5. Standard ejb-jar file.

Vendor-Specific Deployment Descriptor

Enterprise JavaBean Restrictions

Best Practices

Summary

Chia sẻ:

Có liên quan

Bình luận về bài viết này

Standard `ejb-jar.xml`

Figure 2.5. Standard `ejb-jar` file.