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.