Client/server is dead. That's the buzz now that newer Internet-based technologies are flourishing. But those new technologies are merely the natural evolution of earlier approaches, implemented with newer, more open protocols and designed to provide greater scalability, manageability, and diversity.

The magnitude of this evolution is astounding. Most of the major client/server vendors have modernized their products and now direct their marketing dollars into three-tiered technologies. In most cases, the newer products are Java-centric and Internet-protocol centric. For example, I identified at least 46 Java middleware products at last count. Two years ago it would have been hard to come up with half that number.

This is the first of a two-part series of articles dedicated to explaining general-purpose Java middleware in its current forms. In this first article, I'll examine the features of current products and explain why these features are important. In the second part, Anil Hemrajani will examine Enterprise JavaBeans (EJB) and show how the current generation of Java middleware products relate to and support this important component standard.

Background

First of all, let's define Java middleware. The term encompasses application servers like BEA WebLogic, messaging products like Active Software's ActiveWorks and Push Technologies's SpiritWAVE, and hybrid products that build on a DBMS legacy and add server-based Java object execution features. I could have focused on a more narrow segment, such as application servers, but that would have been unfair to the many products that don't fit this category precisely but nevertheless should be considered for multitier applications. Further, even among application servers there is quite a spectrum, including those that are primarily servlet servers as well as those that are ORB-based or OODB-based. Drawing a line between all these products proves increasingly difficult. The unifying feature, however, is that they all attempt to solve the multitier application deployment problem by using Java and Internet technologies.

The business case to use Java in middleware is compelling; among the advantages offered by Java middleware are the following:

The ability of the Internet to economically interconnect offices and organizations

The need for organizations to cooperate by sharing data and business processes

The desire to consolidate generic services and the management of these services

The desire to redeploy business logic at will and unconstrained by infrastructure; this necessitates using open APIs and protocols, which are widely supported across most infrastructure products

The need to support cooperating mixed-architecture applications

The desire to move network and service infrastructure decisions out of the application space, so that system managers can make infrastructure decisions without being hampered by applications that depend on proprietary protocols or features

The desire to reduce the diversity and level of programmer staff skills needed and minimize the need for advanced tool-building expertise within projects

The desire to leverage object-oriented expertise by extending it into the server realm -- hence newer object-oriented server products and object-to-relational bridges

The goal of middleware is to centralize software infrastructure and its deployment. Client/server originates from an era of integration within a single department. Organizations now commonly attempt integration across departmental boundaries -- even from one organization to another. The Internet -- which entices businesses with its ability to serve as a global network that lets departments and partners interconnect efficiently and quickly -- has generated the demand for this integration.

Java provides a lingua franca to easily interconnect data and application across organizational boundaries: In a distributed global environment, in which you have no control over what technology choices your partners may make, smart companies choose open and platform-neutral standards. Companies cannot anticipate who will become their customers, partners, or subsidiaries two years down the road, so it isn't always possible to plan for a common infrastructure with one's partners. In this uncertain situation, the best decision may be to use the most universal and adaptable technologies possible.

Java lets you reduce the number of programming languages and platforms your staff must understand. Why? Because Java is now deployed in contexts as diverse as Internet browsers, stored procedures within databases, business objects within middleware products, and client-side applications.

At the age of three, however, Java technology is still somewhat immature, and this is true of the products discussed in this article. On the other hand, we may now be in an era when products never truly reach maturity, because the underlying technologies on which they're based change so rapidly. In fact, I've found significant problems with virtually every middleware product I've used, including supposedly mature products that have been on the market for a few years and have recently come out with significant new features. The point is, by the time a vendor manages to fix problems, new features have been added. The cycle for adding new features is now much shorter than it has ever been, and so products don't have enough time to become stable before they include the next major feature set. This may be something we have to get used to, and learning the strengths and weaknesses of the products we choose is an important part of any application design and prototype cycle.

Goals for middleware

The EJB middleware component standard was developed with the following goals:

To provide component interoperability. Enterprise beans developed with different tools will work together. Also, beans developed with different tools will run in any EJB environment.

To provide an easy-to-use programming model while maintaining access to low-level APIs.

To address lifecycle issues, including development, deployment, and runtime.

To provide for compatibility with existing platforms, which allows existing products to be extended to provide support for EJB.

To maintain compatibility with other Java APIs.

To provide interoperability between EJB and non-Java applications.

To be compatible with CORBA.

