When the client calls a method on an EJB object, the EJB object method communicates with the remote EJB container, requesting that the same method be called, on the appropriate remote EJB, with the same arguments, on the client's behalf. See Figure 3 for a pictorial representation of this arrangement. There are two basic types of Enterprise JavaBeans: session beans and entity beans.
These two types of beans play different roles in a distributed EJB application. A session bean is an EJB instance associated with a single client. Session beans typically are not persistent although they can be , and may or may not participate in transactions.
In particular, session objects generally don't survive server crashes. One example of a session object might be an EJB living inside a Web server that serves HTML pages to a user on a browser, and tracks that user's path through the site. When the user leaves the site, or after a specified idle time, the session object will be destroyed.
Note that while this session object might be storing information to the database, its purpose is not to represent or update existing database contents; rather, it corresponds to a single client performing some actions on the server EJBs.
An entity bean represents information persistently stored in a database. Entity beans are associated with database transactions, and may provide data access to multiple users. Since the data that an entity bean represents is persistent, entity beans survive server crashes this is because when the server comes back online, it can reconstruct the bean from the underlying data. In an object-oriented database OODB , an entity bean may represent a single object, with its associated attributes and relationships.
An example of an entity bean might be an Employee object for a particular employee in a company's Human Resources database. An Enterprise JavaBeans client creates EJB objects on the server we'll see how in just a moment and manipulates them as if they were local objects. This makes developing EJB clients almost as easy as writing a client that runs locally: the developer simply creates, uses, and destroys objects, but these objects have counterparts executing on a server that do the actual work.
Session beans manage information relating to a conversation between the client and the server, while entity beans represent and manipulate persistent application domain data. One way to conceptualize this is that entity beans replace the various sorts of queries used in a traditional two- or three-tier system, and session beans do everything else. Every EJB has a unique identifier.
For entity beans, this unique identifier forms the identity of the information. This is analogous to the concept of a primary key in a relational database system. A session bean's unique identifier is whatever distinguishes it from other beans of its type: it may be the host name and port number of a remote connection, or even just a randomly-generated key that the client uses to uniquely identify a given bean. So, a client program contacts a server and requests that the server create an Enterprise JavaBean to do data processing on its behalf.
The server responds by creating the server-side object the EJB component instance , and returning a proxy object the EJB object whose interface is the same as the EJB component's and whose implementation performs remote method invocations on the client's behalf.
The client then uses the EJB object as if it were a local object, "never knowing" that a remote object is actually doing all the work. How does a client program create objects on a server? Operations involving the life cycle of server-side beans are the responsibility of the EJB container.
The client program actually contacts the container and requests that a particular type of object be created, and the container responds with an EJB object that can be used to manipulate the new EJB component. EnterpriseBean interface. This is usually done indirectly, through either the javax. SessionBean interface or the javax. EntityBean interface. In our example, we're defining a session bean, so the ProfileServerBean class implements the SessionBean interface.
The EJB class must be declared as public , to allow the container to introspect the class when generating the classes that hook the bean to the container and to allow the container to invoke methods on the bean directly where necessary.
The bean class can optionally implement the bean's remote interface, but this isn't strictly required. In our case, we haven't implemented the bean's remote ProfileServer interface in the ProfileServerBean class. When the EJB server generates the classes that bridge the bean to the container, it also provides a class that implements the remote interface and acts as a proxy to the EJB class itself. This is server-dependent, however, so there's no guarantee that this will help or hurt.
In fact, for practical reasons, you probably don't want your EJB implementation to implement the remote interface for your bean. The remote interface has to extend the EJBObject interface, which includes a set of abstract methods that clients can use to retrieve the bean's home interface, get the primary key for entity beans, etc. When you deploy your bean, you'll use tools provided by the EJB container tools to generate stub and skeleton classes for the remote interface that implement these methods from EJBObject.
If you implement the remote interface with your bean implementation class, you have to provide implementations for the EJBObject methods as well. All Enterprise JavaBean objects, whether they are session beans or entity beans, must implement the following methods:. Called by the container when the bean has been deserialized from passive storage on the server. Allows the bean to reclaim any resources freed during passivation e.
Called by the container just before the bean is to be serialized and stored in passive storage e. Allows the bean to release any non-serializable resources e. Called after the client invokes one of the create methods on the bean's home interface. Session beans are required to provide at least one create method, but create methods are optional on entity beans, since entity beans can also be acquired using finder methods.
The container creates the bean object using one of its standard constructors and might create several beans of the same type at server startup to act as a pool for future client requests. The ejbCreate method indicates that a client is ready to use the bean; the arguments indicate the identity or starting state of the bean. For entity beans, the return type of an ejbCreate method should be the bean's primary key type see the later section "Implementing Entity Beans" for more details.
Called by the container just before the bean is to be removed from the container and made eligible for garbage collection. The container may call this when all remote and local references to the bean have been removed. These methods are used by the bean's container to notify the bean of various changes in its runtime state. Instead, the purpose of these methods is to provide a way to retrieve information that is not related to a single entity bean instance.
When the client invokes any home interface business method, an entity bean is removed from the pool to service the request. Thus, this method can be used to perform operations on general information related to the bean. For example, in an employee application, you might provide the local home interface with a create , findByPrimaryKey , findAll , and calcSalary methods. The calcSalary method is a home interface business method that calculates the sum of all employee salaries.
It does not access the information of a particular employee, but performs a SQL query against the database for all employees. The remote home interface extends javax. The local home interface extends javax. A remote client invokes the EJB through its remote interface. The client invokes the create method that is declared within the remote home interface. The container passes the client call to the ejbCreate method—with the appropriate parameter signature—within the bean implementation.
The requirements for developing the remote home interface include the following:. The remote home interface must extend the javax.
0コメント