Columns

MTS vs. EJB
David Chappell - November 1998

A transaction processing (TP) monitor helps developers create applications that are both scalable and correct. With the rise of component-based development, we've also seen the appearance of component-based TP monitors. (For a brief introduction to components and transactions, see my column from the October 1997 issue of this magazine.) There are now two technologies vying for dominance in this area: the Microsoft Transaction Server (MTS) and Enterprise JavaBeans (EJB), created by a group of vendors headed by Sun.

These two technologies have much in common. Both, for example, require writing applications as components, and both allow setting the transactional requirements of those components administratively. Their services for easy authorization and scalability support are also similar in many ways. But MTS and EJB have important differences, and I believe that these differences are likely to determine which of these technologies will dominate in the future. The goal of this column is to look at the pros and cons of both MTS and EJB, and to make some projections about their likely futures.

Two comments before we start: first, I don't think that deeply technical issues, such as differences in how these two technologies manage an object's state, will be significant in determining which one gets more widely used. Other issues, as described below, are far more important. And second, at the risk of destroying any suspense this column might have for you, let me tell you up front that my money is on MTS.

MTS Pros

MTS's single biggest strength is that it's a standard part of Windows NT. As NT becomes the dominant server operating system for new development, which I think is very likely over the next few years, most developers will wind up using its built-in TP monitor. Even if the U.S. Government decides that bundling MTS with NT is anti-competitive and requires Microsoft to price it separately, it will still have the huge advantage of being produced by the company that makes the operating system. IBM's CICS has dominated the TP monitor space in the mainframe world for decades, and a major reason for this is its creation by the owner of the operating system.

MTS is also relatively simple for developers to understand and use. Microsoft has tended to exaggerate this simplicity, but if a developer already understands COM, there's not too much effort required to effectively use MTS. And one more big plus is that MTS allows application development in many programming languages, including Visual Basic (VB), Java, C++, and others. As Windows NT continues its march to dominance, it's very possible that VB will emerge as the next COBOL, the dominant language for business application development. The relative ease with which MTS components can be created in VB is an important part of this possibility. In fact, Visual Basic, which was once just a tool for building client-side GUIs, is now the language Microsoft most emphasizes for building MTS components.

MTS Cons

MTS's biggest strength is also its biggest weakness: it's tied exclusively to NT. So far, Microsoft has clearly stated that they have no plans to port MTS (or its forthcoming successor COM+) to other operating systems. NT is probably less reliable today than leading Unixes such as Solaris and HP/UX, and it's certainly less trusted in most shops for mission-critical applications. Also, NT isn't available today on really big machines, while Unix is. Both of these things are likely to change in the next few years - NT will probably get more reliable and more scalable - but until then, there will certainly be applications for which MTS is not an appropriate choice.

MTS is also missing some features that many consider essential in a distributed TP monitor. It has no automatic load balancing, for example, so clients are bound to servers in a fairly static way. COM+ promises to add this feature, but as of this writing, Microsoft has yet to announce any dates for the release of COM+.

EJB Pros

EJB's biggest plus is that it will be available on lots of different operating systems. The list includes Windows NT, but it also includes Unix, IBM's OS/390 (once known as MVS), and others. This diversity means that EJB-based TP monitors can run on systems that are bigger and perhaps more reliable than NT systems, but can also run on cheap, plentiful NT boxes.

Furthermore, EJB defines APIs that can be implemented on top of existing TP monitors. Unlike MTS, which is a relatively new product, EJB potentially allows building on what already exists. This can be a good thing for TP monitor customers, since building mission-critical applications has a tendency to make one quite conservative about betting on entirely new software platforms.

EJB also has some interesting technical features. For example, it defines support for two kinds of objects (or, in the jargon of EJB, two kinds of enterprise beans). The first, called session beans, are much like MTS objects. EJB's second option, however, known as entity beans, has no direct analog in MTS. Unlike session beans, entity beans allow the TP monitor itself to load and store the bean's state, i.e., to manage its persistence. Taking this approach can make life easier for the application developer, which is, after all, what TP monitors are all about.

EJB Cons

EJB was produced by a committee of competing vendors, and nearly every one of its faults stems from this fact. Defining full, complete standards leaves no room for competitive advantage, and so vendors tend not to do it. Not surprisingly, then, the biggest problem with EJB is its lack of true standardization.

In fact, EJB all but assumes use of another not-especially-standard technology, the Object Management Group's CORBA. While it's possible to access enterprise beans remotely using Java's native RMI protocol, cross-vendor interoperation essentially requires CORBA's IIOP. And even though different IIOP implementations can communicate for some kinds of requests, there's been little success in building truly effective distributed environments from multiple vendors' CORBA-based products. Complete standards for directory services, distributed security services, load balancing, and other critical areas are lacking. The EJB specification doesn't even indicate what wire protocol should be used for controlling transactions, relying instead on private agreements among EJB vendors to produce an interoperable solution. It also explicitly allows vendors to add extensions to the standard APIs. The result is that, as with CORBA, vendors will field products that conform to the published EJB standard, yet still don't provide true interoperability or portability.

Another almost unavoidable side effect of creation by committee is complexity. When vendors can't agree, an easy solution is to adopt all proposals. EJB, for example, defines three different ways to demarcate transaction boundaries, and allows using all three at once. Expecting developers to understand the possible outcomes of various combinations of these three is too much to ask. (MTS, by contrast, defines only one way to control transaction boundaries.) EJB also defines multiple ways to manage an object's state, including the session bean/entity bean distinction mentioned earlier and more. While all of these options allow more flexibility, they also make the technology much tougher to learn and use.

Finally, EJB's support for only a single programming language, Java, may turn out to be a serious limitation. Java's use is growing rapidly, especially in universities, and so it's reasonable to assume that more and more enterprise application developers will know it in the near future. But it's not reasonable to assume that any one language will ever be right for every organization and every application. By tying itself to a single language, EJB is limiting its reach.

Conclusions

MTS has an unbeatable advantage: it's bundled with NT. Just as CICS became the dominant TP monitor for IBM mainframes, it's hard to imagine any other technology displacing MTS on NT. And if NT becomes the dominant server operating system, MTS will be the clear winner over EJB. Even worse for EJB supporters, MTS was released in late 1996, while products supporting EJB aren't appearing until well into 1998. In the race to be the dominant component-oriented TP monitor technology, MTS has a considerable head start.

EJB is as much a marketing effort as it is a technology. It provides a common flag around which Microsoft's competitors can rally, but it doesn't really define a standard. I would very much like to see EJB become more complete, as a true multi-vendor standard in this area could be a strong competitor to MTS (and Microsoft needs nothing today as much as serious competition). But as it stands, EJB is a specification that provides marketing cover for what are essentially a group of single-vendor products. If EJB's creators complete the task they've set out on and produce a complete standard, they may have a chance to define tomorrow's standard TP monitor technology. But unless they do, MTS is likely to emerge as the CICS for the next twenty years.