Sun Microsystems Inc.

•Various services information, such as a transaction and security attributes, are separate from the enterprise bean class. This allows the services information to be managed by tools during application assembly and deployment.

•Client access is mediated by the Container in which the enterprise Bean is deployed.

•If an enterprise Bean uses only the services defined by the EJB specification, the enterprise Bean can be deployed in any compliant EJB Container. Specialized containers can provide additional services beyond those defined by the EJB specification. An enterprise Bean that depends on such a service can be deployed only in a container that supports that service.

•An enterprise Bean can be included in an assembled application without requiring source code changes or recompilation of the enterprise Bean.

•The Bean Provider defines a client view of an enterprise Bean. The Bean developer can manually define the client view or it can be generated automatically by application development tools. The client view is unaffected by the container and server in which the Bean is deployed. This ensures that both the Beans and their clients can be deployed in multiple execution environments without changes or recompilation.

4.1.2 Flexible component model

The enterprise Bean architecture is flexible enough to implement components such as the following:

•An object that represents a stateless service.

•An object that represents a stateless service and whose invocation is asynchronous, driven by the arrival of JMS messages.

•An object that represents a conversational session with a particular client. Such session objects automatically maintain their conversational state across multiple client-invoked methods.

•An entity object that represents a business object that can be shared among multiple clients.

Enterprise beans are intended to be relatively coarse-grained business objects (e.g. purchase order, employee record). Fine-grained objects (e.g. line item on a purchase order, employee’s address) should not be modeled as enterprise bean components.

Although the state management protocol defined by the Enterprise JavaBeans architecture is simple, it provides an enterprise Bean developer great flexibility in managing a Bean’s state.

4.2 Enterprise JavaBeans contracts

This section provides an overview of the Enterprise JavaBeans contracts. The contracts are described in detail in the following chapters of this document.

Sun Microsystems Inc

4.2.1 Client-view contract

This is a contract between a client and a container. The client-view contract provides a uniform development model for applications using enterprise Beans as components. This uniform model enables the use of higher level development tools and allows greater reuse of components.

The enterprise bean client view is remotable—both local and remote programs can access an enterprise bean using the same view of the enterprise bean.

A client of an enterprise bean can be another enterprise bean deployed in the same or different Container. Or it can be an arbitrary Java program, such as an application, applet, or servlet. The client view of an enterprise bean can also be mapped to non-Java client environments, such as CORBA clients that are not written in the Java™ programming language.

The enterprise Bean Provider and the container provider cooperate to create the enterprise bean’s client view. The client view includes:

•Home interface

•Remote interface

•Object identity

•Metadata interface

•Handle

The enterprise bean’s home interface defines the methods for the client to create, remove, and find EJB objects of the same type (i.e. they are implemented by the same enterprise bean) as well as home business methods that are not specific to a particular bean instance. The home interface is specified by the Bean Provider; the Container creates a class that implements the home interface. The home interface extends the javax.ejb.EJBHome interface.

A client can locate an enterprise Bean home interface through the standard Java Naming and Directory InterfaceTM (JNDI) API.

An EJB object is accessible via the enterprise bean’s remote interface. The remote interface defines the business methods callable by the client. The remote interface is specified by the Bean Provider; the Container creates a class that implements the remote interface. The remote interface extends the javax.ejb.EJBObject interface. The javax.ejb.EJBObject interface defines the operations that allow the client to access the EJB object’s identity and create a persistent handle for the EJB object.

Sun Microsystems Inc.

Each EJB object lives in a home, and has a unique identity within its home. For session beans, the Container is responsible for generating a new unique identifier for each session object. The identifier is not exposed to the client. However, a client may test if two object references refer to the same session object. For entity beans, the Bean Provider is responsible for supplying a primary key at entity object creation time[1]; the Container uses the primary key to identify the entity object within its home. A client may obtain an entity object’s primary key via the javax.ejb.EJBObject interface. The client may also test if two object references refer to the same entity object.

