JavaBeans

1. Building a bevy of beans 1
2. Building a bevy of beans 2

• Take an in-depth look at the Java Reflection API

Exterprise JavaBeans

•  THE CUTTING EDGE - Enterprise JavaBeans

• The Java™ Naming and Directory Interface (JNDI)

Exterprise JavaBeans Specifications (excerpts)

Goals

Overall goals for the Enterprise JavaBeans (EJB) architecture:

• Enterprise JavaBeans will be the standard component architecture for building distributed object-oriented business applications in Java. Enterprise JavaBeans will make it possible to build distributed applications by combining components developed using tools from different vendors.
• Enterprise JavaBeans will make it easy to write applications: Application developers will not have to understand low-level transaction and state management details; multi-threading; resource pooling; and other complex low-level APIs. However, an expert-level programmer will be allowed to gain direct access to the low-level APIs.
• Enterprise JavaBeans applications will follow the “write-once, run anywhere” philosophy of Java. An enterprise bean can be developed once, and then deployed on multiple platforms without recompilation or source code modification.
• The Enterprise JavaBeans architecture will address the development, deployment, and runtime aspects of an enterprise application’s life cycle.
• The Enterprise JavaBeans architecture will define the contracts that enable tools from multiple vendors to develop and deploy components that can interoperate at runtime.
• The Enterprise JavaBeans architecture will be compatible with existing server platforms. Vendors will be able to extend their existing products to support Enterprise JavaBeans.
• The Enterprise JavaBeans architecture will be compatible with other Java APIs.
• The Enterprise JavaBeans architecture will provide interoperability between enterprise beans and non-Java applications.
•  The Enterprise JavaBeans architecture will be compatible with CORBA.

Goals for Release 1.0

• Define the distinct “roles” that are assumed by the component architecture.
• Define the client’s view of enterprise beans.
• Define the enterprise bean developer’s view.
• Define the responsibilities of an EJB container provider and server provider; together these make up a system that supports the deployment and execution of enterprise beans.
• Define the format of the ejb-jar file, EJB’s unit of deployment.

Session and entity objects

• A session object type.
• An entity object type.

Session objects

• Executes on behalf of a single client.
• Can be transaction-aware.
• Updates shared data in an underlying database.
• Does not represent directly shared data in the database, although it may access and update such data.
• Relatively short-lived.
• Is removed when the EJB server crashes. The client has to re-establish a new session object to continue computation.

Entity objects

• Represents data in the database.
• Transactional.
• Shared access from multiple users.
• Can be long-lived (lives as long as the data in the database).
• Survives crashes of the EJB server. A crash is transparent to the client.

Roles and scenarios

Roles

Enterprise bean provider

An enterprise bean provider is typically an application domain expert. An enterprise bean provider develops reusable components called enterprise beans. An enterprise bean implements a business task, or a business entity.

An enterprise bean provider is not an expert at system-level programming. Therefore, an enterprise bean provider usually does not program transactions, concurrency, secu-rity, distribution and other services into the enterprise beans. An enterprise bean pro-vider relies on an EJB container provider for these services.

The output of an enterprise bean provider is an ejb-jar file that contains enterprise beans. Each bean includes its Java classes, its remote and home interfaces, its deploy-ment descriptor, and its environment properties. The enterprise beans must conform to the Enterprise JavaBeans component contract to ensure that they can be installed into any compliant EJB container.

Application assembler

An application assembler is a domain expert who composes applications that use enter-prise beans. The application assembler works with the enterprise bean’s client view contract. Although the assembler must be familiar with the functionality provided by the enterprise beans’ remote and home interfaces, he or she does not have to have any knowledge of the enterprise beans’ implementation.

The output of the application assembler can be new enterprise beans, or applications that are not enterprise beans (for example, servlets, applets, or scripts). The assembler may also write a GUI for the applications.

The application assembly can be done before or after the deployment of the enterprise beans into an operational environment.

