Tuxedo can be considered as the original and purest service oriented architecture. The key abstraction in Tuxedo is the service and everything is made to fit into the service mould. It seems strange then that people think of Tuxedo as a legacy application. Tuxedo is highly regarded by the senior management team in Oracle who view it as a key tool to support extreme transaction processing. The question is then, how does this relate to the rest of the SOA world which does not subscribe to the Tuxedo technologies such ATMI, C++ or COBOL.
The native client interfaces to Tuxedo are the C, C++, .Net or COBOL client interfaces using ATMI (Application to Transaction Monitor Interface). There is also a version of ATMI for Java, called Jolt. These interfaces allow clients to invoke Tuxedo services and get responses. They do not allow Tuxedo to invoke services in these clients except by listening on Tuxedo message queues, these interfaces are asymmetric.
A Tuxedo domain can interface to other Tuxedo domains, treating their services as though they were its own services. This capability is extended to other systems such as mainframe systems. The external systems see Tuxedo services as native services and invoke them as they would any other service, similarly Tuxedo sees these external systems as native Tuxedo services and invokes them as it would any other service. This provides relatively seamless integration between legacy environments and Tuxedo and allows either side to operate as a server to the other, in other words these interfaces are symmetric.
In addition to treating legacy mainframe interfaces and other Tuxedo domains in the same way as local services Tuxedo can also do this for such open system standards as CORBA and java code running in WebLogic Server. CORBA applications can invoke Tux services through the CORBA API and Tuxedo services can invoke CORBA objects. The WebLogic Tuxedo Connector (WTC) extends the capabilities of Jolt to become fully symmetric in that EJBs in WebLogic can be invoked as services from Tuxedo.
Note that all the interfaces we have spoken about so far are transactional, as in they are part of the Tuxedo transaction infrastructure, invoking a remote mainframe transaction may cause an XA transaction to be started within Tuxedo. When calling an EJB in WebLogic this also is part of the overall Tuxedo XA transaction infrastructure.
There are two alternative ways to get Web Services to access Tuxedo. The most obvious is to use SALT (Service Architecture Leveraging Tuxedo) which exposes Tuxedo services as web services, and allows Tuxedo to invoke Web Services as though they were Tuxedo services. This is a symmetric interface and takes care of all the XML to Tuxedo translations but it is not transactional. The web service call is not part of the transaction. A web service request to Tuxedo may cause a Tux transaction to be initiated, but webs services don’t currently provide a transactional context. Similarly when Tux makes a call to a web service, that call is not part of any Tuxedo transaction.
So what if you want transactionality and access to web services. This is where the service bus comes in. The Oracle Service Bus (OSB) takes advantage of the WebLogic Tuxedo Connector to provide a fast efficient and transactional interface to and from the Tuxedo world. This allows a pipeline to make two seperate calls to Tuxedo as part of the same transaction. Note that there are a couple fo wrinkles to making this happen and I will deal with those in a later post.
Not only is Tuxedo the original service oriented architecture but despite being more than 20 years old, through SALT and WebLogic Tuxedo Connector it still speaks the modern lingo of service buses, Java, XML, SOAP and HTTP. So if you have a Tuxedo investment don’t write it off, but look at how you can more easily make your Tux services available to the new fangled XML based web service world.