respective entity beans. Session and message-driven beans like TravelAgent, which are responsible for making a reservation on a cruise, can even access a database directly and perform reads, updates, and deletes to data. But theres no Travel Agent record in the database- -once the bean has made reservation is, it waits to process another What makes this distinction difficult is that it's extremely flexible. The relevant distinction for Enterprise Java Beans is that an entity bean has persistent state the session and message-driven beans model interactions but do not have persistent state Classes and Interfaces A good way to understand the design of enterprise beans is to look at how you'd go about implementing one. To implement entity and session enterprise beans, you need to define the component interfaces, a bean class, and a primary There are basically two kinds of component interfaces, remote and local. The remote interfaces are supported by both EJB 2.0 and 1. 1 while the local component interfaces are new in EJB 2.0 and are not supported by EJB 1.1 Remote interface The remote interface for an enterprise bean defines the bean's business methods that can be accessed from applications outside the EJB container the business methods a bean presents to the outside world to do its work. It enforces conventions and idioms that are well suited for distributed object protocols. The remote interface extends javax. ejb EJBObject, which in turn extends java. rmi Remote. The remote interface is one of the beans component interfaces and is used by session and entity beans in conjunction with the remote home interface Remote home interface The home interface defines the beans life cycle methods that can be accessed from applications outside the EJB container: the life-cycle methods for creating new beans, removing beans, and finding beans. It enforces conventions and idioms that are well suited for distributed object protocols The home interface extends javax. ejb EJBHome, which in turn extends java. rmi Remote. The remote home interface is one of the beans component interfaces and is used by session and entity beans in conjunction with the remote interface EJB 2.0: Local interface The local interface for an enterprise bean defines the bean's business methods that can be used by other beans co-located in the same EJB container; the business methods a bean presents other beans in the same address space. It allows beans to interact without the overhead of a distributed object protocol, which makes them more performant. The local Copyright(c)2001 OReilly Associates
DRAFT, 10/21/017/6/2001 Copyright (c) 2001 O'Reilly & Associates 3 respective entity beans. Session and message-driven beans like TravelAgent, which are responsible for making a reservation on a cruise, can even access a database directly and perform reads, updates, and deletes to data. But there’s no TravelAgent record in the database—once the bean has made reservation is, it waits to process another. What makes this distinction difficult is that it’s extremely flexible. The relevant distinction for Enterprise JavaBeans is that an entity bean has persistent state; the session and message-driven beans model interactions but do not have persistent state. Classes and Interfaces A good way to understand the design of enterprise beans is to look at how you’d go about implementing one. To implement entity and session enterprise beans, you need to define the component interfaces, a bean class, and a primary key: There are basically two kinds of component interfaces, remote and local. The remote interfaces are supported by both EJB 2.0 and 1.1 while the local component interfaces are new in EJB 2.0 and are not supported by EJB 1.1. Remote interface The remote interface for an enterprise bean defines the bean’s business methods that can be accessed from applications outside the EJB container: the business methods a bean presents to the outside world to do its work. It enforces conventions and idioms that are well suited for distributed object protocols. The remote interface extends javax.ejb.EJBObject, which in turn extends java.rmi.Remote. The remote interface is one of the bean’s component interfaces and is used by session and entity beans in conjunction with the remote home interface. Remote Home interface The home interface defines the bean’s life cycle methods that can be accessed from applications outside the EJB container: the life-cycle methods for creating new beans, removing beans, and finding beans. It enforces conventions and idioms that are well suited for distributed object protocols. The home interface extends javax.ejb.EJBHome, which in turn extends java.rmi.Remote. The remote home interface is one of the bean’s component interfaces and is used by session and entity beans in conjunction with the remote interface. EJB 2.0: Local interface The local interface for an enterprise bean defines the bean’s business methods that can be used by other beans co-located in the same EJB container: the business methods a bean presents other beans in the same address space. It allows beans to interact without the overhead of a distributed object protocol, which makes them more performant. The local
interface extends javax. ejb EJBLocalobject. The local interface is one of the bean's component interfaces and is used by session and entity beans in conjunction with the local home interface EJB 2.0: Local Home interface The home interface defines the bean's life cycle methods that can be used by other beans co-located in the same EJB container: that is, the life-cycle methods a bean presents to other beans in the same address space. It allows beans to interact without the overhead of a distributed object protocol which improves their performance. The local home interface extends javax. ejb. EJBLocalHome. The local home interface is one of the beans component interfaces and is used by session and entity beans in conjunction with the local interface Bean class The session and entity bean classes actually implement the bean's business and life-cycle methods. Note, however, that the bean class for session and entity beans usually does not implement any of the beans component interfaces directly. However, it must have methods matching the signatures of the methods defined in the remote and local inter faces and must have methods corresponding to some of the methods in the both the remote and local home interfaces. If this sounds perfectly confusing, it is. The book will clarify this as we go along. An entity bean must implement javax. ejb EntityBean; a session bean must implement javax. ejb SessionBean. The EntityBean and SessionBean extend javax. ejb. EnterpriseBean The message-driven bean in EJB 2.0 does not use any of the component interfaces, because it is never accessed by method calls from other applications or beans. Instead, the message-driven bean contains a single method, onMessage(), which is called by the container when a new message arrives. So the message-driven bean does not have a component interface as does the session and entity beans, it only needs the bean class to operate. The message-driven bean class implements the javax. ejb MessageDrivenBean javax. jms. MessageListener interfaces The JMS MessageListener interface is what makes a message-driven bean pecific to JMS, instead of some other protocol EJB 2.0 requires the use of JMs, but future versions may allow other messaging systems. The MessageDrivenBean, like the EntityBean and SessionBean extends the javax. ejb. EnterpriseBean interface Primary ke The primary key is a very simple class that provides a pointer into the database. Only entity beans need a primary key, the only requirement for this class is that it implements java. io Serializable EJB 2.0 adds the crucial distinction between remote and local interfaces. Local interfaces provide a way for beans in the same container to interact efficiently calls to methods in the local interface don't involve RMI: the methods in the Copyright(c)2001 OReilly Associates
DRAFT, 10/21/017/6/2001 4 Copyright (c) 2001 O'Reilly & Associates interface extends javax.ejb.EJBLocalObject. The local interface is one of the bean’s component interfaces and is used by session and entity beans in conjunction with the local home interface. EJB 2.0: Local Home interface The home interface defines the bean’s life cycle methods that can be used by other beans co-located in the same EJB container: that is, the life-cycle methods a bean presents to other beans in the same address space. It allows beans to interact without the overhead of a distributed object protocol, which improves their performance. The local home interface extends javax.ejb.EJBLocalHome. The local home interface is one of the bean’s component interfaces and is used by session and entity beans in conjunction with the local interface. Bean class The session and entity bean classes actually implement the bean’s business and life-cycle methods. Note, however, that the bean class for session and entity beans usually does not implement any of the bean’s component interfaces directly. However, it must have methods matching the signatures of the methods defined in the remote and local interfaces and must have methods corresponding to some of the methods in the both the remote and local home interfaces. If this sounds perfectly confusing, it is. The book will clarify this as we go along. An entity bean must implement javax.ejb.EntityBean; a session bean must implement javax.ejb.SessionBean. The EntityBean and SessionBean extend javax.ejb.EnterpriseBean. The message-driven bean in EJB 2.0 does not use any of the component interfaces, because it is never accessed by method calls from other applications or beans. Instead, the message-driven bean contains a single method, onMessage(), which is called by the container when a new message arrives. So the message-driven bean does not have a component interface as does the session and entity beans, it only needs the bean class to operate. The message-driven bean class implements the javax.ejb.MessageDrivenBean and javax.jms.MessageListener interfaces. The JMS MessageListener interface is what makes a message-driven bean specific to JMS, instead of some other protocol. EJB 2.0 requires the use of JMS, but future versions may allow other messaging systems. The MessageDrivenBean, like the EntityBean and SessionBean, extends the javax.ejb.EnterpriseBean interface. Primary key The primary key is a very simple class that provides a pointer into the database. Only entity beans need a primary key; the only requirement for this class is that it implements java.io.Serializable. EJB 2.0 adds the crucial distinction between remote and local interfaces. Local interfaces provide a way for beans in the same container to interact efficiently; calls to methods in the local interface don’t involve RMI; the methods in the
local interfaces dont need to declare that they throw RemoteException, and so on. An enterprise bean isnt required to provide a local interface, if you know when you're developing the enterprise bean that it will only interact with remote clients. Likewise, an enterprise bean doesn't need to provide a remote interface if it knows it will only be called by enterprise beans in the same container. You can provide local or remote component interface or both The complexity-particularly all the confusion about classes implementing the methods of an interface but not implementing the interface itself--comes about because enterprise beans exist in the middle between some kind of client software and some kind of data base. The client never interacts with a bean class directly; it al ways uses the methods of the entity or session bean's component nterfaces to do its work, interacting with stubs that are generated automatically For that matter, a bean that needs the services of another bean is just another lient: it uses the same stubs, rather than interacting with the bean class directly. Although the local component interfaces (local and local home) in EJB 2.0 represent session and entity beans in the same address space and do not use distributed object protocols, they still represent a stub or proxy to the bean class While there is no network between co-located beans. the stubs allow the container to monitor the interactions between co-located beans and app security and transactions as appropriate Its important to note, that EJB 2.0s message-driven bean doesnt have any component interfaces, but it may become the client of other session or entity beans and interact with those beans through their component interfaces. The entity and session beans with which the message-driven bean interacts may be co-located,in which case it uses their local component interfaces, or they may be ocated in a different address space and EJB container, in which case the remote omponent interfaces are used There are also lots of interactions between an enterprise bean and its server These interactions are managed by a"container, which is responsible for presenting a uniform interface between the bean and the server. (Many people use the terms"container""server"interchangeably, which is understandable because the difference between them isn't clearly defined. )The container is esponsible for creating new instances of beans, making sure that they are stored properly by the server, and so on. Tools provided by the container's vendor do a tremendous amount of work behind the scenes. at least one tool will take care of creating the mapping between entity beans and records in your database. Other tools generate a lot of code based on the component interfaces and the bean class itself. The code generated does things like create the bean, store it in the database, and so on. This code (in addition to the stubs) is what actually implements the component interfaces, and is the reason your bean class doesn't have to Copyright(c)2001 OReilly Associates
DRAFT, 10/21/017/6/2001 Copyright (c) 2001 O'Reilly & Associates 5 local interfaces don’t need to declare that they throw RemoteException, and so on. An enterprise bean isn’t required to provide a local interface, if you know when you’re developing the enterprise bean that it will only interact with remote clients. Likewise, an enterprise bean doesn’t need to provide a remote interface if it knows it will only be called by enterprise beans in the same container. You can provide local or remote component interface or both. The complexity—particularly all the confusion about classes implementing the methods of an interface but not implementing the interface itself—comes about because enterprise beans exist in the middle between some kind of client software and some kind of database. The client never interacts with a bean class directly; it always uses the methods of the entity or session bean’s component interfaces to do its work, interacting with stubs that are generated automatically. (For that matter, a bean that needs the services of another bean is just another client: it uses the same stubs, rather than interacting with the bean class directly.) Although the local component interfaces (local and local home) in EJB 2.0 represent session and entity beans in the same address space and do not use distributed object protocols, they still represent a stub or proxy to the bean class. While there is no network between co-located beans, the stubs allow the container to monitor the interactions between co-located beans and apply security and transactions as appropriate. Its important to note, that EJB 2.0’s message-driven bean doesn’t have any component interfaces, but it may become the client of other session or entity beans and interact with those beans through their component interfaces. The entity and session beans with which the message-driven bean interacts may be co-located, in which case it uses their local component interfaces, or they may be located in a different address space and EJB container, in which case the remote component interfaces are used. There are also lots of interactions between an enterprise bean and its server. These interactions are managed by a “container,” which is responsible for presenting a uniform interface between the bean and the server. (Many people use the terms “container” and “server” interchangeably, which is understandable because the difference between them isn’t clearly defined.) The container is responsible for creating new instances of beans, making sure that they are stored properly by the server, and so on. Tools provided by the container’s vendor do a tremendous amount of work behind the scenes. At least one tool will take care of creating the mapping between entity beans and records in your database. Other tools generate a lot of code based on the component interfaces and the bean class itself. The code generated does things like create the bean, store it in the database, and so on. This code (in addition to the stubs) is what actually implements the component interfaces, and is the reason your bean class doesn’t have to
Before going on, lets first establish some conventions. When we speak about an enterprise bean as a whole, its component interfaces, bean class, and so forth, we will call it by its common business name, followed by the word"bean " For example, an enterprise bean that is developed to model a cabin on a ship will be called the " Cabin ejb "notice that we didn 't use a constant width font for Cabin. We do this because we are referring to all the parts of the bean(the component interfaces, bean class, etc. )as a whole, not just one particular part like the remote interface or bean class. The term enterprise bean denotes any kind of bean including entity, session, or message-driven beans. Similarly, entity bean denotes a entity type enterprise bean; session bean a session type enterprise bean; and message-driven bean a message-driven type enterprise bean. It's popular to use the acronym EJB for enterprise bean, a style adopted in this book to distinguish an enterprise bean as a whole from its We will also use suffixes to distinguish between local component interfaces and remote component interfaces. When we are talking about the remote interface of the Cabin Ejb we will use combine the common business name with the word Remote. For example, the remote interface for the Cabin EJB is called the CabinRemote interface In EJB 2.0, the local component interface of the Cabin EJB would be the cabinloca l interface the home interfaces follow the convention by adding the word Home to the mix. The remote and local home the Cabin EJB ald be Cabinhome CabinHomeLocal respectively. The bean class is always the common business name followed by the word Bean. For example, the Cabin EJBs bean The remote interface Having introduced the machinery, lets look at how to build an entity or stateful enterprise bean with remote component interfaces. In this section, we will examine the Cabin EJB, an entity bean that models a cabin on a cruise ship. Lets start with its remote interface We'll define the remote interface for a Cabin bean using the interface abinRemote, which defines business methods for working with cabins remote-interface types extend the javax. ejb EJBObject interface import java rmi RemoteException public interface CabinRemote extends javax. ejb EJBObject t public String getName () throws RemoteException; public void setName(String str) throws RemoteException public int getDeckLevel( throws RemoteException public void setDeckLevel(int level) throws RemoteException These are methods for naming the cabin and methods for setting the cabins deck level; you can probably imagine lots of other methods that you'd need, but this is enough to get started. All of these methods declare that they throw Copyright(c)2001 OReilly Associates
DRAFT, 10/21/017/6/2001 6 Copyright (c) 2001 O'Reilly & Associates Before going on, let’s first establish some conventions. When we speak about an enterprise bean as a whole, its component interfaces, bean class, and so forth, we will call it by its common business name, followed by the word “bean.” For example, an enterprise bean that is developed to model a cabin on a ship will be called the “Cabin EJB.” Notice that we didn’t use a constant width font for “Cabin.” We do this because we are referring to all the parts of the bean (the component interfaces, bean class, etc.) as a whole, not just one particular part like the remote interface or bean class. The term enterprise bean denotes any kind of bean including entity, session, or message-driven beans. Similarly, entity bean denotes a entity type enterprise bean; session bean a session type enterprise bean; and message-driven bean a message-driven type enterprise bean. It’s popular to use the acronym EJB for enterprise bean, a style adopted in this book to distinguish an enterprise bean as a whole from its component parts. We will also use suffixes to distinguish between local component interfaces and remote component interfaces. When we are talking about the remote interface of the Cabin EJB we will use combine the common business name with the word Remote. For example, the remote interface for the Cabin EJB is called the CabinRemote interface. In EJB 2.0, the local component interface of the Cabin EJB would be the CabinLocal interface. The home interfaces follow the convention by adding the word Home to the mix. The remote and local home interfaces for the Cabin EJB would be CabinHomeRemote and CabinHomeLocal respectively. The bean class is always the common business name followed by the word Bean. For example, the Cabin EJB’s bean class would be named CabinBean. The remote interface Having introduced the machinery, let’s look at how to build an entity or stateful enterprise bean with remote component interfaces. In this section, we will examine the Cabin EJB, an entity bean that models a cabin on a cruise ship. Let’s start with its remote interface. We’ll define the remote interface for a Cabin bean using the interface called CabinRemote, which defines business methods for working with cabins. All remote-interface types extend the javax.ejb.EJBObject interface. import java.rmi.RemoteException; public interface CabinRemote extends javax.ejb.EJBObject { public String getName() throws RemoteException; public void setName(String str) throws RemoteException; public int getDeckLevel() throws RemoteException; public void setDeckLevel(int level) throws RemoteException; } These are methods for naming the cabin and methods for setting the cabin’s deck level; you can probably imagine lots of other methods that you’d need, but this is enough to get started. All of these methods declare that they throw
RemoteException, which is required of all methods on remote component Java RMI-IIOP conventions with remote component interfaces, although.on nterfaces, but not EJB 2.0,s local component interfaces. EJB requires the us underlying protocol can be CORBA llOP, Java Remote Method Protocol (RMP) or some other protocol. Java RMl-llOP will be dis cussed in more detail in the next The remote home interface The remote home interface defines life-cycle methods used by clients of entity and session bean for locating enterprise beans. The remote home interface extends javax.ejb. EJBHome. We'll call the home interface for the Cabin bean Cabin remote and define it like this. import java. ml RemoteException; import javax. ejb. CreateExceptic import javax. ejb. FinderException; public interface CabinHameRemote extends javax. ejbEJBHome public Cabin create(Integer id) throws CreateException, RemoteException; ublic Cabin findBy Primarykey (Integer pk) throws FinderException, RemoteException; The create() method will be responsible for initializing an instance of our bean. If your application needs it, you can provide other create ()methods, with different argum In addition to the findByPrimaryKey(), you are free to define other methods that provide convenient ways to look up Cabin beansfor example, you might want to define a method called findByShip()that returns all the cabins on a particular ship. Find methods like these are only used in entity bean and are not used in session bear d obviously not message-driven beans EJB 2.0: The bean class EJB 2.0: The bean class Now lets look at an actual entity bean. Here's the code for the CabinBean; it's rse implementation, but it will shov import javax. ejb EntityContext public abstract class CabinBean implements javax. ejb EntityBean I / EJB 1.0: return void ublic CabinPk ejbCreate(Integer id)I setId (id) Copyright(c)2001 OReilly Associates
DRAFT, 10/21/017/6/2001 Copyright (c) 2001 O'Reilly & Associates 7 RemoteException, which is required of all methods on remote component interfaces, but not EJB 2.0’s local component interfaces. EJB requires the use of Java RMI-IIOP conventions with remote component interfaces, although the underlying protocol can be CORBA IIOP, Java Remote Method Protocol (JRMP), or some other protocol. Java RMI-IIOP will be dis cussed in more detail in the next chapter. The remote home interface The remote home interface defines life-cycle methods used by clients of entity and session bean for locating enterprise beans. The remote home interface extends javax.ejb.EJBHome. We’ll call the home interface for the Cabin bean CabinHomeRemote and define it like this: import java.rmi.RemoteException; import javax.ejb.CreateException; import javax.ejb.FinderException; public interface CabinHomeRemote extends javax.ejb.EJBHome { public Cabin create(Integer id) throws CreateException, RemoteException; public Cabin findByPrimaryKey(Integer pk) throws FinderException, RemoteException; } The create() method will be responsible for initializing an instance of our bean. If your application needs it, you can provide other create() methods, with different arguments. In addition to the findByPrimaryKey(), you are free to define other methods that provide convenient ways to look up Cabin beans—for example, you might want to define a method called findByShip() that returns all the cabins on a particular ship. Find methods like these are only used in entity beans and are not used in session beans -- and obviously not message-driven beans. EJB 2.0: The bean class EJB 2.0: The bean class Now let’s look at an actual entity bean. Here’s the code for the CabinBean; it’s a sparse implementation, but it will show you how the pieces fit together: import javax.ejb.EntityContext; public abstract class CabinBean implements javax.ejb.EntityBean { // EJB 1.0: return void public CabinPK ejbCreate(Integer id){ setId(id);