Deployer

A deployer is an expert at a specific operational environment, and is responsible for the deployment of enterprise beans and their containers. A deployer typically uses tools provided by the container provider to adapt enterprise beans to a specific operational environment.

For example, a deployer is responsible for mapping the security roles assumed by the enterprise beans to those required by the organization that will be using the enterprise beans. A deployer typically reads the attribute settings in the enterprise beans’ deploy-ment descriptors and modifies the values of the enterprise beans’ environment proper-ties. In some cases, a qualified deployer may customize the business logic of the enterprise beans at their deployment. Such a deployer would typically use the container tools to write relatively simple application code that wraps the enterprise bean’s business methods.

EJB server provider

An EJB server provider is a specialist in the area of distributed transaction manage-ment, distributed objects, and other lower-level system-level services. A typical EJB server provider is an OS vendor, middleware vendor, or database vendor. Typically, the EJB server provider will provide a container that implements the EJB session container[4.2.2] contract, and may also provide an entity container[4.2.2] for one or more data sources supported on the EJB server. An EJB server provider will typically publish its lower-level interfaces to allow third parties to develop containers. These interfaces are not currently specified by Enterprise JavaBeans and are vendor specific. A later release of Enterprise JavaBeans may standardize the interfaces between a container and an EJB server.

EJB container provider

The expertise of a container provider is system-level programming, possibly combined with some application-domain expertise. The focus of a container provider is on the de-velopment of a scalable, secure, transaction-enabled container system. The container provider insulates the enterprise bean from the specifics of an underlying EJB server by providing a simple, standard API between the enterprise bean and the container (this API is the Enterprise JavaBeans component contract). For enterprise entity beans with container-managed persistence, the entity container is responsible for persistence of the entity beans installed in the container. The container provider’s tools are used to generate code that moves data between the enterprise bean’s instance variables, and a database or an existing application. The container provider may be an expert in the area of providing access to enterprise’s existing data sources or application systems (such as CICS or SAP). A container provider is responsible for providing support for versioning of enterprise beans. For example, the container provider should allow enterprise bean classes to be upgraded without invalidating existing clients or losing existing enterprise bean ob-jects.

The container provider typically provides tools that allow the system administrator to monitor and manage the container and the beans running in the container at runtime. Enterprise JavaBeans defines the component contract that must be supported by every compliant EJB container. Enterprise JavaBeans allows container vendors to develop specialized containers that extend this contract. Examples of specialized containers in-clude a container that supports an application-domain specific framework, a container that bridges the EJB environment with an existing application system (such a container allows modeling of the existing applications as enterprise beans), a container that im-plements an Object/Relational mapping, or container that is built on top of an object-oriented database system.

System administrator

The role of a system administrator is to oversee the well-being of a running system. The system administrator typically uses runtime monitoring and management tools provid-ed by the EJB server and container providers to accomplish this task.

Scenario 1: Development, deployment, assembly

Wombat sells the enterprise beans to banks that may use containers and EJB servers from multiple vendors. One of the banks uses a container from the Acme Corporation. Acme’s tools that are part of Acme’s container product facilitate the deployment of en-terprise beans from any provider, including Wombat Inc. The deployment process re-sults in generating additional classes used internally by the Acme container. The additional classes allow the Acme container to manage enterprise bean objects at runt-ime, as defined by the EJB component contract.

Since the AccountBean and TellerBean enterprise beans by themselves are not a com-plete application, the bank MIS department may use Acme’s tools to assemble the Ac-countBean and TellerBean enterprise beans with other enterprise beans (possibly from another vendor) and possibly with some non-EJB existing software, into a complete ap-plication. The MIS department takes on both the EJB deployer and application assem-bler roles.
 

Fundamentals

Enterprise beans as components

Component characteristics

