Application Servers: COM-Based vs. Java-Based
David Chappell - March 1999

What software services are required to support a scalable, enterprise-ready application? Twenty years ago, the most common answer was IBM's CICS. Plenty has changed since then, with no change more important than the rise of the web. Today, an increasingly common answer to this question is some kind of application server.

Okay, so what is an application server? To most people, it's a set of software that provides the following:

- a component model, such as COM or another technology;

- support services for building scalable applications, including things such as database connection pooling, load balancing, and more;

- a way to access those applications via either HTTP or a distributed object protocol;

- some kind of support for transactions;

- development tools for building web-accessible and/or component-based applications;

- perhaps various other things, such as access to message queuing and directory services, technologies for easily generating HTML on demand, and more.

It's possible to divide the application server vendors on the market today into the customary two camps: Microsoft and everybody else. Although they haven't used the term much, Microsoft has actually been shipping an application server with every copy of Windows NT Server for the last couple of years, giving them today's largest installed base. COM is the central technology in Microsoft's application server, playing a critical role in every part. In the "everybody else" camp, leading products include the Netscape Application Server, Sun's NetDynamics Application Server, IBM's WebSphere, the Oracle Application Server, and others. Most of the non-Microsoft app servers have some unique, proprietary features, but all of them are converging toward supporting the same set of interfaces, those defined by the Enterprise Java APIs. For these products, then, the central
theme is Java.

Lining Up the Technologies

The set of technologies in a typical Java-based application server is remarkably similar to those provided by Microsoft. The corresponding technology pairs include:

- Microsoft Transaction Server (MTS) and Enterprise JavaBeans (EJB): MTS and
EJB both provide support for component-oriented transactions, declarative
authorization, resource pooling, state management, and other related

- Active Server Pages (ASP) and JavaServer Pages (JSP): both technologies
allow embedding programming logic in HTML pages, then executing that logic
at the server when a client accesses a page. ASP programs are typically
written in VBScript and JavaScript, while JSPs support code written in Java.

- DCOM and RMI/IIOP: both allow clients to invoke methods in servers running
on remote machines.

- ODBC and Java Database Connectivity (JDBC): both APIs define standard
schemes for accessing relational databases.

It's worth noting that in nearly every one of these cases, Microsoft was first to market with the Java forces following behind. In fact, one could make a strong argument that Microsoft actually invented the notion of an application server, and that to a large extent, the Java crowd is cloning Redmond's inventions. We really need to get over the idea that Microsoft doesn't innovate-it's simply not true.

Microsoft's App Server: Pros and Cons

Microsoft's strongest advantages here are pretty much the same as always: price and ubiquity. Windows NT server machines are cheap, the application server technologies are bundled with the operating system, and there's no shortage of books, courses, and people to explain them. Counter-intuitive as it may seem, Microsoft's technologies are also the most mature, since they've been shipping since 1996.

The drawbacks of these technologies are also the typical cons of a Microsoft solution: scalability and reliability issues with Windows NT, and complete lock-in to a single vendor. NT will probably get more scalable and more reliable over time, although the arrival of Windows 2000 could herald a
substantial shakedown period for all of the new features it brings. Vendor lock-in, however, probably won't get any better, as I don't expect to see Microsoft provide full-throated support for the Java Enterprise APIs. Still, every vendor will make some attempt to lock in their customers-it's their nature-so complete vendor-independence is probably a chimera.

One more negative with the Microsoft solution is that at the moment, their support for load balancing isn't especially good. COM+, part of Windows 2000, improves the story somewhat, but many Java-based application server vendors seem to take this important issue much more seriously than does Microsoft.

Java-Based App Servers: Pros and Cons

In their favor, Java-based application servers offer plenty of vendor choice. They also hold out the promise of less vendor lock-in than with a purely Microsoft solution, although don't expect complete portability across products. Most important, though, Java-based app servers run on lots of different operating systems, including various flavors of Unix and OS/390. For building server applications on big machines, Java app servers win hands down.

But the technology is quite new. Some parts, such as EJB, still have a good way to go before they really qualify as standards (for more on the trouble with EJB, see my last column). From a technical perspective, Sun and its fellow Java travelers are largely playing catch-up ball with Microsoft. Of course, as the Patricia Seybold Group's Anne Thomas has observed, this allows them to treat the relevant Microsoft technologies as prototypes for their work, extending and building on what has gone before. Still, when it comes to supporting enterprise applications, maturity matters a great deal.

Shaping Your Strategy

So which of the two app server paths should you take? For once, the decision is easy. If you can solve your problem using an NT server, and you're willing to commit to a Microsoft-only solution, using the Microsoft application server technologies is the obvious best choice. They're the most mature, the best integrated, and the cheapest (beating a price point of zero is hard, although I suppose a vendor could always pay you to use their product). Microsoft also has good support for using the Java language with its app server technologies, so you're still free to use this up-and-coming programming tool if desired.

If you don't believe Windows NT (or Windows 2000) is reliable enough, scalable enough, or vendor-neutral enough for your situation, you'll need a Java-based application server running on some other operating system. It's not so implausible that a single language can suffice for developing business applications-COBOL did it for years-so the mono-linguistic world promoted by Enterprise Java most likely has a good future. And while choosing among the ever-growing set of Java-based application servers is a non-trivial problem, it's also (thankfully) beyond the scope of this column.

As described above, taking the Java path is not without problems. In particular, interoperability among different vendor's EJB implementations looks like a pipe dream to me. I do think it's likely, though, that the various EJB vendors will achieve a reasonable degree of application portability across their products. The creators of Enterprise Java seem to have learned from the mistakes made by OMG, and the chances for something close to a true standard are much better.

And speaking of OMG, Enterprise Java is the final nail in CORBA's coffin. True, IIOP will survive, as it's the primary distributed object protocol that we'll see in Java-based application servers. CORBA's Object Transaction Service is also important, since most EJB implementations will probably rely on it in their attempts to achieve interoperability. But nearly all major CORBA vendors are burying the rest of the OMG-defined interfaces beneath their Enterprise Java equivalents. OMG's members continue to work away producing new interface definitions, but it's hard to see why-the torch has clearly been passed to Sun and the Java camp. To me, this is a good thing. CORBA never achieved either real standardization or widespread use. Enterprise Java, addressing many of the same problems in a more concrete way, looks much more promising as a true Microsoft competitor.

That said, however, it will still be hard for any Java app server vendor to compete with Microsoft's COM-based technologies for small and medium-scale applications. If an NT server will do the job, it makes sense to use the services it includes. And eventually, Microsoft is likely to make their flagship operating system as scalable and reliable as anything else available. But until this happens, Java app servers will have an important role at the high end of this market. A serious competitor to Microsoft for the future of enterprise infrastructure has finally arrived, something that's bound to benefit everybody. Three cheers for free markets!