Introducing Tuxedo
Tuxedo started in the year 1983 at AT&T as a framework for building high-performance, distributed business applications. It has its roots in the DUX (Database for Unix) and TUX (Transactions for Unix) projects, which were combined into a client-server communication framework with support for transactions under the name TUXEDO. Tuxedo stands for Transactions for Unix, Extended for Distributed Operations.
Tuxedo evolved from a client-server framework of release 1.0 to support high availability in release 2.0, and then to distributed and heterogeneous system support in releases 3.0 and 4.0. By release 6.1 and the year 1995, Tuxedo had reached maturity. A book entitled The TUXEDO System was published and it described Tuxedo as we know it today. Tuxedo continued to improve and advance over the later years and gained additional features until the most recent release, 12.2.2, but the core of it is pretty close to what it was in 1995.
Some of the innovations made by the engineers of Tuxedo became standardized; most notably, the XA interface is still implemented by databases and used for distributed transactions even in modern Java applications. Less known is the XATMI standard describing the core Tuxedo API. You may be familiar with the XA and XATMI specifications from X/Open Company, but not many people know that the inspiration came from Tuxedo.
Another fun fact is that Tuxedo enabled Service-Oriented Architecture (SOA) before the term was coined, and it enabled us to write microservices and even transactional microservices before the microservice architectural style became popular. Of course, a framework that is more than three decades old does not fit modern ideas when it comes to application servers, middlewares, microservice frameworks, and so on, but if you take a step back, you will see similarities.
A Unix-inspired application server
Tuxedo is an application server for the C and COBOL programming languages. Application servers, as we know them today for other programming languages, are typically a single process with multiple threads. That leads to isolation problems when multiple applications are running in the same application server. Some languages ignore that, while others try to minimize it by using different class loaders and other techniques. But still, all applications use the same heap memory. A single misbehaving application will affect other applications either by consuming all CPU resources or consuming too much memory.
Tuxedo follows the original Unix philosophy of having many (small) processes that communicate with each other. Such a process is called a server and a Tuxedo application consists of many servers. Another kind of process is a client, which accesses facilities provided by the server but does not provide facilities itself. Unix processes give memory isolation out of the box for Tuxedo applications: memory corruption by one server will not affect others. Processes are also scheduled by the operating system to give each of them a fair share of CPU time. A process can be assigned a priority or be run under different user accounts.
Communication between clients and servers is done using Unix System V ("System Five") inter-process communication (IPC) mechanisms: message queues, shared memory segments, and semaphores. Distributed computing is added transparently on top of that by forwarding messages from queues over the TCP/IP network to a different machine. All Tuxedo applications are distributed applications by design: communication is done by passing messages; a receiver may fail before or after processing the message; the sender may fail before receiving the response. The possibility of failure is exposed in the API.
After getting an idea of what Tuxedo is, let's learn more about it in detail in the next section.