The focus of the EJB standard is therefore on creating an interoperability standard for Java middleware, shielding programmers from having to deal with many of the difficult issues that arise when developing distributed applications. This allows software developers to concentrate on business logic instead of writing sophisticated homegrown infrastructure and tools. As a result, businesses can put most of their educational resources into training staff in business processes, which typically is what provides the greatest payoff.

To the list above, I add the following additional goals for enterprise-class Java middleware. These product features are needed in the long term in order to successfully run and maintain a middleware-based environment:

It should accommodate the interconnection of multiple business units, companies, and customers in a distributed infrastructure without compromising security or introducing chaos

It should allow flexible yet reliable access control mechanisms to assure that business-partner data is accessed only in the intended ways, and only by the intended parties

It should allow system administrators to manage a distributed computing environment containing large numbers of business logic components in a uniform way, without having to understand or apply unique procedures to particular components

it should allow system administrators to make infrastructure component selections without impacting applications, and to tune and scale those components and have a uniform and generic means of measuring the performance and resource needs of all applications

It should allow business components to be relocated between clients and servers without impacting the architectures of either

It should provide a security mechanism that allows particular users to add new components, without having to give the server administrator access to all components and data sources (this is a great opportunity for value-added capability, as it is critical to extranet and partnership applications)

Components and features of Java middleware platforms

The fastest-growing category of Java middleware today is probably application servers. However, it is essential to realize the wide variety of application servers (and other kinds of middleware products) that exist. Distinctions among Java middleware product categories today are represented not by a line but by a vast middleware continuum. I will now discuss the features of Java middleware, based on my own work comparisons, which encompass every class of Java middleware product I know about.

Object, component, and container models

Application components must adhere to some runtime deployment model, which specifies how the component communicates with its environment; (possibly) how it is installed, started, stopped, and called; and how it accesses services important for its environment. Popular Java-centric server-component runtime and container models include RMI, EJB, CORBA, DCOM, servlet, JSP (Java Server Pages), and Java stored procedures. In addition, the component models can be expressed in a variety of underlying languages, including Java, IDL, C++, and many others.

There is overlap with various component models. For example, RMI is a trivial component model with very basic facilities for object activation and location, and is primarily a remote invocation standard, whereas EJB leverages RMI and specifies RMI as its primary object invocation model. EJB also supports CORBA. In fact, none of these models is exclusive, and many Java application servers support most or all of the models above.

Many Java middleware servers run multiple business-object instances (which the CORBA world now calls servants) within a single Java virtual machine (JVM). The type-safety of the Java language allows a single JVM process to service requests from multiple clients and use program data structures and class loaders to keep client data separate. As long as servants don't employ their own native methods, it isn't possible for one servant to bring other servants down if it crashes (unless it encounters a bug in the JVM itself), or access data that is private to other classes. A properly designed object server will protect its private objects and prevent errant objects from accessing what belongs to other objects.

However, data declared static in a Java class can be shared among clients within the same JVM if the clients use the same class loader, so rules need to be defined to dictate when a separate JVM (or the equivalent of a separate JVM using memory-partitioning techniques) or separate class loader is needed to give a client its own static data space. Such rules have been specified for applets, but not for other execution environments. Sun's Java Web Server uses a single JVM for all servlets and a separate class name space for servlets with a different code base. EJB circumvents the issue by prohibiting nonfinal static data.

Performance can be increased if objects are inactivated or passivated when not in use, freeing up resources such as database connections. For this reason, many servers passivate and reactivate objects as appropriate. Similarly, some products keep frequently created objects in a pool or cache in an initialized state and ready for immediate use. The object container must manage passivation and reactivation as well as the pooled resources affected by passivation.

EJB compatibility (version)

The EJB model already is becoming universally supported. Nearly every middleware vendor has promised to support it and many already do. Moreover, the Object Management Group (OMG) has incorporated a mapping to EJB as part of the proposed CORBA Component Specification. It's hard to imagine that even Microsoft, the lone and steadfast holdout, won't eventually yield and provide EJB containers for DCOM.

While different EJB-compatible middleware can deploy and operate the same application components (as long as those components use only standard required EJB features), there is still a great deal of variation among EJB-compliant servers. For one thing, the EJB specification itself is evolving. An important question when evaluating Java middleware products, therefore, is: Does the server support the latest version of EJB, or does it support only an earlier version? Another key question is: Is the product EJB-centric, or is EJB support included only in the product's value-added features (and thus unavailable when EJB services or APIs are used)? And finally: Which optional EJB features are included (for example, entity beans and container-managed persistence)?