Search our
entire site
Enter your search
terms below, or visit
our search page

Search case
studies only
Enter your search
terms below:

For the table
of contents and
hyperlinks to
general topics
proceed to toc

SUN

AUGUST 1998

Distributed Java component model

It doesn't always happen this way, but when Sun Microsystems raised Enterprise JavaBeans (EJB) up the flagpole, some really big vendors saluted. That's not surprising -- many of those vendors helped to put the flag together -- but one might legitimately wonder whether EJB is the outstanding technology we are told it is.

Depending on their design, EJB servers could compete directly with Microsoft Transaction Server (MTS), Microsoft's Component Object Model (COM)-based transaction manager. On a larger scale, however, the EJB "container" model correlates closely with Microsoft's notion of "interception," a service-addition layer that the company is putting forth as a key element in its upcoming COM+ framework. This makes it a battle of server-side component models.

Stepping back a few more paces, EJB's tight mappings to CORBA's Object Transaction Service (OTS) and Internet Inter-ORB Protocol (IIOP) suggest the real contenders will be full distributed component frameworks -- EJB and IIOP on one side, COM+ on the other. In that case, EJB becomes a pivotal player in the enterprise development platform contest and deserves close inspection.

THE MODEL. Enterprise JavaBeans are Java components that fit together in a standard way, and the container provides a portability layer that lets anyone's beans operate in anyone else's container. To look at EJB from the perspective of a platform strategy, the beans themselves are relatively unimportant. They need to use the proper semantics and naming conventions, and of course they encapsulate your business logic, but it's the container that makes EJB what it is.

Containers are software receptacles that know how to communicate with and manage the beans, a fact that adds significant value to the component proposition. The container places itself between the client and the bean, which gives it the opportunity to implement services most corporate application developers would rather not worry about. These include persistence management, transactions, concurrency, thread management, and security, among other things. Of central importance, EJB extends JavaBeans by letting container-based objects communicate with each other via a network.

EJB container vendors seem to be coming from every direction, including traditional transaction-processing monitor vendors such as BEA Systems and IBM; Web application server vendors such as Netscape, NetDynamics, and WebLogic; database vendors such as Sybase and Oracle; and CORBA object request broker (ORB) vendors such as Inprise (formerly Borland).

BETTING ON JAVA. To explore the inner workings of EJB and to evaluate whether it holds serious promise as an enterprise component model, we developed an online gambling application that simulates a business-to-consumer commerce site. The client is a standard Java application and the server is an EJB object. It is a fairly simple application, but it helps highlight a few key features of EJB.

We chose WebLogic's Tengah 3.0.4 Java application server for our container, which provided EJB support at the 0.8 level. The differences between 0.8 and 1.0 did not affect the operation of our application.

We also enlisted the help of huge EJB-proponent IBM, which let us dissect the company's J-Store demo. J-Store is a simulated online-shopping service in which EJBs handle the business objects while Java servlets and JavaServer Pages take care of the page transmission and display logic. The application authenticates users, lets them browse GIF images and load items into a shopping cart, and tallies up the sale. The EJBs ran in a custom EJB container that is not currently an official IBM offering. One interesting aspect of the application is its use of servlets to act as clients to the EJBs, which lets you stay away from requiring Java support on the browsers.

UNDER WRAPS. The container is central to EJB, and the features that let the container interpose itself between the client and the bean are the "home" and "remote" interfaces. By design, beans that a client has created (called into service) do not expose their methods (functions) directly to the client. Instead, the container exposes the methods of the remote interface, which the developer or application assembler implements ahead of time via a utility provided by the container vendor. This is known as "wrapping" the object, and the implementation of the remote interface is referred to as the EJB object. The home interface, also built and implemented ahead of time, lets the client create or remove the object and discover details about the object's workings.

To find the bean's home interface in the first place, the client appeals to the container via the Java Native Directory Interface (JNDI) and then requests the bean's location.

Our application's server bean, "Bet," ran alone inside the Tengah container, but it is important to note that EJB lets multiple beans run side by side in a given container and lets multiple containers run on a given server. We were initially confused by the Tengah documentation, which stated that each EJB was associated with one and only one container, until we realized that the word container in the EJB-0.8 specification referred to the Container interface, which changed to the remote interface in Version 1.0.

Had our application required it, or had multiple clients needed to activate the bean, the container could have created multiple instances of Bet and then associated Bet objects to service the additional load. The capability of EJB containers to dynamically manage the creation and destruction of server objects gives them the potential to scale well with increasing demand. It also means bean programmers don't need to worry about the number of clients activating a bean; you write beans as if only one client will use them.

An additional advantage of wrapping is that an EJB doesn't know it is remotely accessible (that is, accessible across a network), because it is not required to expose its remote interface directly. Perhaps more to the point, the developer is freed from handling the low-level details of remote activation, because the container implements the necessary interfaces.

BEAN FLAVORS. EJB containers conforming to the 1.0 standard must support "session" beans, objects that generally retain their state only as long as a client is requesting their services. Version 2.0 will require support for "entity" beans, which permanently store their state and are able to persist indefinitely. Some vendors, WebLogic and IBM in particular, are implementing entity beans in the first go-around.

Session beans come in two flavors: stateless and stateful. The term "state" refers to the data an object carries with it. In the context of a session bean, it means "conversational" parameters passed to and from clients and between methods during the course of its operation.

A stateless bean is perfectly anonymous: It looks the same to a client before and after an operation. The bean's methods can receive and return parameters, but the storage of those parameters is transient. Applications that implement stateless beans should generally scale better, because the container can activate and deactivate multiple instances of a stateless bean on the fly and based on demand.

Stateful session beans, on the other hand, are semipersistent in that the developer can have them swap their parameters to disk, temporarily retirebring the beans and data back ("activate" them) when needed. A container may also passivate beans automatically. Stateful session beans can access persistent resources such as database tables, sockets, and files, but the beans do not actually represent the data. Session beans of both types are lost if the server crashes. Both types of session beans execute on behalf of a single client; two clients may not access the same instance of a session bean.

Our betting application used a stateless session bean and stored state information, such as the user's log-in name, on the client. Of course, we could just as well have made our bean stateful, stored parameters on the bean, and passed the parameters directly among methods. The choice generally depends on how much load you want to place on the client and on the wire.

Entity beans differ in that they do represent "persistent data," which in this case can mean stored data or it can mean an application that the bean accesses through function calls. Because the data is permanently stored, the object will survive server crashes. Further, multiple clients can access a single entity bean concurrently via a pool of instances. When a client activates the object, the container makes sure an instance is bound to the current data and passes its interface to the client.

Entity beans have powerful implications for incorporating legacy data and code into an EJB framework. It might not be easy -- for bean-managed persistence someone will have to write custom access calls in the bean's methods -- but it might be easier than recoding or regenerating the data. Another possibility is for the container to generate access calls when entity beans are installed in the container, but this places the burden of writing the calls on the vendor. The current specification does not require the container to manage persistence on behalf of the bean, so vendors are off the hook unless they want to provide this as a value-add.

CONTAIN AND CONTROL. One of the good things about having a container provide services is that you can tell the container at deployment time how to treat your components rather than tell your components at development time how to act. This is known as attribute-based or declarative programming, and it's darned convenient. For example, the container needs to know if each session bean is stateful or stateless so it can decide whether to passivate and activate it, among other things. The person deploying the application informs the container of a bean's state situation through the bean's deployment descriptor file.

Transaction management is another EJB feature that you can specify at deployment time. Transaction support in EJB conforms to a subset of the CORBA Java Transaction Service (JTS), the Java-language mapping of OTS.

Transaction support in EJB ensures that operations performed on important stored data are protected in the event of system, network, or application failure. EJB containers may implement a two-phase-commit protocol, which transaction-processing monitors have used for years to manage all-or-nothing changes to distributed stored data. (The EJB specification currently only requires flat transactions, which makes EJB support easier for database and transaction server vendors that do not currently support nested transactions.)

The truly valuable feature of EJB's container framework for transactions, though, isn't the declarative programming model per se but the capability to automatically start, stop, suspend, commit, and rollback transactions on behalf of components. If an object represents an important piece of durable data, you can tell the container that the bean must always participate within the boundaries of a transaction. The transaction boundaries bracket the operations that happen between the start and end of a transaction, when persistent resources involved in the transaction such as database records are either committed via a two-phase-commit operation or aborted via a rollback. If a bean must participate in a transaction but the caller does not pass a transaction "context" to the object, the container simply starts one up.

EJB defines five other transaction attributes that you assign to beans when you package them. Note that the client is the program that invokes a method on an object. The client may or may not be a remote program. Here is the complete list:

• Not_Supported. The bean cannot run within the client's transaction. If the client is running within a transaction, the container suspends the client's transaction until the bean finishes executing, then resumes the client's transaction. The container doesn't propagate the transaction to objects called by this bean.
• Bean_Managed. The bean can set transaction boundaries but cannot run within the client's transaction. If the client is running within a transaction, the container suspends the client's transaction, resumes the bean's transaction, lets the bean execute, suspends the bean's transaction, and then resumes the client's transaction. The container doesn't propagate the transaction to objects called by this bean.
• Required. The bean must operate within a transaction. If the client is running within a transaction, the bean will inherit the client's transaction. If the client isn't running within a transaction, the container begins a new transaction for the bean, lets the bean execute, then ends the bean's new transaction.
• Supports. The bean may operate within a transaction, but it is not required. If the client is running within a transaction, the bean inherits the client's transaction. If the client is not running within a transaction, the bean does not run within a transaction.
• Requires_New. The bean must operate within a new transaction. If the client is running within a transaction, the container suspends the client's transaction, begins a new transaction for the bean, lets the bean execute, ends the bean's new transaction, then resumes the client's transaction. If the client is not running within a transaction, the container begins a new transaction for the bean, lets the bean execute, then ends the bean's new transaction.
• Mandatory. The bean must operate within the client's transaction. If the client is running within a transaction, the bean inherits the client's transaction. If the client is not running within a transaction, the container throws an exception. Note it is possible to assign transaction attributes to entire beans or to individual methods within a bean. In our betting application, we wanted to ensure that the user's bets made it safely into our database, so we specified a transaction attribute of Required, set on the entire bean.

SUGGESTIVE, NOT PRESCRIPTIVE. Support for implicit transactions across heterogeneous servers makes great sense for transaction servers, databases, and application servers. On the other hand, not all potential EJB environments will have much use for transactions, nor will all vendors want to implement distributed two-phase-commit protocols in their products. Because EJB does not specify the implementation of the JTS interface, this is not a limitation. But because "supports EJB" is not an automatic prescription for robust transactions, be sure to read the label. Transactional capabilities combined with thread management, load-balancing, and fail-over protection already present in today's enterprise-duty middleware and back-end systems define an area in which would-be EJB container vendors can differentiate their products.

Security is partially left as an exercise for the container vendor. EJB specifies standard Java security interfaces, and the container does the job of mapping instances of the appropriate class to individual user accounts or groups on the server. But because the mapping depends on the security implementation of the container, you cannot count on EJB to provide the bomb-proof yet flexible security system you might want.

A second way in which a developer can introduce security is by programming EJB methods that interrogate a client for its identity, but this seems like a throwback compared to a third method, security attributes the application assembler sets through the deployment descriptor. These also rely on the security implementation of the container or DBMS.

BET THE BUSINESS ON JAVA? In EJB, Sun has delivered a distributed component model that stands to make Java a genuine IT strategy. Transactions, security, component distribution, and object persistence all collaborate to make EJB an intriguing technology. The EJB servers and tools we have seen so far go above and beyond the call of the specification, which is an encouraging sign and indicates that this is a framework vendors are willing to get behind. If you are looking for a way to distribute platform-neutral, server-side components, EJB is the technology to watch.