Section 1: The Basics
In this section, we will introduce Tuxedo and get a development environment ready for the rest of the book. We will cover the Tuxedo client-server architecture and messages sent between clients and servers in depth from both the Tuxedo and UNIX sides.
This section has the following chapters:
- Chapter 1, Introduction and Installing Tuxedo
- Chapter 2, Building Our First Tuxedo Application
- Chapter 3, Tuxedo in Detail
- Chapter 4, Understanding Typed Buffers
Chapter 1: Introduction and Installing Tuxedo
In this chapter, we will introduce Tuxedo and learn why it is still relevant and in use even today. I will try to convince you that the Python programming language is a good choice when it comes to writing, extending, and improving Tuxedo applications. And finally, we will create a development environment for learning Tuxedo development using Python.
We will cover the following topics in this chapter:
- Introducing Tuxedo
- Understanding Tuxedo through modern lens
- Reviewing the need for Python
- Installing Tuxedo and Python
By the end of this chapter, you will have a good understanding of Tuxedo and have your environment set up for building your own applications.
Technical requirements
To follow the instructions in this chapter, you will require the following:
- Docker for Linux, or Docker Desktop for Windows 10
- A 64-bit processor
- At least 3 GB of free disk space
- At least 4 GB of RAM, but 8 GB is strongly recommended
You can find the code files for this chapter on GitHub at https://github.com/PacktPublishing/Modernizing-Oracle-Tuxedo-Applications-with-Python/tree/main/Chapter01. The Code in Action video for the chapter can be found at https://bit.ly/3rWX4Gh.
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.
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 respon...
