Understanding Tuxedo through modern lens

In this section, we will look at various aspects of Tuxedo through a modern lens. We cannot cover all of them, but I believe each sections covers an aspect that is still relevant today.

Availability

If a Tuxedo server process crashes, it will get restarted. Multiple copies of the same executable may be run at the same time for redundancy. Multiple machines may be used to improve availability when one of them crashes. Tuxedo will load balance requests between the processes and machines that are up and running to minimize response time.

All Tuxedo applications have an administrative process that looks for servers that are stuck or have crashed and restarts them.

It is also possible to reconfigure a Tuxedo application without downtime. Adding more servers, and changing and reconfiguring existing ones – it can all be done while the application is running. Also, new versions of the software can be deployed without interrupting business processes.

Performance

The Tuxedo framework itself is fast and requires few resources. The performance cost on top of your application code will be very low.

This is partially because of the IPC queues used for the communication mechanism. The roundtrip latency, that is, sending a request and receiving a response, is less than 40 microseconds. Yes, that is 0.000040 seconds for a service call between two processes on the same machine.

The other reason for such performance is at-most-once delivery semantics, also known as fire-and-forget. It provides no message delivery guarantees and the sender is responsible for retrying the request and coming up with a way for a receiver to filter duplicate requests. If that sounds scary at first, this approach is similar to the UDP protocol, which offers better performance compared to TCP/IP. The application can be made reliable by using reliable queues or other mechanisms.

Oracle Tuxedo, along with Oracle Database, was used in transaction processing the TPC-C benchmark to achieve more than 500,000 transactions/second (http://www.tpc.org/tpcc/results/tpcc_results5.asp). Hundreds and thousands of business transactions per second are processed by Tuxedo running on smaller servers and laptops. To give you some perspective, Bitcoin is limited to around 7 transactions per second.

Services

Tuxedo is a message-oriented middleware. It works by sending and receiving messages through IPC queues. However, a typical Tuxedo API does not mention IPC queues as other message-oriented middlewares do. Tuxedo has an abstraction on top of the queues called a service. Each Tuxedo server implements one or more services. A service may be backed by a single queue or by multiple queues, or multiple services may share the same queue. All of that is transparent to the application code. A service might even be running on a different machine, but that is a concern for the administrator configuring the application, not the developer.

What about microservices or macroservices? Tuxedo is neutral in this regard: you are free to implement one big monolith service or many smaller ones, each using a different storage functionality and implementation language. It is a design choice, not a technical decision. When you do implement your application as many smaller services, Tuxedo will help you to make them transactional if you want to.

Polyglot development

Tuxedo natively supports the C and COBOL programming languages and Tuxedo's development tools produce output in one of those languages.

Since you can write C-like code in C++, you can use C++ to develop Tuxedo applications as long as you take care of exception propagation and typecasting, and avoid some pitfalls. Tuxedo comes with support for writing Java code; however, your Java code will look more like C code than idiomatic and modern Java. Other languages, such as PHP, Python, and Ruby, are supported through a technology called Service Component Architecture (SCA).

Transactions

Distributed transactions, or XA transactions, have a bad name these days, but I blame this on poor implementation in application servers. In Tuxedo, they work like a charm. You should design your application to avoid the need for distributed transactions, but when you need the consistency and are tempted to implement a solution with compensating transactions, just let Tuxedo do its work.

XATMI

X/Open ATMI (XATMI) stands for the Application to Transaction Monitor Interface and was based on existing Tuxedo API calls. It introduces typed buffers, which are used to exchange messages between parts of the application with the API to allocate, inspect, and release them. It also describes what a service is and how it is implemented. Finally, it specifies APIs for different messaging patterns: synchronous and asynchronous calls and conversational paradigms.

However, this standard captured what Tuxedo was capable of at some point in time. Tuxedo has since gained new APIs and supports typed buffers with more features and is better suited for complex applications. Think of XATMI as the SQL standard for databases: while the API is standardized, there are plenty of behavior differences not covered by the standard, and Tuxedo's XATMI will always be one of a kind.

Tuxedo today

Tuxedo became a product of the Oracle Corporation in 2008 and is now a part of Oracle Fusion Middleware, with the latest stable release being 12.2.2 in 2016. Tuxedo is a commercial, closed source product. With the current trend of relying on open source software, we will not see Tuxedo gaining huge popularity and acceptance. Most likely, it will not be used to develop new applications unless you use it already in your organization.

However, Tuxedo applications run a significant part of critical infrastructure in banking, telecommunications, payments, and many others. Just like COBOL, it is not going to disappear in the next few years; Tuxedo is here to stay for years to come. Those applications have to be maintained and enhanced and learning about Tuxedo might be a future job for you.

With detailed knowledge of Tuxedo, we are now ready to move on to the next section, where we will try to justify the use of the Python programming language.