Spilling the "Beans"

Software Magazine, Sept, 1999 by Paul Harmon, Jason Matthews

ABOUT ENTERPRISE APPLICATION SERVERS

Companies rushing to convert themselves into e-businesses are turning to enterprise application servers, which are really Enterprise JavaBean (EJB) servers, with the notable exception of Microsoft's MTS

Suddenly, whenever anyone talks about developing a large Internet application, they are talking about running it on an application server. In spite of the overnight success of this new software product, there is a lot of confusion about what constitutes an application server.

A software application server is a software platform that allows a developer to field an Internet application. Ironically, an application server, even though it is usually used to field Internet applications, isn't usually an Internet server. An Internet server (or HTML server) supports Internet clients by providing them with HTML, CGI, and other Internet protocol code when requested. An application server, on the other hand, provides a platform on which one can run middle-tier business logic. Most application server packages rely on external Internet servers to pass information to clients via the Web.

There is also an important distinction between products designed to support modest Web sites and those that support serious enterprise applications. Web site products may help provide information to people visiting a corporate Web site, Application servers are designed to support applications with transaction processing or with complex decision processing requirements and should be termed "enterprise application servers" to avoid confusion. This article will focus on the enterprise application servers.

To define an enterprise application server in still another way, consider Figure 1. The basic matrix shown in Figure 1 is modified after a diagram that Gartner Group popularized several years ago. Gartner argued that as applications became more complex, developers tended to move from remote procedure call (RPC) and message-oriented middleware (MOM) products to object request brokers (ORBs), like the Object Management Group's CORBA. At the same time, as the integrity of the data became more important, developers tended to move from RPCs and MOM products to transaction processing monitors, like IBM's CICS or BEA Systems' Tuxedo. The best of both worlds, Gartner argued, would be an object transaction monitor (OTM) that combined an ORB and transaction processing (TP). In late 1997 and early 1998, OTMs were hot, and Iona's Orbix and BEA's M3 OTM were among the most popular. Both combined CORBA implementations with a transaction processing engine.

The OMG was working on a transaction processing standard in 1997, but hadn't finalized the specification, and thus, most vendors who entered the OTM market created products that combined 0MG CORBA standards with some proprietary TP engine. A CORBA implementation is a collection of objects or components that implement a variety of 0MG standards and protocols. In effect, a CORBA implementation is a set of component frameworks. CORBA can be quite powerful, but there is a considerable learning curve required to master CORBA systems development.

What changed in the spring of 1998 was Sun's introduction of the Enterprise JavaBean (EJB) standard. EJB is a component specification for "server-side components." It took a while for Sun and its allies to sufficiently publicize the virtues of EJBs, but gradually, developers decided that they could achieve OTM functionality by using server-side components, in conjunction with enterprise application server products designed to support those components. Thus, when most people today talk about enterprise application servers, they are really talking about EJB application servers.

There is, of course, one notable exception: Microsoft's MTS (Microsoft Transaction Server) product. Microsoft introduced MTS well before the EJB spec, and Gartner, in its original matrix, had suggested that MTS might be an OTM. In spite of its early start, and some modest attention, MTS has really only been extensively promoted by Microsoft as a way of countering Sun's EJB initiative. By 1998, Microsoft had announced its intention to integrate MTS, version 2, and COM in a new component-based TP standard referred to as COM . The complete implementation of COM isn't expected to be released until Windows 2000 is released. (The current Beta version of COM isn't complete.) As the deadline for Windows 2000 has stretched out, Microsoft has apparently reversed course and decided to promote MTS as a standalone product, pending its integration with COM .

In any case, MTS is only marginally an enterprise product. First, it only runs on Windows platforms. Second, it's stateless. It only provides the equivalent of EJB's session beans and doesn't have the equivalent of State beans. This isn't to say that MTS hasn't proved popular, or that Microsoft won't ship more units of MTS than EJB application server vendors ship. MTS isn't a specification, after all; it's a product incorporated in Windows NT 4.0. Those who are developing low-end OTM applications can use MTS quite effectively. In its present form, however, it isn't designed to scale up. It doesn't have any built-in load balancing mechanism and it doesn't run on non-Windows platforms.