Enterprise JavaBeans

Enterprise JavaBeans is an important part of J2EE. It provides an environment in which components from several manufacturers can be assembled into a working application. The application assembler, with deep knowledge of the requirements of the business, can choose the component that best matches the task at hand. For instance, she could use transaction-processing beans from one company; customer, order, and product beans from another company; and shipping beans from a third company. She would then end up with an application capable of accepting orders, charging the customer, and process shipments without having to write code.

Enterprise beans are specialized components that can encapsulate session information, workflow, and persistent data. A bean client is an application that uses enterprise beans to access database data or an enterprise bean that relies on the functionality provided by another enterprise bean. An enterprise bean has three parts:

• The home interface is used by the client to create and discard beans.

• The remote interface is used by the client to execute the bean’s business methods.

• The implementation or bean class is where the bean’s business methods and callback methods are implemented. The client never invokes these methods directly; they are invoked by the bean container.

The container is a conceptual entity that mediates between enterprise-bean instances and client applications. Clients never access bean instances directly. Instead, they interact with proxies provided by the container. This allows the bean container to perform its duties in the most efficient way. The client doesn’t have to know how the container implements its functions; all it needs to know is how to talk to the container.

In addition, beans have a deployment descriptor. This is an XML file that gives the container information about each bean and data-source connection details, among many other items.

There are two major types of enterprise beans: session beans and entity beans.

• Session beans come in two flavors: stateful and stateless. Stateful session beans maintain state between method invokations; stateless session beans do not.

  Stateless session beans are useful for grouping related methods in one place. Stateful session beans can be used to encapsulate workflow. In most cases it’s more efficient for client applications to use session beans (stateless or stateful) to accomplish their tasks than to use entity beans directly because network traffic is reduced.

• Entity beans are similar to enterprise objects (the objects that represent an instance of a data entity in Enterprise Objects). They encapsulate access to data stored in databases and other types of data stores.

An enterprise-bean developer can focus on the high-level business logic needed to implement the services that a bean provides instead of on low-level system or data- store calls (those functions can be left to the container).

One of the most important functions of the container is transaction management and access control. WebObjects includes the OpenEJB open-source container system. OpenEJB consists of four main components:

• EJB container: The EJB container implements the lifecycle of enterprise beans and the server contracts in the EJB specification.

• Object Request Broker (ORB): The OpenORB object request broker implements RMI-over-IIOP, naming service, and CORBA ORB.

• Transaction manager: The Tyrex transaction manager implements a transaction manager compliant with the Java Transaction API (JTA) and Object Transaction Service (OTS) specifications.

• Persistence manager: The Castor JDO persistence manager implements bean persistence for entity beans. It’s used in the implementation of CMP (container-managed persistence) beans.

Enterprise JavaBeans in WebObjects

You can use WebObjects development tools to develop enterprise beans from scratch or to integrate third-party EJB-based solutions in a WebObjects application. Bean development in WebObjects is divided in two phases: development and deployment.

You develop enterprise beans by writing .java files and deployment descriptor files. Project Builder provides you with templates for these files. You can also obtain the source code or JAR files for enterprise beans from a third party. As an alternative, you can develop data models from which entity-bean source files can be generated. For more information, see Developing an Entity Bean From a Data Model.

You deploy one or more beans by generating a bean framework, which contains the beans’ JAR files and deployment descriptor files, and placing it somewhere in a development computer’s file system; for example, in /Library/Frameworks. After you deploy a bean framework, it’s available to be integrated in client applications or other enterprise beans for their use.

Client applications can be developed in two ways: using an internal bean container, or using an external container:

• Internal container: This approach is the most scalable because each application instance has its own container and naming-service object.

  If the user load of your site becomes too large for one instance to handle, all you have to do is add more instances of it. Each container answers only to one application, so there is no application-to-container bottleneck.

• External container: This approach is beneficial if you already have a robust bean container, running on a fast computer, that you want to leverage. In this case, no configuration files should be present in the bean-client application project. For more on the configuration files, see Configuring Applications.