JavaEJBDoing Business with Enterprise JavaBeans

Doing Business with Enterprise JavaBeans content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

March 24, 1999
Doing Business with Enterprise JavaBeans

by George Reese

Most people familiar with Java have encountered its standard component model for client-side objects, JavaBeans. Through a simple programming contract, you can build Java components that others can employ in diverse applications using standard Java IDEs. Although nothing restricts you from developing “server-side” components, like business objects using the JavaBeans specification, you will find yourself limited to a single virtual machine environment. JavaBeans does not provide direct support for components that need to operate in a distributed, persistent, and secure environment. Because business objects need such an environment, Sun and its partners created a component model built around these needs: Enterprise JavaBeans (EJB). We will explore the special needs of an enterprise computing environment and how the EJB specification attempts to meet these needs.

Enterprise computing

The term “enterprise computing” is definitely one of today’s busiest buzzwords. When you hear it used, chances are it is being misused. Enterprise computing is not simply business computing; it is not even mission-critical business computing. Specifically, it is computing that uses technology as a strategic tool for modeling a business. It encompasses both mission-critical and mundane applications. In particular, enterprise computing unifies all kinds of business applications under a single model.

Enterprise JavaBeans basically break down along two lines: persistent and transient beans.

Any enterprise computing solution must focus on modeling business concepts without imposing restrictions on business processes. For example, you do not want your business software to dictate that your worldwide offices operate in English. You may choose English for other non-technical reasons, but you should never let technology drive business processes. Thus the key to proper business modeling is to capture your business concepts in reusable, re-packageable components. These components must meet the following requirements:

  • An enterprise business component must be accessible from any place at any time using security that can support multiple classes of users. You want a business component that can support both Web access for customers, extranet access for vendors, and intranet access for employees.
  • An enterprise business component may require persistence. In other words, it may need to remember its state across time. When the server goes down, that business component must come back up on that server or on another server in the exact same state as it was in when the server went down. Not all components will require persistence, but an enterprise component model must support both persistent and transient components.
  • An enterprise business component must place only minimal standards-based requirements on those who use it. In short, it should be platform independent and be able to persist against a number of different persistence models. While you may be able to control what environment your employees work in, you cannot control the computing environments of your customers, clients, vendors, or distributors. By avoiding proprietary solutions, you maximize the potential clients of your business components.
  • An enterprise business component should be free of cultural bias. Beyond the obvious requirement for internationalization and localization, it also means a component should abstract from the particular quirks of your local department, so other departments and your business partners can use it.
  • An enterprise component must be the authoritative reference for the business concept it represents. In a banking system, for example, a single, logical business component represents Savings Account #129936432. This component may be made up of multiple objects, but those objects should be working together to maintain a single, logical point of reference for any potential clients.

EJB roles

To some degree, the EJB component model enables you to build enterprise components that meet all of these requirements. Before assessing its suitability to the task, however, we should briefly review Enterprise JavaBeans. While you can find the specification on the EJB site, it is terse and a bit difficult to follow.

The specification first identifies different roles in the business component world. The key roles are as follows:

  • The EJB Provider — An EJB provider is an expert in the business concepts at hand and is the author of the Java classes that model those concepts. These Java classes exist independent of any particular application in which they might appear.
  • The Application Assembler — An application assembler is an expert in the processes of a business and is the author of a complete application built from the business components developed by one or more EJB providers.
  • The Deployer — A deployer is an expert in a particular operating environment. The deployer takes an assembled application and configures it to the specifics of the environment in which it will run. This job may include, for example, indicating how to map the attributes of a business component to the corporate database.
  • The EJB Server Provider — A server provider provides one or more system-level services, such as distributed transaction management.
  • The EJB Container Provider — A container provider provides the runtime environment for an EJB.
  • The System Administrator — A system administrator maintains the system’s runtime environment over the course of its life-cycle.

An entity bean is shared across multiple client applications.

The current specification focuses almost entirely on the work of the EJB provider. As a business object developer, the provider is you. Every other role makes use of the business objects you develop. Of those roles, only the container is of interest in this article. The container is the place where your business objects live. It thus manages the key functions of an enterprise component such as security and persistence.

Types of beans

Enterprise JavaBeans basically break down along two lines: persistent and transient beans. A persistent EJB is one whose state is retained across application instances. A large percentage of your business objects will likely be persistent. The EJB specification calls these business objects “entity beans.” An entity bean is shared across multiple client applications. For example, a single savings account entity bean may be referenced simultaneously by an ATM machine and a Web client.