A client may also obtain the enterprise bean’s metadata interface. The metadata interface is typically used by clients who need to perform dynamic invocation of the enterprise bean. (Dynamic invocation is needed if the classes that provide the enterprise client view were not available at the time the client program was compiled.)

Message-driven beans have no home or remote interface and hence no client view in the sense of this section. A client can locate the JMS Destination to which it should send messages that are to be delivered to a message-driven bean by means of the standard JNDI API.

4.2.2 Component contract

This subsection describes the contract between an enterprise Bean and its Container, and, in the case of an enterprise Bean with container managed persistence, between an enterprise Bean and its Persistence Manager. The main requirements of the contract follow. (This is only a partial list of requirements defined by the specification.)

•The requirement for the Bean Provider to implement the business methods in the enterprise bean class. The requirement for the Container provider to delegate the client method invocation to these methods.

•For message-driven beans, the requirement for the Bean Provider to implement the onMessage method in the enterprise bean class. The requirement for the Container provider to invoke this method when a message has arrived for the bean to service.

•The requirement for the Bean Provider to implement the ejbCreate<METHOD>, ejbPostCreate<METHOD>, ejbHome<METHOD>, and ejbRemove methods, and to implement the ejbFind<METHOD> methods if the bean is an entity with bean-managed persistence. The requirement for the Container provider to invoke these methods during an EJB object creation, removal, and lookup.

•The requirement for the Bean Provider to provide abstract accessor methods for persistent fields and relationships for an entity with container-managed persistence. The requirement for the Persistence Manager Provider to provide the implementation of these methods.

•The requirement for the Bean Provider to provide a description of the relationships that are to be implemented by the Persistence Manager. The requirement for the Persistence Manager Provider to implement the relationships described by the Bean Provider.

[1]In some situations, the primary key type can be specified at deployment time (see subsection 9.10.1.3).

Sun Microsystems Inc

•The requirement for the Bean Provider to define the enterprise bean’s home and remote interfaces, if the bean is an entity bean or a session bean. The requirement for the Container Provider to provide classes that implement these interfaces.

•For sessions, the requirement for the Bean Provider to implement the Container callbacks defined in the javax.ejb.SessionBean interface, and optionally the javax.ejb.SessionSynchronization interfaces. The requirement for the Container to invoke these callbacks at the appropriate times.

•For message-driven beans, the requirement for the Bean Provider to implement the Container callbacks defined in the javax.ejb.MessageDrivenBean interface.

•For entities, the requirement for the Bean Provider to implement the Container callbacks defined in the javax.ejb.EntityBean interface. The requirement for the Container to invoke these callbacks at the appropriate times.

•The requirement for the Persistence Manager Provider to implement persistence for entity beans with container-managed persistence.

•The requirement for the Container Provider to provide the javax.ejb.SessionContext interface to session bean instances, the javax.ejb.EntityContext interface to entity bean instances, and the javax.ejb.MessageDrivenContext interface to mes- sage-driven bean instances. The context interface allows the instance to obtain information from the container.

•The requirement for the Container to provide to the bean instances the JNDI context that contains the enterprise bean’s environment.

•The requirement for the Container to manage transactions, security, and exceptions on behalf of the enterprise bean instances.

•The requirement for the Bean Provider to avoid programming practices that would interfere with the Container’s runtime management of the enterprise bean instances.

•The requirement for the Bean Provider of entity beans with container-managed persistence to avoid programming practices that would interfere with the Persistence Manager’s runtime management of the state of the entity beans.

4.2.3 Ejb-jar file

An ejb-jar file is a standard format used by EJB tools for packaging enterprise Beans with their declarative information. The ejb-jar file is intended to be processed by application assembly and deployment tools.

The ejb-jar file is a contract used both between the Bean Provider and the Application Assembler, and between the Application Assembler and the Deployer.

The ejb-jar file includes: