This past winter, I wrote a series of columns about the Microsoft Transaction Server (MTS) platform for deploying application components on the middle tier of a three-tier architecture ("Keeping Active," December 1997; "Tiers Without Tears," February 1998; and "MTS Matures," April 1998). In that series, I described a class-based programming model for component-based development in which MTS provided a runtime environment for the objects I developed to satisfy a series of business requirements. By delivering a programming language that made it relatively easy to create COM objects and a low-cost, easy-to-manage middle-tier application server, Microsoft substantially lowered the entry level for distributed object systems.
The Java camp has now delivered a set of technologies and tools that will let business application developers using Java develop multitier applications with a minimum of fuss. Sun's JavaSoft unit has developed the core technology infrastructure, which it refers to as the Java Platform for the Enterprise (JPE). The Enterprise JavaBean (EJB) specification is the centerpiece of the JPE, which promises to simplify the development of multitier application systems capable of supporting high-volume business transactions. In addition to EJB, the JPE technologies include Remote Method Invocation (RMI), Java Directory and Naming Interface (JNDI), Java Database Connectivity (JDBC), Java Transaction Service (JTS), and Java Messaging.
I recently had a series of discussions with vendors poised to deliver products that fulfill the promise of the EJB specification. These products will extend the technical foundation for n-tier application development with Java and CORBA and will equip developers with a set of robust high-productivity tools for undertaking these types of projects. Among the traditional suppliers of development tools and deployment platforms, IBM and Inprise (formerly Borland International) are investing heavily in enabling their development tools and deployment platforms for the JPE. Similarly, database providers Oracle and Sybase are retooling their product lines to support Java in significant ways.
A number of relatively young, small companies such as Weblogic, Novera, and Persistence are developing runtime deployment environments targeted at middle-tier applications and services. Finally, several companies are making significant investments aimed at realizing a long-held vision of a marketplace of interoperable, self-describing business objects. These efforts include Oracle's redesign of its applications suite around EJB and IBM's San Francisco project. These and other vendors have shipped many new products based on and extending the JPE technologies. I expect these products to trigger the creation of a serious component-based development industry that will finally transcend the Visual Basic-focused market for user interface widgets and communications tools and fulfill a long-standing vision that someday, a commercial marketplace for true business objects will emerge.
I realize this is a fairly aggressive prediction. But consider the fact that Sun has managed to create an environment where a third-party tools-and-platforms industry has begun to flourish. Contrast this to the situation in the Microsoft camp today, where there are few viable development tools besides Microsoft's own developer studio products and Microsoft Transaction Server has a lock on the market for application server products. Lately, even the COM-based component industry has begun to shrink. This is the result of several factors, including Microsoft's gradual incorporation of third-party functionality into its own products, the huge cost of maintaining components that function properly in development and runtime containers associated with different languages, and Microsoft's own backpedaling from its original assertion that ActiveX controls would be an effective component mechanism for client-side Web-based applications.
A significant point of agreement among the vendors I contacted is that EJB heralds the advent of a consistent component-based programming model for middle-tier development. Until now, middle-tier solutions have been deployed on proprietary platforms and have required the development of substantial amounts of infrastructure code. EJB standardizes the infrastructure and establishes a model whereby the developer of the component runtime environment, or EJB server, is responsible for handling remote invocation, transaction processing, security, threading, and state management. The EJB specification defines which services the component runtime environment must provide. Vendors of transaction processing (TP) monitors, CORBA runtime systems, Web server systems, database systems, and application servers are building or adapting products that will function as EJB servers.
An EJB server must implement EJB containers. EJB components are assigned to containers when they are deployed. You can customize the Bean's runtime characteristics at deployment time by editing its environment properties. For instance, the deployer can modify attributes such as the transaction mode and security attributes using tools supplied by the container's user interface. Once deployed, the container is responsible for managing the EJB object life cycle, implementing security for each EJB object, and coordinating transactions. Specialized containers can provide additional services beyond those defined by the EJB specification. An EJB that depends on such a service may only be deployed in a container that supports the specialized service.
The EJB specification provides a mechanism for defining runtime characteristics of each object via deployment time property settings. Each EJB must include a deployment descriptor, which is a serialized instance of the Entity Descriptor or Session Descriptor object. The deployment descriptor object provides methods for reading the EJB's access control entries, environment properties, and home name. The EJB developer defines environment properties, which consist of a series of key value pairs that will determine how an instance of the EJB behaves at run time. For instance, these can include transactional settings and whether entity Beans should employ Bean-managed or entity-managed persistence. Typically, the agent deploying an EJB will edit these environment properties using a property editor provided as part of the container system.
An EJB container manages the state of the object. State refers to the data contained within the object; the values of all of an object's properties at a given point in time represent its state. When an object's property values are assigned at the initiation of a method call and do not persist beyond the execution of that method call, the object is considered transient. When an object's property values persist (so as to be available when additional methods are subsequently invoked), the object is considered persistent. The EJB specification calls for the container to manage session objects, which are transient, and entity objects, which are persistent. In the initial EJB specification, container developers have the option of supporting entity EJBs. They will become a requirement in the 2.0 specification. Notwithstanding their optional status, most vendors support entity EJBs in their current product releases.
From the client's point of view, a session EJB is a nonpersistent object that runs on the server and implements some business logic. Session objects are intended to be private resources available only to the client that created them. In contrast, an entity EJB is a persistent object that provides an object view of an entity whose structure may be defined elsewhere. An entity EJB could represent entities stored in a database or entities whose underlying structure is defined and implemented by an existing enterprise application. Small wonder that object-to-relational mapping tools are quickly gaining in popularity! Unlike session EJBs, entity EJBs must be assigned a unique identity when they are created and provide a mechanism that will enable a client to locate the desired Bean instance based on its key. Multiple clients may access a single entity object concurrently; it's the container's responsibility to synchronize access, using the transaction service.
There are two models for persisting entity EJBs. An EJB can manage its own persistence, in which case the EJB developer must code the database or application update logic into the class's ejbcreate(), ejbremove(), ejbfind(), ejbload(), and ejbstore() methods. Typically, this code will use JDBC services. Alternatively, the developer can delegate management of the Bean's persistent state to the container. In this case, the container provider's tools must generate the database access calls when one installs the EJB into the container.The EJB developer must specify the persistent instance fields in the containerManagedFields property of the deployment descriptor. Using container management insulates the EJB class from needing to know about the data source in which the entity will be stored. It also reduces the coding burden for EJB developers, who suddenly find themselves in the position of being able to avoid having to write any code that retrieves or writes data into object instances completely! You may achieve this huge savings in development, at least initially, at the cost of some performance. Certainly this model will accelerate the development of object to database mapping tools such as JavaSoft's own JavaBlend, as such technology will be a required capability of EJB container products.
An EJB container maintains control over an enterprise Bean through a wrapper. Client applications do not interact with EJBs directly; they interact with the interfaces generated by the container, which provide a client view of the EJB. This EJB object view exposes all the application-related interfaces for the object, but not the interfaces that let the EJB container manage and control the object. One set of interfaces is referred to as the home interface, and its implementation is provided by the container. The home interface lets the client create and remove EJBs and get metadata information about them. For entity EJBs, the home interface also provides a facility for locating a specific instance.
When a client (which may be an applet or application running on a user's workstation or another object) requests the services of an EJB object, it must first locate the object's home interface. This location process uses another of the JPE services, JNDI. The actual locations of the EJB class and its container are transparent to the client. The home interface is specified by the EJB specification and must provide methods to create a new EJB object. Once the client has located the desired EJB class, it can create an object of that class by executing one of the create methods defined on the EJB's home interface.
An EJB object is an instance of a class provided by the container, which implements the EJB's remote interface. Clients always use EJB services by calling methods on the EJB's remote interface. These methods include the business logic defined by the EJB developer as well as the container-provided interfaces that get the object's container, its handle, test its identity, and remove the object. Whenever a client invokes a method on an EJB object, the EJB container intercepts the request and delegates work to the EJB object. This interception mechanism lets the container transparently provide state management, transaction control, and security services to both the client and the EJB.
The container establishes the context of an EJB instance and provides each instance with a Session Context that gives the instance access to information about its context maintained by the container. Context information includes the name of the object, the home interface, the environment properties list, the identity of the object that invoked the instance, the role of the calling object, and the transactional setting.
EJB supports flat transactions, modeled after the OMG Object Transaction Service (OTS) 1.1. EJBs participating in a transaction can atomically update data in multiple databases that may be distributed across multiple sites. Container and EJB server providers bear the responsibility for managing transactions. An EJB's transaction attribute should be specified when the EJB is installed into the container or application server. Any EJB participating in a transaction passes its transaction context to any other resources or EJBs that it invokes. There are six valid transaction attributes that can be assigned to an EJB:
TX_NOT_SUPPORTED indicates that the EJB should not participate in a transaction; the invocation of any of the EJB's methods should occur outside of the scope of any transaction.
TX_BEAN_MANAGED attribute provides a mechanism for client control of transaction demarcation. Only EJBs with this attribute can be manually associated with a transaction.
TX_REQUIRED indicates that any invocation of a method on the object must be associated with a transaction. If no transaction is active, the container will start a new one before delegating the method call to an EJB with the TX_REQUIRED attribute.
TX_SUPPORTS attribute will occur within the current client's transaction scope; if there is no transaction in process, the container will invoke the method without a transaction.
TX_REQUIRES_NEW attribute, it always creates a new transaction context for it. If there is already a transaction in process, it suspends when the new transaction starts and resumes when the new transaction completes.
TX_MANDATORY attribute must always be invoked within the context of an existing transaction. If a client attempts to invoke such an EJB outside of the scope of a transaction, the container will throw a TransactionRequired exception to the client.
The EJB provider must specify the requested transaction isolation level in the deployment descriptor. The available isolation levels correspond to the isolation levels defined by JDBC -- TRANSACTION_READ_COMMITTED, TRANSACTION_READ_UNCOMMITTED, TRANSACTION_REPEATABLE_READ, and TRANSACTION_SERIALIZABLE. The container must specify the requested transaction isolation level when it establishes a database connection on behalf of an EJB. Any database access code generated by the container to support entity beans with container-managed persistence must specify the requested isolation level in the generated code.
Aside from EJBs with the TX_BEAN_MANAGED attribute, EJBs do not have to access transaction management programmatically. Those EJBs with the TX_BEAN_MANAGED attribute must use the UserTransaction interface defined as part of the JTS API. In all other cases the Container must implement the necessary JTS APIs to provide the specified transactional behavior. This shielding of the application developer, and in most cases, the EJB developer, from the details of programming transactional applications will simplify the development of distributed business systems.
EJB breathes new life into CORBA. The CORBA infrastructure is readily adaptable to supporting EJB, and Sun acknowledged the importance of leveraging that infrastructure by publishing an EJB-to-CORBA mapping specification in conjunction with the EJB specification. Under this model, vendors are using plumbing built for CORBA but emphasizing the EJB component model over CORBA's object model. EJB servers built on CORBA generate CORBA IDL implicitly in the runtime environment; the developer never sees any CORBA coding. The mapping specification addresses mapping EJB interfaces to IDL over the Internet Inter-Orb Protocol (IIOP), mapping EJB object names to the CORBA name service, mapping EJB transactions to the OTS, and resolving client identity for security purposes.
Inprise, Oracle, and Novera are building their EJB support on existing or new CORBA services. Inprise is adding EJB runtime support to its Visibroker product line, which has been established in the CORBA world for some time. Version 4.0 of Oracle's application server is primarily a CORBA server that manages EJB via the CORBA to EJB mapping protocols. Likewise, Novera is building its jBusiness suite on a CORBA foundation.
These and other vendors are differentiating themselves in a variety of ways. Oracle will build EJB container support into both its application server and into version 8.3 of the RDBMS itself; in addition, Oracle will support executing EJB-based logic on the client. Oracle is offering extreme flexibility in deploying EJBs to satisfy the requirements of a diverse customer population that scales from small to huge enterprises. On the applications side, Oracle is redesigning its ERP suite so it is based on Designer/2000 models, which emit logic as EJBs via Developer/2000. Oracle believes that this approach will yield a stronger implementation and customization story than SAP's; EJB is a more robust and standard architecture than SAP's BAPI, and model-based EJB generation will pervade the entire product, rather than selected exposed components. Using EJB lets application developers like Oracle focus on packaged business logic and rely on a standard infrastructure for handling security, transactions, and partitioning.
Novera's jBusiness family of products includes Component Development Environment, an Application Server, and a Management Server. The development environment will drop into existing IDEs and include a wizard that generates EJBs from classes that a developer builds, based on answering a series of questions about the EJB's desired behavior. The EJB container will run in the application server, which will support OTS transactions, load balancing, and failover among multiple server instances. Multiweight client access will let powerful clients download and execute business objects locally and interoperate with the server via RPCs. EJB support in the management server includes the ability to view types active in the container, statistics, and an agent scheme based on the event service. It provides these services by introducing management daemon objects into the application server runtime environment.
Persistence Software Inc. claims that its EJB-enabled application server, PowerTier for EJB, will be the fastest application server available. It leverages the company's patented object caching technology to accelerate the Java application performance, as well as Persistence's object-to-relational mapping technology, which lets the server load frequently used data into in-memory objects at startup. Persistence has implemented an interesting model for managing changing data (for example, changes in the state of persistent objects). The PowerTier server isolates uncommitted client changes by creating a private transactional cache that holds the changed objects for each client application. Other users continue to work with the unchanged object in the shared cache. Once a client's work has been committed and accepted by the database, the changed objects are copied from the private transactional cache back into the shared cache.
Weblogic's Tengah application server supports all the optional features described in the EJB specifications. These include distributed transactions, the ability to start transactions on the client or the server and propagate them to other servers, and automatic persistence of both session and entity Beans based on the JDBC specification. Weblogic positions the Tengah server as a fully JPE-based server, rather than a CORBA-based EJB container, and focuses heavily on providing optimized versions of the supporting JPE APIs, including JDBC and RMI. The resulting architecture makes it easy for EJB developers to take advantage of services such as Tengah Events and load balancing.
In Weblogic's view, RMI is the appropriate protocol for coordinating distributed objects because it's very useful to have a protocol that passes objects as arguments to other objects on the network. Weblogic replaces the JavaSoft reference implementation of RMI with its own Tengah RMI. Tengah RMI makes coding distributed solutions easier than using JavaSoft's reference implementation. For example, a remote method does not need to declare RemoteException, and Tengah RMI does not require a separate stub and skeleton class for every remote class. Additionally, there is no requirement in Tengah RMI to set a Security Manager because all of Tengah RMI's services are provided in the context of the secure Tengah Server. Likewise, WebLogic's Tengah RMI offers flexibility among several schemes for naming, binding, and looking up remote objects. URLs can use the standard rmi:// scheme, or they can take advantage of other protocols like HTTP, which lets Tengah RMI function across firewalls that restrict all messages but HTTP.
Java applications and EJBs hosted by Tengah can be replicated with no additional programming. For scalability, Tengah automatically balances the load across available instances of the replicated service and provides a console for remotely monitoring and updating the state of your Tengah application and server cluster. To ensure fault tolerance, Tengah also replicates state information so that an outage can be completely masked from both the user and application. Tengah includes a publish-and-subscribe model for synchronizing applications and data sets over a network.
As with any new product, the 1.0 status of the EJB specification will cause developers to hesitate. I do not believe that hesitation is the appropriate posture; the specification was in play for a long time in order to obtain concurrence from the key partners. During that time, vendors were building prototype and early products based on incomplete versions of the specification. The participating vendors have also discussed the future of the specification and have started to incorporate future requirements based on that advanced knowledge.
The advantages of using Java and EJB for server-side applications are significant. I believe that middle-tier execution of business logic is the right architecture, for all the obvious reasons. It lets organizations support increasing numbers of users by installing more and larger servers rather than investing in network bandwidth and desktop hardware. I also believe that Java is a good choice of language for server-side applications because of its object-oriented nature and because it is portable between server operating systems. In fact, it's more portable on the server, where you don't have to implement a user interface, than it is on the client.
Until the advent of EJB, there was no generic way to implement server-side application logic, which forced those who wanted to implement server-side Java into developing custom infrastructure solutions. EJB offers a generic infrastructure that abstracts the system's underlying persistence store and distribution characteristics. While not a solution unto itself, it makes components transactional and secure without developer intervention. With the JPE in place and supported by an application server like one of those I discussed earlier, the developer no longer needs to develop infrastructure solutions. Applications can deal exclusively with business logic and be deployed on the plumbing of choice. This model lets people whose strength is in implementing business logic become effective developers of industrial multitier solutions. Until now, you needed to be a genius to build robust distributed object solutions. In the future there will only have to be a few geniuses who build application and management servers and a lot of good programmers who understand the application domain.
What did you think of this article? Send a letter to the editor.