The EJB specification calls transient business objects “session beans.” They come in two flavors: stateful and stateless. A stateful session bean shares values between two method calls. If you set an attribute in a stateful session bean by calling one method and then call a second method, that attribute will still be set to the value you assigned it. A stateless session bean, on the other hand, does not maintain any state information across method calls. Both kinds of session beans have a one-to-one relationship with a client. If, for example, we had a login session bean, the ATM machine would reference a different login session bean from the Web client.

Distributed beans

Java comes with built-in support for distributed computing via Java RMI and Java IDL (CORBA). Building on these foundations, all Enterprise JavaBeans are distributed objects that can operate in either RMI or CORBA environments. The agnosticism for distributed computing models is an extremely powerful feature of EJB. You can deploy components from any vendor in either a CORBA or an RMI environment. As a builder of an EJB, you simply don’t care how your application assemblers and deployers actually intend to use the bean.

Bean-managed persistence places the burden of persistence management on the JavaBean developer.

Your options on how you deploy the bean, however, are entirely dependent on the server provider you use. The server provides the distributed computing services for your runtime environment. If it relies entirely on Java RMI and JRMP (RMI’s native network protocol), you will end up with an application that cannot scale due to the limitations of JRMP (lack of failover support, protocol speed, and out-of-control socket creation). A good server can work in pure-CORBA, pure-RMI, and RMI-IIOP environments.

Bean persistence

Java’s platform independence is a feature you have probably heard way too much about. Just as important, though, is EJB’s ability to provide a persistence-independent component model. An EJB can persist against a relational database, a file system, an object database, or any other kind of persistence store you might dream up. It does this in one of two ways.

The most common persistence mechanism in use today is something called “bean-managed persistence.” As its name implies, bean-managed persistence places the burden of persistence management on the JavaBean developer. You implement the persistence methods from the EJB specification to perform persistence operations like the creation, deletion, loading, or updating of an EJB with respect to its data store.

The other kind of persistence is “container-managed persistence.” Here, a bean developer is not at all concerned with persistence issues. Instead, the bean developer focuses entirely on the business logic of business components. You can configure the container at deployment time to make those objects persist against a particular data source and data model.

In an ideal world, there is absolutely no reason you would use anything other than container-managed persistence. In the real world, however, you do not want to touch container-managed persistence until the 2.0 version of the EJB specification is released. The most glaring design fault with the EJB specification is that it requires all attributes for container-managed beans be public. Public attributes are, of course, a sacred no-no of object-oriented software engineering. Unfortunately, EJB must require public attributes, because there is absolutely no way under JDK 1.1 to let a specific class get access to an object’s state unless the state is all public. The JDK 1.2 specification provides a questionable tool that enables any class to get access to another class’s private attributes. Using this tool, the

method in java.lang.reflect.AccessibleObject class, a container in future EJB versions will be able to gain access to private data.

Security basically boils down to two issues: network security and authentication and validation.

Another problem with container-managed persistence lies not in the specification, but in the container implementations themselves. First of all, since containers are not even required to support entity beans, much less container-managed persistence, you cannot rely on that support even to exist. Finally, practical experience is showing that most people run into implementation problems when relying on container managed persistence due to the general immaturity of the products currently available.


The EJB container and server together wrap beans in a security blanket as specified by the deployer. Under this model, you do not have to worry about any security issues when writing an EJB. How containers manage security under the EJB 1.0 specification is largely unspecified except for a reference to a single, deprecated class from the JDK 1.1 package. Security basically boils down to two issues: network security and authentication and validation. Network security is simply the EJB server’s job of assuring encrypted network communication. Authentication and validation is the EJB container’s job of making sure that the right people are accessing the right parts of the system.

Depending on the server you use, your network communications may or may not be secure. You need a container that uses some sort of SSL security if you intend to deploy an application where secure data is being transmitted.

The immaturity of EJB is simply a tactical issue that should disappear as the specification matures.

Due to the lack of direction on authentication and validation, you may see a huge variation in the way different containers implement their pieces of the security puzzle. Application assemblers will potentially need to retool their applications for serious changes when EJB 2.0 comes out. You should, therefore, look for a container that provides good tools for the deployer and system administrator to manage security configuration.

EJB in an enterprise environment

We have covered a variety of issues relating to how Enterprise JavaBeans address the issues of enterprise computing. As a 1.0 specification, it shows its immaturity in a variety of places. In spite of this, however, it is the best option available for an enterprise computing solution. Other alternatives exist that are more mature, but they invariably compromise on one or more of the key aspects of enterprise computing discussed at the start of this article. The immaturity of EJB is simply a tactical issue that should disappear as the specification grows.

Related articles

About the author

George Reese is lead architect for Newthink Inc. and lives in Maple Grove, Minn. He is responsible for the architecture of multi-tier distributed enterprise Java systems. He is the author of Database Programming with JDBC and Java, from O’Reilly and Associates.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories