Jun 1, 1998 1:00 AM PT

Enterprise JavaBeans: Coming soon to a server near you

Get a first look at this new component architecture, which promises to revolutionize server-based component development

While we're all familiar with the Java platform in its various incarnations (1.0, 1.1, and the upcoming 1.2 release), what you may not realize is that Sun also has defined a server-based platform for enterprise-capable Java computing. The Java platform for the enterprise currently consists of eight components designed for "medium-to-large scale business, enterprise-wide systems, multi-tier environment, distributed data sources, and serious users of middleware applications" (to quote Sun's marketing information). This platform is of great importance to the distributed objects developer because pieces of this platform rely on distributed computing architectures such as CORBA, RMI, and sometimes both.

Each technology in the enterprise platform is at a varying stage of development; some of the pieces are probably already familiar to you (RMI and JDBC), while others (like JavaIDL) are just about ready for prime time.

In addition to these three popular APIs, the Java Naming and Directory Interface (JNDI), also a piece of the enterprise platform, is shipping. JNDI is intended to give Java developers the tools required to access naming and directory services for enterprise-class applications.

The four technologies above are available now and JDBC 2.0 (a major revision to the original standard) is on the way (see Resources for JavaWorld coverage of these various APIs.). Meanwhile, the four remaining pieces are:

  • Enterprise JavaBeans (EJB)
  • Java Management API (JMAPI)
  • Java Message Services (JMS)
  • Java Transaction Service (JTS)

All of these APIs (see Resources) warrant standalone discussions; this month, however, we will focus on the technology that will undoubtedly play the largest role in your enterprise application development efforts in the near future -- Enterprise JavaBeans.

What does EJB have to do with distributed objects?

You may be wondering why you, the distributed object guru in your organization, should take the time to begin learning of future changes to the Java APIs. I can think of a number of reasons, which is partially why I'm focusing on EJB this month. The first reason is that distributed, multitier development is fully interwoven into Sun's Java server development platform. While the details may or may not be hidden from you, developing an application using the Java Transaction Service, for instance, means that you will be using a fully compliant mapping of the OMG Object Transaction Service, or OTS as it is commonly referred to. In addition, a portion of the EJB specification deals with standardizing the mapping between the EJB architecture and CORBA. While it will be possible to communicate with an Enterprise JavaBean using RMI (the default protocol), it will also be perfectly valid to use CORBA as the glue between your client applications and Enterprise JavaBeans located on a server. The second excellent reason to pay attention to the enterprise platform is that there will finally be a standardized way to write distributed, transaction-oriented systems that do not lock you into one vendor's proprietary toolset. As a purely random example, let's take a moment to consider the methodology for building a distributed application using Oracle Corporation's Network Computing Architecture (see Resources). While Oracle provides support for developing server "cartridges" in Java that use CORBA as a communications bus, individual transaction management and data access APIs are Oracle-specific and are therefore not portable (should you need to port your application to Sybase SQL Server, for instance). From an application development standpoint, the developer does not choose to use the Oracle8 server based solely on the DBMS's characteristics. Instead, the overall Network Computing Architecture must be evaluated against another vendor's architecture (Microsoft's Transaction Server/SQL Server combo, for example) based on a very large number of tradeoffs.

Now let's jump forward to some point in the near future when the major DBMS and transaction monitor vendors all support the Java platform for the enterprise. (Coincidentally, as I was in the process of writing this article, Oracle announced the fall 1998 release of Oracle8.1 and its "300% Java" initiative. Surprise! It will fully support the EJB 1.0 specification. Using EJB and JDBC, you could build server components, accessible via CORBA/IIOP, that take advantage of the EJB APIs. This means that your entire component, or bean, could be uprooted from Oracle8.1 and installed in an EJB-aware Sybase server with no changes to the code.

