转载--微软98年关于MTS和EJB的比较说明文件.其实Sun也有类似的对比文件,我忘记在那里了!(1)

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 aclearcase/" target="_blank" >ccount 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.

Back to contents

Types of Objects
MTS objects are typically designed to encapsulate some set of business functionality. For example, an MTS object might allow a client to transfer money between two accounts or build and submit an order of some kind. Because MTS objects are written as distinct components, business functions encapsulated into these objects can be combined in arbitrary ways, allowing them to be flexibly reused. Although it@#s not strictly required, an MTS object is typically accessed by one client at a time, and it may (but isn@#t required to) use transactions.

The EJB specification takes a more complex view of objects. Unlike MTS, EJB explicitly defines two different types of enterprise beans. The first, called session beans, are much like MTS objects. Session beans encapsulate some segment of business logic, are typically accessed by one client at a time, and optionally use transactions. The EJB specification also defines a type of persistent object called an entity bean. Unlike session beans, entity beans represent a specific set of persistent data stored in a database, such as an employee record or a particular order. Each entity bean has a unique key that identifies it, and each one is intended to be accessible by many clients simultaneously. Furthermore, entity beans are required to use transactions.

An MTS client need do nothing special to create and work with transactional objects; to a client, an MTS object looks like an ordinary COM object. An EJB client, on the other hand, must understand and correctly use new interfaces and methods to create, manage and destroy enterprise beans. Because MTS is built on COM, it automatically benefits from the richness and maturity of the COM environment. Enterprise JavaBeans, by contrast, is forced to invent much of its own infrastructure, including such basics as persistent object support and interfaces, allowing clients to create remote beans.

Back to contents

Supporting Transactions
A transaction defines a set of events that are guaranteed to be committed or rolled back as a unit. Accordingly, every transaction has a beginning, some number of events that are part of the transaction (such as database updates), and an end. Exactly how a transaction@#s boundaries are demarcated can vary. A common approach in traditional client/server transaction products is to require the client to make a specific call to the transaction coordinator to begin the transaction. The client then makes calls to the components that carry out this transaction@#s work, and finally ends the transaction with another explicit call to the transaction coordinator. This final, transaction-ending call can indicate that the transaction should be committed, making all of its changes permanent, or aborted, causing all of its changes to be rolled back. It@#s the job of the transaction processing system to ensure that exactly one of these two outcomes occurs.

Back to contents

Transactions in Microsoft Transaction Server
When combining transactions with components, the traditional client-controlled model isn@#t usually the best approach. Instead, MTS introduced a new way to demarcate transaction boundaries. Called automatic transactions, it allows clients to remain unaware of when transactions begin and end—they never need to make explicit calls to begin or end a transaction. Instead, when a transaction begins depends on the value of that component@#s transaction attribute. This value can be set to one of four possibilities


If a component is marked as Requires New, the MTS Executive will always begin a transaction when its caller first invokes a method in one of that component@#s objects.
If a component is marked as Required, the MTS Executive will begin a transaction when its caller first invokes a method in one of that component@#s objects unless the caller is already part of a transaction. In this case, any methods invoked in the object will become part of the existing transaction.
If a component is marked as Supported, the MTS Executive will never begin a transaction when a caller invokes methods in one of the component@#s objects. If the caller is already part of a transaction, the work this object does will become part of that transaction. If the caller is not part of a transaction, this object@#s work will execute without being wrapped inside a transaction.
If a component is marked as Not Supported, the MTS Executive will never begin a transaction when a caller invokes methods in one of the component@#s objects. Even if the caller is part of an existing transaction, this object@#s work will not become part of that transaction.
When it has finished its work, an MTS object can call either SetComplete, if it wishes to commit that work, or SetAbort, if the work it has done should be rolled back. If neither is called by the time this object@#s transaction ends, the MTS Executive behaves as though the object called SetComplete—the default behavior is to commit the transaction. These calls are made by a method in the MTS object itself, not by the client (again, the client need not be aware that transactions are being used). If every object participating in the transaction agrees to commit, the MTS Executive will tell the transaction coordinator to commit the transaction. If any MTS object in this transaction calls SetAbort, however, the MTS Executive will tell the transaction coordinator to abort the transaction.

