With support for nested and inter-ORB transactions, it's an object foundation for dealing with the complex world of multistep consumer-to-business and business-to-business transactions
Transactions are essential for building reliable distributed applications. So it should come as no surprise that transactions and distributed objects are getting married. OMG's (Object Management Group's) newly adopted OTS (object transaction service) defines IDL (interface definition language) interfaces that enable objects distributed across multiple ORBs (Object Request Brokers) to participate in atomic transactions, even in the face of catastrophic failure. It
provides for interoperability between object transactions and procedural transactions that adhere to the X/Open DTP (distributed transaction processing) standard, and it optionally supports nested transactions. In short, it's an object foundation for dealing with complex, multistep consumer-to-business and business-to-business transactions.
An object involved in a transaction can assume one of three roles: transactional client, transactional server, or recoverable server (see the figure "
The CORBA 2.0 Object Transaction Service
").
--
A transactional client
issues a set of method invocations that are bracketed by begin/end transaction markers. The calls within the bracket may be for both transactional and nontransactional objects. You declare an object transactional in its IDL definition. The ORB intercepts the begin call and directs it to the transaction service, which establishes a transaction context associated with the client thread. The client then is
sues method invocations on remote objects. The ORB implicitly tags the transaction context and propagates it in all subsequent communications among the participants in the transaction. The ORB also gets involved when the client issues a commit or rollback and notifies the transaction service. The client is oblivious to all this under-the-covers activity; it simply starts a transaction, issues its method invocations, and then commits or rolls back the transaction.
--
A transactional server
is a collection of one or more objects whose behavior is affected by the transaction but have no recoverable states or resources of their own. The ORB implicitly propagates the transaction's context whenever these objects call a recoverable resource. A transactional server does not participate in the completion of the transaction, but it can force the transaction to be rolled back.
--
A recoverable server
is a collection of one or more objects whose data (or state) is affected by
committing or rolling back a transaction. Recoverable objects are transactional objects with ACID (atomic, consistent, isolated, and durable) resources to protect (see the table "The Four ACID Properties" in "Scale Up with TP Monitors"). They inform the transaction service that a recoverable resource has just joined the transaction whose context was propagated in the client call. Recoverable objects provide methods that are used by a transaction coordinator (i.e., the transaction service whose client originates the transaction) to orchestrate an ORB-mediated two-phase commit protocol.
OTS provides IDL-ized interfaces for the objects that make up the transaction service. So it is possible for clients and transactional objects to get more intimately involved in the details of the transaction via explicit method invocations. However, most transactions will depend on the ORB to transparently do all the work using its built-in facilities. Less intervention means better performance. OTS is a well-designed,
low-overhead service that should perform at least as well as X/Open-compliant procedural transaction services.
illustration_link (22 Kbytes)
CORBA's Object Transaction Service