• An enterprise bean is contained and managed at runtime by a container.
• An enterprise bean can be customized at deployment time by editing its environment properties.
• Various metadata, such as a transaction mode and security attributes, are separated out from the enterprise bean class. This allows the metadata to be manipulated using container’s tools at design and deployment time.
• Client access is mediated by the container and the EJB server on which the enterprise bean is deployed.
• If an enterprise bean uses only the standard container 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 the service.
• An enterprise bean can be included in a composite application without requiring source code changes or recompilation of the enterprise bean.
• A client’s view of an enterprise bean is defined by the bean developer. Its view is unaffected by the container and server the bean is deployed in. This ensures that both beans and their 100% Pure Java TM clients are write-once-run-anywhere.

Flexible component model

• An object that represents a stateless service.
• An object that represents a conversational session with a particular client. Such session objects automatically maintain their conversational state across multiple client-invoked methods.
• A persistent entity object that is shared among multiple clients.

A client always uses the same API for object creation, lookup, method invocation, and destruction, regardless of how an enterprise bean is implemented, and what function it provides to the client.

Enterprise JavaBeans contracts

Client’s view contract

Both the enterprise bean provider and the container provider have obligations to fulfill the contract. This contract includes:

• Object identity.
• Method invocation.
• Home interface.

An enterprise bean and its container cooperate to implement the create, find, and re-move operations callable by clients.

An enterprise bean provider defines a remote interface that defines the business meth-ods callable by a client. The enterprise bean provider is also responsible for writing the implementation of the business methods in the enterprise bean class. The container is responsible for allowing the clients to invoke an enterprise bean through its associated remote interface. The container delegates the invocation of a business method to its im-plementation in the enterprise bean class.

An enterprise bean provider is responsible for supplying an enterprise bean’s home in-terface. The enterprise bean’s home interface extends the javax.ejb.EJBHome inter-face. A home interface defines zero or more create(...) methods, one for each way to create an EJB object. A home interface for entity beans defines zero or more finder methods, one for each way to lookup an EJB object, or a collection of EJB objects of a particular type.

The enterprise bean provider is responsible for the implementation of the ejbCreate(...) methods in the enterprise bean class, whose signature must match those of the cre-ate(...) methods defined in the bean’s home interface. The container is responsible for delegating a client-invoked create(...) method to the matching ejbCreate(...) method on an enterprise bean instance.

The enterprise entity bean provider is responsible for the implementation of the ejbFindMETHOD(...) methods in the enterprise bean class, whose signature must match those of the findMETHOD(...) finder methods defined in the bean’s home inter-face. The container is responsible for delegating a client-invoked findMETHOD(...) method to the matching ejbFindMETHOD(...) method on an enterprise bean instance.

Component contract

• An enterprise bean class instance’s view of its life cycle. For a session enterprise bean, this includes the state management callbacks defined by the javax.ejb.SessionBean and javax.ejb.SessionSynchronization interfaces. For an entity enterprise bean, this includes the state management callbacks defined by the javax.ejb.EntityBean interface. The container invokes the callback methods defined by these interfaces at the appropriate times to notify the instance of the

important events in its life cycle.
• The javax.ejb.SessionContext interface that a container passes to a session enterprise bean instance at instance creation. The instance uses the SessionContext interface to obtain various information and services from its container. Similarly, an entity instance uses the javax.ejb.EntityContext interface to communicate with its container.
• The environment java.util.Properties that a container makes available to an enterprise bean.
• A list of services that every container must provide for its enterprise beans.

Ejb-jar file

The ejb-jar contract includes:

• JAR file manifest entries that describe the contents of the ejb-jar file.
• Java class files for the enterprise beans.
• Enterprise beans’ deployment descriptors. A deployment descriptor includes the declarative attributes associated with an enterprise bean. The attributes instruct the container how to manage the enterprise bean objects.
• Enterprise beans’ environment properties that the enterprise bean requires at runtime.

Note that while the figure illustrates only a remote client running outside of the contain-er, the client-side API is also applicable to clients who themselves are enterprise beans installed in an EJB container.