Back to contents

Transactions in Enterprise JavaBeans
The Enterprise JavaBeans specification defines three approaches to demarcating transaction boundaries:

Client-managed transactions, where a client makes explicit calls to begin and end each transaction
Container-managed transactions, which allow a client to rely on the EJB container to begin and end transactions automatically
Bean-managed transactions, where an enterprise bean makes explicit calls to begin and end transactions
Given that its creators are trying to ensure that Enterprise JavaBeans can be retrofitted onto existing legacy products, they have chosen to support the traditional client-managed approach to transaction demarcation. EJB has also adopted MTS@#s innovation of automatic transactions. In fact, EJB@#s container-managed transactions are nearly an exact clone of MTS@#s automatic transactions. An enterprise bean can be labeled as TX_REQUIRES_NEW, TX_REQUIRED, TX_SUPPORTS or TX_NOT_SUPPORTED, all of which have the same meaning as in MTS. And like MTS, Enterprise JavaBeans assumes that a bean wishes to commit the transaction unless it explicitly invokes the setRollbackOnly method (EJB does not provide an analog to the MTS SetComplete call, however).

At first glance, EJB@#s plethora choices can appear attractively flexible. But they are also very complex. What happens, for instance, when different approaches to transaction demarcation are used simultaneously? Suppose an application begins a client-managed transaction, then executes a method in an enterprise bean that@#s configured to require a new container-managed transaction. And suppose this bean creates yet another bean that@#s using bean-managed transactions. What happens when the client commits its transaction? Understanding all the possible combinations (legal and illegal) and their outcomes will be very challenging for developers. And if developers can@#t easily understand the outcome of their transactions, how can they write correct applications? Compared to the simple, unified model that MTS provides, EJB offers developers a confusing and potentially error-prone array of choices for controlling transaction boundaries.

And in fact, MTS provides all three transaction demarcation options found in EJB, but in a less confusing way. First, as previously described, EJB container-managed transactions are virtually identical to MTS automatic transactions. MTS also supports client-managed transactions, allowing a client to determine explicitly when a transaction should begin and end. But unlike EJB, MTS builds this service on top of automatic transactions rather than introducing an entirely separate mechanism. This eliminates the possibility of confusion between automatic transactions and client-managed transactions. And, finally, an MTS object with its transaction attribute set to Not Supported can make direct calls on the DTC using OLE Transactions. By doing this, an MTS object can demarcate transactions on its own, just like an EJB bean-managed transaction.

Back to contents

Controlling Complexity
A primary goal of any transaction processing platform should be to control the complexity inherent in writing transactional applications. Understanding difficult business problems, then creating the correct code to solve them is hard enough without being forced to spend time wrestling with a complex environment. Yet the creators of Enterprise JavaBeans apparently did not have simplicity as a goal. Instead, EJB looks like the union of everyone@#s ideas about how to do transaction processing.

For example, as already described, EJB transaction demarcation is very complex, with three different options spelled out in the specification and a myriad of possible ways to combine those options. Enterprise JavaBeans also defines two types of enterprise beans: session beans, representing business logic, and entity beans, intended to represent persistent data stored in a database. These two bean types must be treated quite differently by developers. (Support for entity beans is not required by the current version of the EJB specification, so an EJB-compliant vendor can implement only session beans if desired. This adds another variable to EJB@#s already-complex set of options.) A session bean must be configured to be either stateful or stateless, depending on the choices its creator makes. Entity beans can have either bean-managed persistence, with the bean itself responsible for issuing database calls to load and save its persistent data, or container-managed persistence, where the EJB container does this on the bean@#s behalf. And entity beans can be labeled as either reentrant or non-reentrant, depending on whether the developer has made provisions for bean reentrancy. Furthermore, because entity beans are designed to be accessible to many clients at once, there must be some way to control concurrent access to their data. The EJB specification gives two illustrative examples of how this might be done but leaves the door open for any other approach.

原文转自：http://www.ltesting.net