作者：zybersx
email: zybersx3@21cn.com
日期：2000-7-23 23:22:24
http://www.microsoft.com/com/wpaper/mts-ejb.asp 

Comparing Microsoft Transaction Server to Enterprise JavaBeans
Microsoft Corporation

Contents
Introduction 
A Brief Overview 
Types of Objects 
Supporting Transactions 
  Transactions in Microsoft Transaction Server 
  Transactions in Enterprise JavaBeans 
Controlling Complexity 
Portability 
Interoperability 
Standardization by Specification 
Choices for a Development Language 
Administering a Distributed Transaction Environment 
Summary

Introduction
Microsoft® Transaction Server (MTS) is the transaction service in the Windows NT® operating system. First available in 1996, MTS is now in use at many organizations. Enterprise JavaBeans (EJB) is a specification for a Java-based transaction service. Created by a group of companies led by Sun Microsystems Inc., the initial specification for EJB was released in spring 1998. Both Microsoft Transaction Server and Enterprise JavaBeans target the creation of component-based, transaction-oriented applications. This paper provides a comparison of these two technologies. More specifically, the paper analyzes the similarities and differences between the ways the two component models handle objects, transaction support, controlling complexity, portability, interoperability, language choice and administration.

Back to contents

A Brief Overview
Put simply, a transaction can be thought of as a set of events that are committed or rolled back as a unit—either all of the events happen, or none of them do. For example, transferring $100 from your savings account to your checking account requires both subtracting the money from your savings account and adding it to your checking account. To achieve a consistent result, either both operations should occur or neither one should. Transaction-oriented applications like this are very common, and so many vendors provide software that makes writing transactional applications easier. And because transactional applications often need to handle hundreds or thousands of clients (i.e., users at workstations), services that make it easier to build scalable applications are commonly built into products that support transactions.

Both Microsoft Transaction Server and Enterprise JavaBeans support transactional applications and provide services for scalability. Because the two technologies attempt to solve many of the same problems, they have much in common. The easiest way to illustrate their similarities is to describe the basic architecture and terminology of each.




Figure 1

MTS is based on the Component Object Model (COM), and an MTS application is implemented as one or more components. As shown in Figure 1, these components are managed by the MTS Executive. COM objects that run under the control of MTS are called MTS objects. As is usually the case with COM, MTS relies on a class factory object to create specific instances of each COM class. To allow MTS to provide extra services, the MTS Executive transparently inserts a wrapper object between each object it manages and that object's client. For example, when a client uses the COM IClassFactory interface to create an instance of a MTS object, that call is actually made on a factory wrapper object implemented by MTS, which in turn passes on the call to the real class factory. Similarly, every method call a client makes on the business methods of a MTS object is first handled by a MTS-supplied context wrapper object. The MTS Executive also supplies a context object for each MTS object. This context object maintains information specific to the MTS object, such as what transaction it belongs to (if any) and whether it has completed its work. Every context object implements the IObjectContext interface, through which a MTS object can access the services that MTS provides.

The general architecture of Enterprise JavaBeans is very similar to MTS; little more than the terminology is changed. As shown in Figure 2, an EJB container acts like the MTS Executive, hosting enterprise beans rather than MTS objects. Each bean exposes its own Home interface, analogous to the COM IclassFactory interface, allowing a client to create instances of specific classes. And, like MTS, the EJB container provides a wrapper for each bean it manages. An EJB Home object wraps the bean's Home interface, while an EJB Object wraps the bean's business methods. Also, an EJB container provides either the javax.ejb.SessionContext interface or javax.ejb.EntityContext interface, both of which offer services similar to MTS's IObjectContext. And although it's not shown in the diagram, an enterprise bean is required to implement one or more additional interfaces that the EJB container uses to interact with the bean.




Figure 2

Both MTS and EJB rely on a transaction coordinator, a logically separate service responsible for ensuring that all operations in a transaction are successful or that none of them are. In MTS, this function is implemented by the Distributed Transaction Coordinator (DTC), a service included in Windows NT. The MTS Executive communicates with the DTC through OLE Transactions, a COM-based interface. The Enterprise JavaBeans specification does not define how a transaction coordinator is implemented or how an EJB container communicates with the transaction coordinator. Instead, each vendor is allowed to implement these functions in any way it wishes.