Spilling the "Beans" - Technology Information

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.

Serious enterprise applications require the integration of legacy applications and data running on a wide variety of platforms. Thus, in effect, enterprise application server products are EJB application server products. (Even EJB in its first iterations had trouble addressing truly heterogeneous environments, but with the addition of CORBA, the current version of EJB can easily integrate programs written in multiple languages running on any major platform.)

To clarify the current state of the software market, we've added a third dimension to Gartner's original matrix. Excepting MTS, all of the products that Gartner originally considered as OTM products were CORBA products that had integrated TP capabilities. During 1998 a number of companies explored this option and some built successful applications using this approach. Unfortunately, building these applications proved arduous--developers were forced to create lots of interfaces and linkages to handle the integration of the several different frameworks that make up a typical CORBA implementation package.

The EJB and MTS models promised a way to hide lots of the difficulties involved in building OTM applications. By 1998, most companies were looking for ways to field enterprise applications on the Internet. Thus, the combination of an Internet-oriented server component standard, like EJB, and application servers designed to provide all the needed frameworks, while hiding lots of the details, proved an irresistible combination. (It has proved so irresistible in the marketplace, that BEA Systems and Iona have both found it difficult to sell their earlier OTM products. Each has subsequently bought an EJB application server vendor and introduced a new EJB application server-based OTM product.)

Server-Side Component Models

Taking a slight detour, let's consider what's so special about EJB or MTS components (Figure 2). First, an EJB component sitting inside an EJB container looks almost exactly the same as an MTS component inside its respective MTS container. The EJB components are JavaBeans, and there's nothing new there. It's the EJB container that introduces the difference. When a client component sends a message to an EJB component, it must first pass through the container (a set of components). A container is like an animal cell wall, intercepting and judging anything that wants to pass from the outside to the EJB components within.

The EJB container creates a clean separation between the thought that goes into the development of an EJB component, and the design considerations involved in programming the EJB container. In other words, using an EJB or MTS approach, one group of developers can create components without having to consider how they might be fielded. Another group takes the finished EJB components and decides how they are to be managed in a particular system. This creates a situation like the one described in Figure 3, and it provides the basis for a mature market for reusable components.

Sun's EJB specification details the nature and interfaces of EJB components, EJB containers, and EJB application servers. The application server pre-packages lots of details that a system developer would have had to consider. The system developer now places EJB components in containers and then programs the container interface and links the container to external service frameworks provided by the EJB application server environment.

Keep this in mind: Although EJB application servers are products, they are actually frameworks of components. Depending on the vendor, the services provided by the server frameworks are more or less well hidden. The EJB application server simply substitutes more systematic and manageable EJB component interfaces for the more loosely organized frameworks that make up a typical CORBA OTM implementation.

The real advantage is the degree to which the EJB and MTS component models free business component developers from concerns about how the component will be fielded. The business component developer can focus on the business functionality. All of the runtime considerations can be handled later by the developer who places the component in a container and programs the components that make up the "wall" of the container.

EJB Application Server Vendors

Today, there is quite a bit of variation in EJB application server products, primarily because many vendors are redesigning existing products to function as enterprise application servers. For example, some EJB application servers started life as Internet or HTML servers, while others began as database servers. Still others began as CORBA middle-ware products, Java development tools, or OO databases. An EJB application server is a combination of all these things, and thus it makes sense for vendors from each of these niches to enhance their products in an effort to enter a hot new market. The result, however, is that each product reflects the strengths it brings from its particular background and needs to work to improve its offerings in other areas.

To complicate matters, transaction or server-side component models are, themselves, new technology, and the standards are changing rapidly. Thus, each vendor can implement the settled features associated with the EJB or CORBA specifications and must wait, or make proprietary extensions, to capture other features that won't be defined until subsequent releases of the specifications.

Figure 4 provides a generic architecture that can be used to discuss the features of an enterprise application server.

In the center of the figure, the "Core Application Server," are the services and utilities that most enterprise application servers have. In a larger box, represented by a dotted line, are a number of boxes to describe features that only some servers include.

Starting from the top left, Internet application servers provide services for clients. Some of those clients will be browser- based, accessing the application server via HTTP and related W3C protocols. In some cases, the enterprise application server product will incorporate an Internet server to manage HTML documents, CGI scripts, and other Internet-related protocols. In most cases, however, the enterprise application server does not include an Internet server, but relies, instead, on an Internet server provided by another vendor. (Note that this is strictly a logical distinction. The two software products, the Internet server and the application server, may physically reside on the same hardware, or may reside on independent platforms.)

In addition to supporting Internet connections, most enterprise application servers will also support access to other types of clients. Thus, any EJB application server will support access to Java components, applets, and EJB clients, either directly or by way of an Internet server.

Similarly, most EJB servers support CORBA, and can communicate with any CORBA client. If a server supports Java or CORBA, it can also access COM indirectly, using bridges provided by CORBA or Java.

The core of any application server consists of a number of utilities. Thus, every enterprise application server implements one or more component models. In effect, the server is a collection of component service frameworks, protocols, and the APIs necessary to assure the smooth functioning of the business objects that developers place on the application server.

EJB application servers implement Sun's EJB transaction component model. Most future editions of EJB application servers will probably also implement the OMG's upcoming CORBA component standard.

The BIB specification divides responsibility between BIB servers, BIB containers, and EJB components, although the developer can override and change certain allocations to improve performance. Thus, it is assumed that BIB component developers will create business components without worrying about the exact environment in which the component will be fielded. Developers responsible for placing the BIB component in a container and those responsible for placing the container on an BIB application server will each have to make decisions about how their respective software environments will handle the BIB components. For example, containers handle the creation of new instances of the BIB components and usually determine which components will be handled as elements in a transaction. Security may be a responsibility of the container or of the server.

Even though the container coordinates a transaction, an independent transaction manager actually manages the transaction. The transaction manager may be part of the application server product, or an independent product. Some servers support both options.

Similarly, the application server coordinates queuing and load balancing, and brings additional servers online, as needed. The message queuing engine may be part of the application server, an independent component, or a third-party product.

Evaluation Criteria

Keep in mind that all of the enterprise application servers are, in fact, BIB application servers, with the exception of Microsoft's MTS. Thus, in most cases, all will support the basic features of the BIB transaction component model, and most of the attention will be directed to how well the product supports special features or incorporates other products.

That said, there are several key criteria for evaluating an enterprise application server:

* Server Hardware Support

* Business Component Model

* Transaction Processing and Message Queuing

* Client Connectivity

* Data Management

* Security

* Tool and Language Support

* Application Management

Finally, one other general criterion to consider is the overall strength of the application server vendor. Vendors like Microsoft and IBM are clearly going to be around and supporting their products over the course of the next five years. That may not be the case with some of the smaller, newer vendors.

Innovation will continue. The BIB specification is not yet complete Bach new BIB specification release will require vendors to revise and update their products to incorporate the latest standards.

The constant effort to upgrade, while simultaneously preventing bugs, remaining backward compatible, and growing one's market share, requires technical and managerial talent and it costs money. Larger vendors will be more likely to weather these required changes. Smaller vendors will be under a constant strain to keep up, and some will either fail or be acquired by larger vendors looking for a quick entry into the BIB application server market. Several acquisitions have already occurred.

Meanwhile, as companies rush to convert themselves into c-business and to field serious applications via the Internet, the market for enterprise application servers seems certain to prosper.

Paul Harmon is the editor of Component Development Strategies newsletter and the Director of Technology Information at Genesis Development Corp., in West Chester, Pa. (www.gendev.com).

Jason Matthews, CEO of Genesis Development, heads the Genesis Software Evaluation Lab that contracts for the private evaluation of application servers.

COPYRIGHT 1999 Wiesner Publications, Inc.
COPYRIGHT 2000 Gale Group