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.

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.

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.

As I am writing this book, Python is the third most popular language according to the TIOBE Programming Community index. Given current trends, it may surpass Java and secure second place by the time this book is published. The only other language more popular than Python and Java is C.

So why should you choose Python instead of C or C++, which is supported natively by Tuxedo? Well, Python is simply a more productive tool for writing application logic. Unlike C, Python comes with "batteries included" and contains tools and libraries for many tasks. If the libraries included are not enough, Python has standard tools to download and install open source libraries for the missing functionality.

Python is a dynamic language and has some problems because of its dynamic nature, but, at the same time, it makes Python code easier to test by using mocks for database access and Tuxedo service calls. The same mocking enables you to migrate code away from Tuxedo if you choose to do so. It serves as an abstraction layer on top of Tuxedo, isolating your code from some of Tuxedo's APIs.

Even if the application is written in C or COBOL, using Python is beneficial for testing and quality assurance. It can be used for building a quick prototype before implementing it in C. There are plenty of good reasons to give it a try.

Tuxedo already comes with Python support, but sadly, the SCA standard did not gain popularity and is considered dead. Nothing prevents you from using SCA, but that is another API to learn in addition to XATMI and it exposes fewer features than Tuxedo provides. We will use something that does not hide the powerful XATMI and Tuxedo's improvements on top of it.

There are several open source libraries for developing Tuxedo applications using Python. This book will use Python's tuxedo module for all examples, but many examples can be implemented with slightly outdated tuxmodule or tux_oracle modules as well. And since those are open source modules, you can always add missing functionality yourself.

