Enterprise JavaBeans
In a typical business application built on the J2EE platform, business logic will be encapsulated in Enterprise JavaBeans (EJBs). It is possible to use other types of component or plain Java objects to implement business logic, but EJBs provide a convenient way of encapsulating and sharing common business logic, as well as benefiting from the services provided by the EJB container.
EJBs are usually described as a distributable component technology. Unlike JavaBeans, which must reside in the same JVM as the client and server, EJBs can reside in different JVMs allowing the client and server to be located on physically separate machines.
The EJB model makes use of two mechanisms found in J2SE--namely Remote Method Invocation (RMI) and the Java Naming and Directory Interface (JNDI)--to facilitate interaction between the EJB and its client. When an EJB is written, the functionality it offers to clients is defined as an RMI remote interface. When an EJB is deployed, its location is registered in the naming service.
A client will then use JNDI to look up the location of the EJB. It will interact with a factory object, which implements the EJB's home interface, to obtain an instance of the EJB. This is equivalent to using new to create an instance of a local object. When the client has a reference to the EJB, it can use the business functionality offered by the EJB. This sequence is shown in Figure 2.1.
Figure 2.1. A client uses JNDI and RMI to access an EJB.
There is a more detailed look at how to use EJBs on Day 4, “Introduction to Enterprise JavaBeans.” It is worth mentioning that EJBs can also use local interfaces when the client and server reside in the same J2EE container. Typically this happens when one EJB uses functionality of another EJB. Local interfaces are discussed on Day 6, “Entity EJBs.”
Within the required business logic, certain components will be primarily concerned with data and the manipulation of that data, others will focus on the sequencing of business logic and the associated workflow, whereas still others will need to start a large piece of work without waiting for that work to complete. There are three types of EJB covering each of these requirements:
Session Beans
Session beans are the simplest and probably most common type of EJB. A session bean is primarily intended to encapsulate a set of common business functions.
Session beans offer a synchronous interface through which the client can use the business logic. Session beans are not intended to hold essential business data. The Session bean will either hold no data on an ongoing basis, or the data it does hold will only be relevant to the current user session. If a Session bean wants to obtain data from a database, it can use either JDBC calls or Entity EJBs. Session beans are discussed further on Day 5, “Session EJBs.”
Entity Beans
An Entity bean is a representation of some business data and offers a synchronous interface through which the client can access its data and functionality. Entity beans will access underlying data sources (frequently, a database or possibly an ERP system) to collect all the business information they represent. As you will see later, Entity beans are frequently used together with Session beans to provide the business functionality of a system. Entity beans are discussed further on Day 6.
Message-Driven Beans
A Message-Driven Bean (MDB) offers an asynchronous interface to clients. The bean is associated with a particular Java Message Service (JMS) message queue, and any messages arriving on that queue will be delivered to an instance of the Message-Driven bean. As with Session beans, Message-Driven beans are intended to house business logic rather than data, so they will access any data required through JDBC or Entity beans.
To use the services of an MDB, a client will send a message to its associated message queue. Message-Driven Beans and the Java Message Service are discussed further on Day 9, “Java Message Service,” and Day 10, “Message-Driven Beans.”