An Introduction to Object Transaction Services (OTS)

When this site was originally conceived, the coverage of Open Transaction Processing was relatively poor on the Net. For example none of the TPM vendors had anything more than a product brochure on their web sites. Articles written and published here were a meager effort to correct that. The same cannot be said for the latest developments in Open TP, the rise of CORBA and its later acquisition of properties of an Open TP architecture. What follows is thus a brief and link laden introduction to the Transactional aspects of that architecture. For Objectively challenged old middleware folks like Mr. OLTP we have written 800 words on Object terminology for beginners elsewhere (there are links from various terms in this page).

What is CORBA?

Common Object Request Broker Architecture (CORBA) defines a series of standard protocols and interfaces the core of which is an Object Request Broker (ORB). An ORB provides an RPC like mechanism whereby programs can make requests of and manipulate objects which are remote to it. The body that holds the standards is an industry based one, The Open Management Group (OMG). The RPC like communications interface is termed an Object Request by the OMG.

Object Requests provide a richer and better interface than a simple RPC (such as a DCE RPC) for they provide a distributed version of an Objects' essential Polymorphism and Inheritence properties. ORBs do not necessarily provide all the properties of a Object Transaction Manager, but do provide the necessary Naming, gateway and coordination facilities.

The CORBA has undergone a number of iterations over the years acquiring a necessary Transactional aspect by version 2 (it is currently at version 3).

Douglas Schmidt has a number of papers, go to his home page for navigation, in particular we recommend the CORBA overview. Jon Siegel has written a paper [Siegel] on the particular goals of the OMG with respect to Corba which gives a further good introduction to this organization and its ethos. There is also a CORBA overview from Melody Brake at Colorado State University. Sadly an extremely good review of CORBA 2 specification available from the Technical University at Vienna appears to be no longer available. There is, of course, a very comprehensive CORBA Frequently Asked Questions with Answers (FAQ) which has its origins in Usenet News, in particular the comp.object.corba news group.

Distributed Objects Need Transactions Too

It is widely agreed that the introduction of Objects to middleware brings with it great benefits, those that can be ascribed to Object oriented programming, mainly ease of reuse. Initially however ORBs only provided an infrastructure analogous to RPCs such as DCE. They did not provide Transactional properties, nor did they provide any mechanism where they could be used to scale fully.

Needless to say several early adopters of this technology found themselves writing the necessary Transactional and scaling aspects themselves. This seems to be a counter productive move, when the benefit of this technology is supposedly so the programmer does not have to reinvent the wheel.

Recognising this the OMG introduced refinements to the CORBA specification and introduced Transactions. Software vendors then went about writing the necessary bit of software that would go over the top of an ORB to make the data flows Transactional and allow some measure of traditional TP scaling behaviour, that is coping with a large number of very similar requests simultaneously. These pieces of software are collectively known as Object Transaction Managers (OTM).

GIOP and IIOP

Since the very essence of their being is communications, ORBs need to talk to each other and they need to speak the same language. To this end the OMG have produced specification for General Inter-ORB Protocol (GIOP). This is a transport neutral protocol that could be layered over X.25 for example (although it actually isn't). The implementation of this protocol on TCP/IP, the Internet Protocol is known as the Internet Inter-ORB Protocol (IIOP). In order to be conformant ORBs must implement a bridge between what ever internal mechanism they are using and IIOP. IIOP has from a programming point of view a very RPC feel to it. The programmer defines an interface between the two objects using an Interface Definition Language (IDL) not dissimilar to DCE's (indeed one of the original proposals to CORBA was that this Inter-ORB protocol be DCE). This is then compiled in client and server stubs (called skeletons in IIOP). The skeletons on the server side consist of Virtual function calls the bodies for which are filled in by the programmer.

Other papers on the web treat IIOP in greater detail (PDF).

OTM

Object Transaction Monitors (OTM)s provide Transactions and Scalability by defining distributed objects which have these properties which be then used in programs running under their control. OTS provides the standard interfaces for these Objects and it is the OTM's providers responsibility to write the code for the virtual functions. OTMs are highly state oriented and are non-trivial in their design and implementation. They use stable storage to allow them to recover in flight transactions should a catastrophic crash occur. They interoperate with Resource Managers (RM) to implement the necessary Transaction co-ordination and furnish non-transient connections to these RM for the programs running within them. The guts of these beasts therefore resemble more traditional non-object TPM and indeed some have developed from traditional TPM.

As of the turn of the century (2000) there were a number of notable OTM from traditional TPM Vendors. We list some of the below, but treat with caution, as with anything like this on the Internet, it dates rapidly.

Component Broker

This is from IBM, bundled with Websphere Enterprise Edition (WSEE) and does not appear to be available separately. Websphere EE is an Enterprise Java Beans (EJB) container, which at one stage also has both Encina and CICS (in the form of TXSeries) bundled with it too.

M3

This is from BEA Systems, purveyors of Tuxedo, and sometime known by its development name Iceberg. At one stage bundled with the enterprise version of Weblogic and now available as part of the latest incarnation of Tuxedo it is not available separately. Weblogic, like Websphere has a number of versions, the Enterprise one is the one which contains the OTM and is another EJB machine.

Encina's OTM

Transarc wrote an OTM based on Encina and sort of released it (it was noted for being perpetually in Beta). This OTM, after some work, found its way to Ireland and Iona. It is now in Orbix's OrbixOTM. Encina's OTM is still available separately from Transarc (now part of IBM), but bundled in TXSeries.

Arjuna

This is a commercial offering based on an academic exercise from Newcastle University of the same name (Arjuna). The technology was available from Bluestone, bundled with their EJB stuff. HP bought out Bluestone and then, following the acquisition of Compaq, "sunset" it (their term, not ours). Arjuna however lives on, as Arjuna Technologies a company which provides a variety of OLTP related products and services.

VisiTransact

Folks at Borland (formally Inprise, formally Borland) have informed us that their OTM is VisiTransact, a fine OTM bundled in their Borland Enterprise Appserver series of products.

Like the fine folks at Borland please send us Feedback.

Java

While the CORBA with Transactions can now be considered a well proven technology, latest thinking in this area revolves around the Java programming language and one of its componentization models, Enterprise Java Beans (EJB). This together with a Remote Method Invocation (RMI) to IIOP framework will allow Java Programs running in browsers to communicate with Enterprise class middleware running on the back-end in a safe scalable fashion. Needless to say there are one or two flies in the ointment see our critique of EJBs.

Microsoft

Writing of flies in the ointment, Microsoft has not signed up to anything that the OMG has done. Their view is that there should be a Microsoft solution to middleware and that it should be closely linked with their proprietary-ish interfaces built around Distributed Component Object Model (DCOM). MTS provides the Transactional environment for this. Recent name changes apart (it is now called COM+ and is part of the ".NET" initiative) this seems to be stable enough that several companies are now offering DCOM/CORBA bridges.

$Date: 2008/07/03 17:45:17 $