Is the light fully on and blazing in your head yet? If not, read on. (Even if it is, don't link out of here just yet!)

We'll spend the rest of this article discussing EJB from a fairly high-level perspective. In the coming months, as real products that implement this specification begin to emerge, we'll build some live applications that take advantage of this revolutionary new API.

EJB: Server-side component model for the future

EJB promises to standardize middle-tier server development in a way that no other technology to date has been able to do. Not only does EJB have the backing of the major enterprise players (IBM, Sun, Baan, BEA Systems, Netscape, Novell, Oracle, Sybase, Informix, Lotus, Gemstone, Tandem, and others), but the popularity of Java, and, most importantly, the need for a well-thought-out, easy-to-use, portable component model for server applications have made this technology a shoo-in for success.

Rather than coming up with my own definition, I'll quote Sun's documentation definition of EJB:

Enterprise JavaBeans is a cross-platform component architecture for the development and deployment of multi-tier, distributed, scalable, object-oriented Java applications. Enterprise JavaBeans makes it easy to write business applications as components by providing a set of automatic services to support scalable transactional application server components. Enterprise JavaBeans can be deployed on top of existing transaction processing systems including traditional transaction processing monitors, web servers, database servers, application servers, etc.

The EJB 1.0 specification unequivocally states the goals behind the design of the EJB component model. Here are just a few of them:

  • EJB will be the standard component architecture for building distributed object-oriented business applications in the Java programming language.

  • EJB will make it easy to write applications: Application developers will not have to understand low-level transaction and state management details, multithreading, resource pooling, and other complex low-level APIs.

  • The EJB architecture will define the contracts that enable tools from multiple vendors to develop and deploy components that can interoperate at runtime.

  • The EJB architecture will be compatible with existing server platforms. Vendors will be able to extend their existing products to support EJB.

  • The EJB architecture will be compatible with CORBA.

It should come as no surprise to find that EJB, like all other Java technologies, is a platform-independent, object-oriented technology. Each Enterprise JavaBean will be required to execute within a component execution environment that must comply with the EJB 1.0 specification. This approach will ensure that each execution environment (or container) implements a defined set of interfaces. The end result will be that each Enterprise JavaBean can be uprooted from one execution environment and placed in another one without requiring any recoding (that is, assuming that no vendor-specific APIs are used). Each Enterprise JavaBean will be required to define and implement a Java remote interface so that it can be accessed from a Java client using RMI. This makes RMI the default communications mechanism for Enterprise JavaBeans. It is important to note, however, that Enterprise JavaBeans can also be accessed via the CORBA Internet InterORB Protocol (IIOP). This will allow Enterprise JavaBeans to be accessed from both Java clients (using RMI) and other clients (via IIOP). The CORBA implementation details will be hidden from the EJB developer.

Naturally, an Enterprise JavaBean can make use of all of the existing features inherent in the Java platform, including threads, persistence, and security.

What is a JavaBean and how does it differ from an Enterprise JavaBean?

JavaBeans is the name of the component model developed for Java and included with the Java 1.1 platform. It provides a mechanism for component-based development in Java, and more often than not, JavaBeans are visual components -- grids, calendars, and charts, for example -- that are reused across applications. Each JavaBean can be viewed by its client container application as a set of properties, methods, and events that can be manipulated at design-time and at runtime. Java's serialization and introspection capabilities allow JavaBeans to be dragged onto a form in a Java IDE (Visual Café, for example), have their properties set by the developer at design-time, then be viewed and manipulated by a user at runtime. A standard JavaBean is, by definition, a client-side component that cannot, by default, be accessed and manipulated by other clients at runtime.

Enterprise JavaBeans, meanwhile, have no user interface component and reside entirely on an EJB-aware server. In the future, this could be a transaction processing monitor such as BEA's Tuxedo, a database management system such as Oracle or Sybase, or a Web application server from Netscape or NetDynamics. The Enterprise JavaBeans 1.0 specification details the requirements that these server containers must meet and how they will work with Enterprise JavaBeans components. While standard JavaBeans properties are hard-wired into code, Enterprise JavaBeans support customization at runtime via environment properties. Enterprise JavaBeans also differ in the way they are actually distributed. A new distribution format, known as an ejb-jar file contains a JAR file manifest, Java class files for the Enterprise JavaBean, deployment descriptors, and environment properties specifying the properties the bean will require at runtime.

Currently, two types of Enterprise JavaBeans are described in the specification: Entity and session beans. Session objects will exist for the life of a single client application and disappear should the server crash. Entity objects are persistent objects that may be used by many users across crashes or shutdowns of the server. To comply with the EJB 1.0 specification, a container need only support session objects, although entity object support will be a requirement in the 2.0 specification.

Transaction management using EJB

Most notable among all of an Enterprise JavaBean's features is its support for distributed transactions. Thanks to the required capabilities of an EJB container, an EJB developer can seamlessly update multiple databases distributed across multiple locations without having to write any of the "low-level" logic that becomes necessary to commit or rollback multiple transactions. Each EJB container is required to implement the javax.jts.UserTransaction interface, shown below, which is a small portion of the Java Transaction Service (JTS) API.

public interface javax.jts.UserTransaction
        public final static int STATUS_ACTIVE;
        public final static int STATUS_COMMITTED;
        public final static int STATUS_COMMITTING;
        public final static int STATUS_MARKED_ROLLBACK;
        public final static int STATUS_NO_TRANSACTION;
        public final static int STATUS_PREPARED;
        public final static int STATUS_PREPARING;
        public final static int STATUS_ROLLEDBACK;
        public final static int STATUS_ROLLING_BACK;
        public final static int STATUS_UNKNOWN;
        public abstract void begin();
        public abstract void commit();
        public abstract int getStatus();
        public abstract void rollback();
        public abstract void setRollbackOnly();
        public abstract void setTransactionTimeout(int seconds);

In addition to performing transactions across multiple databases at multiple locations, an Enterprise JavaBean can also initiate multiple transactions across multiple EJB servers. The EJB servers work together to propagate the transaction context across each server, a process that is totally transparent to both the client and Enterprise JavaBean component programmer. Each Enterprise JavaBean possesses a transactional attribute that can be modified by tools provided with the container/server application. The possible values of this attribute include:

  • TX_NOT_SUPPORTED -- The bean does not support transactions
  • TX_BEAN_MANAGED -- The bean uses the javax.jts.UserTransaction interface to demarcate transaction boundaries
  • TX_REQUIRED -- The bean must execute within the context of a transaction
  • TX_SUPPORTS -- The bean supports, but doesn't require, a transaction context
  • TX_REQUIRES_NEW -- The bean must execute within a new transaction context
  • TX_MANDATORY -- The bean must execute within an existing client transaction context

The ability to seamlessly perform distributed transactions in a vendor- and platform-independent manner is perhaps this technology's biggest drawing card. To reiterate, this will allow an Enterprise JavaBean to be moved transparently among different vendors' EJB containers with no code change (assuming that no vendor-specific APIs are used when building the Enterprise JavaBean).

The relationship between CORBA and EJB

In addition to distributed transaction coordination, the EJB specification also defines how Enterprise JavaBeans will map to CORBA objects. Due to the requirements in the specification, the following scenarios will be possible:

  • A CORBA client (written in C++, COBOL, or any other programming language supported by CORBA) can access Enterprise JavaBeans

  • A client program can mix calls to CORBA and EJB objects within a transaction

  • A transaction can span multiple EJB objects that are located on multiple CORBA-based EJB servers, provided by different vendors

This means that there are two basic types of clients that can use an Enterprise JavaBean:

  1. An Enterprise JavaBean/CORBA client that uses the JNDI to locate objects, RMI over IIOP to communicate with remote objects, and the javax.jts.UserTransaction to perform transactions. Note that this client can be written with no knowledge of CORBA or its Interface Definition Language (IDL). Instead, the runtime implicitly uses IDL based on the Enterprise JavaBeans Java remote interface.

  2. A standard CORBA client written in a programming language with a CORBA IDL mapping defined. This type of client would locate the client using a COS naming service, CORBA IDL to manipulate the objects, and the Object Transaction Service (OTS) to perform transactions.

Note that in order for the first client type to exist, the ability to use RMI over IIOP must also exist. This ability is not currently in place, but Sun is working on it. When completed, RMI over IIOP will make use of the CORBA pass-by-value extension and will allow Java applications to fully interoperate with CORBA applications developed in other programming languages. This technology is expected via an "early access" release this summer, and will also ship as a standard extension to JDK 1.2.

I'm hoping that you can now see the value of my previous columns (see Resources), which focused on the CORBA specification and showed how it worked so seamlessly with Java. In the near future, CORBA will be the glue binding both client and server objects together, no matter if they were written in Java, C++, COBOL, or even Smalltalk.


EJB promises to become the one technology that truly solidifies Java's foothold in the world of enterprise computing. Just as many IS managers were beginning to fear that Java was becoming a language useful only for building animated dancing-head applets, Sun has produced a specification that could become the standard for building interoperable, distributed, component software development.

We will be looking at the Java platform for the enterprise in more depth in coming months, and will, of course, particularly focus on areas of interest to the world of distributed objects. My mailbag is overflowing with reader requests for column topics -- such as a further explanation of CORBA's DII capabilities, a look at the Java Transaction Service, and in-depth remote method invocation -- which should keep me busy over the next several months. Nonetheless, if you'd lke to add any specific technology or topic for future coverage, please contact me with your suggestions.

Bryan Morgan is a senior member of the technical staff with TASC Inc. (http://www.tasc.com). He currently is using CORBA and Java to build a distributed spatial query application as part of an internal R&D project. Bryan has co-authored several books for Sams Publishing, including Visual J++ Unleashed and Java Developer's Reference. He holds a B.S. in Electrical Engineering from Clemson University.

Learn more about this topic

  • Previous Distributed Object columns