Enterprise JavaBeans are being promoted as the component architecture for the new decade. The word Enterprise in the name would imply that EJBs are to the server environments what JavaBeans are to client computing. Both are component models, both are for Java, both try to deliver on the promise "write once, run anywhere." Beyond that, however, there is little commonality between them. EJB is not actually a software product but rather a specification of a server-side component architecture, to be implemented by vendors of server software. The specification combines object distribution with transaction processing and persistence. Its goal is to provide a standard architecture for building scalable, portable and distributed enterprise systems. The EJB architecture attempts to separate the business logic in the enterprise beans from the services that are required to host the beans. The promise of the architecture is that developers can focus on building the beans with little or no consideration given to the details of target runtime environments. According to the specification, the enterprise bean developer ships the bean with environment-neutral information on how to deploy it. Based on this information, the target environment expert adapts the bean to the environment using the environment-specific deployment tools.
The future potential of EJBs is great, hence the interest and effort being expended on them by many large server software vendors. The EJB architecture provides application software vendors with a single way to deploy the same application across a large number of very different server platforms, without their necessarily having to know all the details of writing applications on those platforms. Another side of the same coin is vendor-neutral standardization of server component software, which is important for enterprises with heterogeneous platforms. Even for organizations that aren't concerned about diverse environments, the EJB architecture and programming model can be used as a standard for server software development across different units.
This article provides a brief overview of the past, present and future of Enterprise JavaBeans. It also briefly describes an example EJB environment and its development tools. For space reasons we'll refrain from presenting any background information on transactions, security, persistence or various other distributed object concepts.
There are two types of enterprise beans: entity beans and session beans. The former model business entities, such as a customer, an invoice or a contract. Entity beans are persistent, that is, they're stored in a database. Their persistence can be managed either by the runtime environment (EJB container) or by the bean itself. The advantage of the container-managed scheme is that the container handles all persistence and back-end peculiarities instead of having this knowledge embedded in application code. This scheme limits the beans' possible property types to a relative few, however, because the container accesses the properties directly when a bean is stored and restored. The only thing that can be assumed across various containers is that their persistence mechanisms support the basic Java types. With the bean-managed scheme the container doesn't access a bean's properties directly. The entity bean itself knows how to store and restore its state. Therefore the EJBs' internal composition structure can be whatever the developer desires and the container doesn't limit the property types. The downside of this approach is that the developer has to code all the database access. For a small, single application this is probably of little concern. For large applications this may lead to potential maintenance and performance problems.
Session beans control workflow. They contain the logic for managing business processes and tasks, like "make a reservation" or "create a new customer." Due to their task-centric nature, the session beans are transient and not persistent. Session beans interact with entity beans and act as agents for client applications. A client application interacting with session and entity beans is presented in Figure 1.
Having the workflow logic in a session bean rather than in the client application reduces the network traffic and the number of connections needed. Session beans can be either stateful or stateless. Stateful session beans maintain their state across multiple client requests and are useful for long-running conversational tasks. Multiple clients, however, can't share the same bean instance because the bean's state depends on a particular conversation with a client. Stateless session beans don't maintain any state. Each method invocation is independent of any previous invocation and operates only on data passed in as parameters. The same bean instance can serve multiple clients, thereby reducing the amount of resources needed to serve the clients.
A complete enterprise bean package includes a description of how to deploy the bean in the target environment. This description includes the bean's interfaces, its persistent fields, how the bean's persistence is managed, its transactional behavior, and its security and environment properties. Based on the deployment description, the EJB container deployment tools create a wrapper (EJB object) and a factory (EJB home) for the bean that adapt the bean to the container. The deployment process also includes generation of all the distribution and persistence services for the bean. A deployed enterprise bean is presented in Figure 2.
An EJB container is a runtime environment for enterprise beans. The container's six primary services are naming, distribution, concurrency, transaction management, persistence and security. The container also provides resource management, including bean instance pooling and activation.
The EJB object implements the enterprise bean's remote interface. Clients can't access the bean directly; they can only access the EJB object that wraps the bean. The EJB object delegates the method invocations to the bean.
This delegation scheme allows the container to intercept the messages between the client and the bean in order to manage transactions, security and persistence for the bean. Relationships between entity beans and EJB objects are presented in Figure 3.
An EJB home provides finder services for locating beans and factory/life-cycle services for creating and deleting beans. A home also provides metadata about the beans, including a bean's remote interface, its primary key class and its type (session or entity).
The EJB world, just like the rest of the Java world, is very specification-centric. The first EJB specification was released in the beginning of 1998. Version 1.0 defined the basic EJB components and the component contracts, including the container, homes, EJB objects, session and entity beans, and deployment descriptors. Version 1.0 also specified various other things, such as developer roles, exceptions, distribution, transactions, persistence and security.
The EJB model specified in version 1.0 certainly has many advantages. The first version, however, omitted many details and had a number of limitations that application developers and container providers had to work around. For example, version 1.0 leaves such essential OO concepts as inheritance and associations unspecified. This has caused either the tool vendors to add nonportable extensions to containers or the application developers to emulate these missing features in applications. Version 1.0 also states that entity beans are optional only, and due to the lack of an API for accessing the container's services the bean-managed persistence is nearly impossible to implement just by following the specification. It's also difficult to implement portable finders because the specification doesn't define any semantics for the finders.
The new 1.1 specification version doesn't introduce any major revisions to 1.0. It primarily introduces small enhancements here and there, which do, however, make a difference. Version 1.1 facilitates association implementations by specifying associated homes. The specification also opens doors for inheritance implementations by stating that enterprise bean classes can have superclasses. Some other key revisions are that entity beans are mandatory, finders can return collections in addition to enumerations, the security model has been refactored, deployment descriptors are stored in XML format rather than in binary format, and structural deployment information (e.g., home, fields) is separated from assembly information (e.g., security, transactional behavior).
An Example EJB Environment
IBM WebSphere Advanced Edition is an example of an enterprise server environment that hosts EJBs. The EJBs are developed and deployed using VisualAge for Java. The deployed EJBs are then executed within the WebSphere Application Server.
VisualAge for Java provides tools for EJB creation, packaging and deployment. It supports top-down, bottom-up and meet-in-the-middle approaches for developing EJB applications. With the top-down approach the database schema is created from existing EJBs. The bottom-up approach supports creating EJBs from an existing schema. The meet-in-the-middle approach is for situations in which existing EJBs are mapped to an existing schema. A screen capture of the EJB creation is presented in Figure 4.
The created EJBs are packaged into JAR files. VisualAge produces three types of JAR files: a generic portable JAR file, a predeployed JAR file for WebSphere Advanced Edition and an EJB client JAR file. The deployment step includes mapping EJBs to a database schema, generating the CRUD services for container-managed persistence, generating the EJB objects, generating EJB homes and corresponding finders, and generating the distribution services (i.e., stubs and skeletons).
VisualAge for Java also includes EJB client and server environments for testing and debugging EJBs. The EJB server is a lightweight version of the WebSphere Application Server that runs within the VisualAge IDE. VisualAge can automatically generate a test client for a deployed EJB and run it against the test server. This significantly simplifies and speeds up testing of EJBs.
WebSphere Application Server Advanced Edition is a highly scalable EJB server that supports multiple platforms, databases and transaction systems. Its workload manager provides server clustering and application-level workload management and distribution across multiple servers. The distributed transaction management executes across multiple applications and components. The distributed security operates at EJB level and can utilize third-party authentication and secure association services. The user registries are LDAP-based and the access control lists and policies can be established at the user and group levels, and for specific calls or methods within applications. Advanced Edition includes remote administration, logging and analysis capabilities, and it also can be monitored with Tivoli-based tools. A screen capture of the Advanced Edition administrative console is presented in Figure 5.
The server also provides a wide range of capabilities for interacting with enterprise databases, transaction processing systems and other applications.
The application server supports both container- and bean-managed persistence. The messaging between EJBs is optimized for both remote and local situations: if both the sender and the receiver EJB reside in the same container, the messaging bypasses the Object Request Broker. This optimization is especially important with applications that consist of large numbers of fine-grained objects.
The Future of EJBs
The first two EJB specification versions were written primarily by Sun. Subsequent development, however, has been done within the Java Community Process. Two EJB-related specifications are currently being developed: the EJB 2.0 specification and a specification for UML/EJB mapping. Expert groups for both began their work at the end of last year and first drafts can be expected later this year.
The EJB 2.0 will be a major revision to the specification. The Java Specification Request delineates several important objectives for the specification. The most important ones are full support for inheritance and associations, and portable query syntax for finder methods. The other objectives include integration with the Java Message Service, improved entity bean persistence, additional methods on the home interface and a mechanism for extending containers. The JMS integration will allow asynchronous method invocation from clients, which is important for systems that have part-time disconnected clients. The persistence enhancements include data access components that encapsulate the database access, and a standard API that enables persistence tools to operate across different containers. The additional methods in the homes are for providing behavior that is independent of finding and managing individual bean instances. For example, a home might have a batch-update method that operates on all instances within the home. The container extension mechanism, which is based on an interceptor pattern, provides means for specializing the container's behavior for specific operational environments, thus reducing the need to have several versions of the base container itself.
The objective of the UML/EJB Mapping Specification is to provide means for modeling EJB applications using UML. The specification defines a set of standard UML extensions expressed as a UML profile. This profile describes the relationship of EJB constructs and a deployment descriptor to UML model elements, the forward engineering transformation from the model elements to EJB implementation artifacts, and the reverse engineering transformation from the implementation artifacts to the model elements. The specification also defines a mechanism for associating UML models and EJB implementation artifacts that are stored in the same JAR file. The mechanism is based on XML DTD and can be used for reflection and tool automation.
Even though Enterprise JavaBeans provide an advanced server architecture, they won't make server application development trivial. Building high-performance enterprise servers, with or without EJBs, is never simple. Still, the EJB specification represents a significant step forward in the systematic development of scalable and distributed component-based applications. The advantages of unifying on a single server architecture and programming model for Java applications are enormous, even for applications that aren't distributed in nature or deployed on different server platforms.
The specification is by no means perfect or complete as yet. Where the specification is lacking, developers and vendors must make up the difference or do without. This can mean guessing the direction the specification is evolving, developing additional functionality and, later, creating migration strategies from the proprietary enhancements to some future version of the specification.
It's unlikely that there will be a viable alternative to EJB for a server component architecture in the near future. Most major server software providers offer EJB environments, and there's a lot of general interest and effort being invested in EJBs throughout the software industry. This, added to the fact that there's already a wide range of EJB business components available from independent software vendors, makes EJBs one of the most attractive server solutions today.
Timo Salo, a senior software engineer for IBM Transarc, has been developing large-scale, multitier distributed systems for banking and financial industries since 1985. Timo is currently architecting EJB
persistence tools for various IBM development environments, including VisualAge for Java and WebSphere Application Server.
He can be reached at: [email protected].
Justin Hill, a senior software engineer at IBM, is currently working
on Smalltalk and Java feature development. Since 1987 he has
been developing object-oriented systems for the banking,
telecommunications, process manufacturing and insurance industries. Justin has specialized in object persistence and object-oriented query languages for the last five years.
He can be reached at:[email protected].