Oracle provides Dockerfiles and commands to build Docker images for Oracle products on GitHub (https://github.com/oracle/docker-images). Tuxedo is no exception, although Oracle considers it old content and has moved into an archive location where it is available today. Therefore, we will create more up-to-date Docker images ourselves.

To install Tuxedo, you must first download it from the Oracle website (http://www.oracle.com/technetwork/middleware/tuxedo/downloads/index.html). You will have to create an account if you don't already have one. Tuxedo is available for different operating systems: AIX, Linux, HP-UX, Solaris, and Microsoft Windows. For all examples in this book, we will use the latest release of Oracle Tuxedo 12cR2 (12.2.2) and an installation package that includes all the required add-ons called "Oracle Tuxedo 12cR2 (12.2.2)" (including Tuxedo, SALT, and Jolt) for Linux x86-64 (64-bit). The downloaded file will be named tuxedo122200_64_Linux_01_x86.zip.

Create a new folder and put the downloaded tuxedo122200_64_Linux_01_x86.zip file there. You will need to create tuxedo1222.rsp and Dockerfile files in the same folder as the downloaded file.

We start with tuxedo1222.rsp, which contains answers for Oracle Tuxedo installer so that it can be installed in silent mode:

RESPONSEFILE_VERSION=2.2.1.0.0
FROM_LOCATION="/home/oracle/Disk1/stage/products.xml"
ORACLE_HOME="/home/oracle/tuxhome"
ORACLE_HOME_NAME="tuxhome"
INSTALL_TYPE="Custom Install"
DEPENDENCY_LIST={"tuxedoServer:12.2.2.0.0","atmiClient:12.2.2.0.0"}
TLISTEN_PASSWORD="oracle"

This is a minimized response file that contains only the required responses. Here are the most important things:

• FROM_LOCATION gives the location of the unpacked ZIP file.
• ORACLE_HOME and ORACLE_HOME_NAME say that Tuxedo will be installed under /home/oracle/tuxhome.
• INSTALL_TYPE says we will install only selected components.
• TOPLEVEL_COMPONENT and DEPENDENCY_LIST say that only the core Tuxedo should be installed.

Then we need a Dockerfile file that contains instructions for building a Docker image:

FROM oraclelinux:8
RUN yum -y install oracle-release-el8 && \
    yum -y install \
           libnsl java-devel gcc-c++ python3-devel \
           unzip file hostname which sudo && \
    rm -rf /var/cache/yum
RUN groupadd oracle && \
        useradd -m -g oracle -s /bin/bash oracle && \
        echo 'oracle ALL=(ALL) NOPASSWD:ALL' \
        >> /etc/sudoers.d/oracle
USER oracle
COPY tuxedo1222.rsp tuxedo122200_64_Linux_01_x86.zip /home/oracle/
ENV ORACLE_HOME=/home/oracle/tuxhome \
    JAVA_HOME=/etc/alternatives/java_sdk
RUN cd ~/ && \
      jar xf tuxedo122200_64_Linux_01_x86.zip && \
      cd ~/Disk1/install && \
      chmod -R +x * && \
      ./runInstaller.sh -responseFile ~/tuxedo1222.rsp \
            -silent -waitforcompletion && \
      rm -rf ~/Disk1 && \
      rm -f ~/tuxedo1222.rsp ~/tuxedo122200_64_Linux_01_x86.zip
ENV TUXDIR=/home/oracle/tuxhome/tuxedo12.2.2.0.0
ENV PATH=$PATH:$TUXDIR/bin
ENV LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$TUXDIR/lib
USER root
RUN pip3 install tuxedo
USER oracle
WORKDIR /home/oracle

Once you have it, you can run the following command:

docker build -t tuxpy .

This command creates the Docker image. While it runs for several minutes, let's take a look at the most important steps:

1. The Docker image will be created from Oracle Linux 8. Other Linux distributions may also be used, but the choice of Oracle Linux will come in handy when we start using the Oracle database.
2. We run the yum package manager to install Python version 3, Java for running the Oracle Tuxedo installer, and the GCC compiler for building a Python module.
3. We create a regular Linux user named oracle and give permissions to run sudo for installing other software packages.
4. Once all the files are put into the container, the Tuxedo installation is unpacked.
5. The Tuxedo installation is run in non-interactive mode with a response file containing all the necessary inputs. Tuxedo can also be installed using a graphical interface or console interface like all other Oracle products, which is handy if you don't use containers.
6. We export the TUXDIR environment variable that points to the directory where Tuxedo is installed and set up program and library paths to include Tuxedo binaries.
7. After that is done, the Python tuxedo module is installed using the pip3 tool.

After that, you can start the newly created image by using the following command:

docker run -ti --privileged tuxpy bash

If you are using Docker Desktop on Microsoft Windows, you may need to add winpty in front of the command:

winpty docker run -ti --privileged tuxpy bash

The --privileged parameter gives extended privileges to the container that will be needed in Chapter 3, Tuxedo in Detail to resize message queues.

If you have any preferences for a text editor or other tools, you can install them by using sudo yum install and the package name. As an exercise, take a look at the Python examples that use SCA under $TUXDIR/samples/sca/simp_python. It will make you appreciate the simplicity of your first Tuxedo application in Python, which we will create in the next chapter.

In this chapter, we introduced the decades-old Tuxedo framework for building distributed applications and technology that is still relevant today. We also looked at the current state of Tuxedo through the eyes of a fellow Tuxedo user and why the Python programming language is a good choice for development in the year 2021 and beyond. Lastly, we prepared a development environment by installing Tuxedo and Python in a Docker image. While it might not be a good idea to use a Docker container as the main development machine, it makes a nice throwaway sandbox for trying out code samples.

These topics helped you to acquire basic knowledge of Tuxedo and set up a working environment for creating applications. We will move things on in the next chapter, where you will build your first application.

1. Which programming languages are supported by Tuxedo?
2. How old is Tuxedo?
3. What kind of queues does Tuxedo use?

• Getting Started with Oracle Tuxedo, by Biru Chattopadhayay, describes Tuxedo from a different angle and provides the perspective of a Tuxedo application administrator.