Getting Started with Oracle Tuxedo

Chapter 1. Getting Started with Tuxedo

In this introductory chapter, we'll discuss Oracle Tuxedo for distributed client/server technology and how it has evolved over the past decades. It gives you a comprehensive overview of Tuxedo architecture and its various important components and their functionalities. It then follows with Tuxedo installation procedures in brief and hardware and software requirement guidelines.

Introduction to the distributed client/server architecture using Tuxedo

Tuxedo is a middleware for building multitier client/server applications in heterogeneous distributed environments. It stands for Transactions under UniX Extended for Distributed Operation (TUXEDO). It is also called the Transaction Monitoring (TP Monitor) system. Tuxedo has been around for more than three decades now and it is expanding every day. Today, the Service Oriented Architecture (SOA) or Service Component Architecture (SCA) is considered as the new architectural approach, but Tuxedo has been based on this approach from the beginning. Tuxedo has been used to build various mission-critical distributed applications around the world that are extremely scalable, reliable, and highly available in nature. One may question whether Tuxedo is still relevant in the current IT scenarios? The answer is YES! It can easily be extended to an SOA environment, where the Tuxedo service can be called as a component of a composite in SCA-based applications. The latest Tuxedo can run on an Exalogic machine, one of most futuristic machines for cloud computing. All these features are very natural to the Tuxedo environment and returns better ROI.

In Tuxedo, a client program acts like a consumer who initiates a call to the service or a server, which is the provider for the service. The service is always in a ready state to accept a request from the client.

Some of the basic features of Tuxedo in the distributed client/server model are as follows:

The server and the client are functional modules with distinct interfaces. The APIs are standards-based (SCA, XATMI, and CORBA). The functions performed by a client and a server can be implemented by a set of software modules run on the same or different machines.
Each client/server association is established between two functional components when a client component initiates a service request for a server, which responds to the service request.
Transaction management is one of the most important features of Tuxedo; for example, two-phase commit protocol, which is also known as XA.
Tuxedo provides a reliable message queuing mechanism called /Q, which supports XA. It provides a reliable and persistent queuing technique that allows applications to unequivocally queue requests to a queue.
The following additional features, although not required, are typical of the client/server model:
- There are various types of message-passing mechanisms, which are typically asynchronous, synchronous, unsolicited notification, conversational, or publish/subscribe.
- Clients and servers typically reside on separate machines connected through a network, but they can reside in the same machine too.
There are various security features such as auditing, authorization, authentication, and encryption available for use.

Some of the benefits of client/server technology

The advantages or benefits of a clean client/server model are manifold; some of them are as follows:

Modular application design – Divides application processing across multiple machines, with the following conditions:
- Non-critical data and functions are processed on the client
- Critical functions are processed on the server
Optimization – Optimizes the server for data processing and storage (for example, large computers and disk space)
Reduced network traffic – Due to the three-tier architecture, data doesn't need to travel back and forth from frontend clients to databases multiple times
Scales horizontally – Multiple servers, each having capabilities and processing power, can be added to distribute processing load
Scales vertically – Can be moved to more powerful machines, such as a minicomputer or a mainframe, to take advantage of the larger system's performance
Reduces data duplication – Data is stored on the servers instead of clients, reducing the amount of data replication for the application

The history of Tuxedo

Tuxedo was developed by Bell Labs in 1983 to achieve multiuser access and manipulate a database on a mainframe computer simultaneously. In 1989, the Unix System Laboratories (USL) promoted Tuxedo as a client/server framework and launched this product. In 1993, Novell acquired USL and Tuxedo became Novell's product. In 1996, BEA bought the rights for Tuxedo from Novell. Tuxedo did wonders for many Fortune 500 companies around the world. In 2008, Tuxedo became an Oracle product along with all the other BEA Systems products, for example, WebLogic server, and others.

Tuxedo architecture and anatomy

Clients and servers are the application-processing components of a Tuxedo system. Server processes provide one or more named services. Client processes can request services without having to know where they are located. The named service feature provides a directory of services that result in the request being routed to one of the servers providing the service. Clients and servers communicate by sending messages. When the clients and servers are distributed over different machines, Tuxedo makes the networking infrastructure by connecting the client and server machines, while keeping the client/server request-response model transparent. Programmers therefore do not have to worry about where the service is located or what the underlying network protocols are. The application's code remains the same whether the clients and servers are running on a single machine or distributed over multiple machines.

The basic middleware characteristics that Tuxedo supports are as follows:

Simplifies the segregation of the clients' and servers' logic.
Manages and helps in monitoring distributed transactions among multiple data sources.
Extremely modular in nature; one or more servers may fail without affecting the applications running on the same Tuxedo environment.
Communicates with heterogeneous databases using various resource managers within a single application for transactional integrity.
Integrity of the code and data for a server are centrally maintained, making it is easy to maintain and protect data integrity. This supports the horizontal and vertical scalability of applications. Horizontal scaling is adding or removing of hardware with only a small performance effect. Vertical scaling is moving to a bigger and faster server or adding servers.
Supports service-requests prioritization, load balancing, data-dependent routing, and queuing.
The clients and servers are loosely coupled processes that can exchange service requests and replies using messages.

Tuxedo has a very rich set of internal components (shown in the previous diagram) that provide runtime support for application availability, scalability, and extendibility. I will briefly introduce them to you in this chapter and we will be discussing them in detail in the following chapters; they are as follows:

Bulletin Board (BB): This is the first process as you start Tuxedo; it stores the configuration and dynamic information for the whole Tuxedo system. It stays in the shared memory and is available to all the processes of the Tuxedo system. The BB translates a service name to a specific server. When a client calls a service, the BB is used to look up which servers offer the requested service, and based on this information, the request message is put on the request queue of the correct server. Once the message is ready to be passed on to the client, it enqueues it to reply queue for the designated client.
Bulletin Board Liaison (BBL): This Tuxedo administrative process monitors the other processes of Tuxedo systems.
Distinguished BBL: The DBBL is the master monitor for a multimode (clustered) Tuxedo environment, responsible for overseeing the BB on each node. Also, for networked applications, a backup node may be designated for the DBBL.
Bridge: This process is used for multinode (MP mode) configurations, which are responsible for inter-node communications in networked applications.
TMS: This is the transaction manager server dedicated to a particular resource when distributed transaction processing is employed.
Master machine/node: In a multiple machine configuration (clustered), the Tuxedo domain that holds the UBBCONFIG file is called the master machine. All the administering tasks, such as starting, stopping, and monitoring, can be done from this server in a Tuxedo domain.
Tuxedo server processes: These are the executable programs that offer named services through the Tuxedo system. They are normally customer-developed programs. One server (program/executable) may contain one or more service (functions) in it.
Tuxedo client processes: These are executable programs that call services through the Tuxedo system. They are usually customer-developed programs.
Workstation Listener (WSL): This is the Tuxedo server process that works as a listener for the WS client (workstation). As a handshaking process, this server listens to the WS clients and assigns connections to a WS Handler (another Tuxedo-provided server) accordingly for the rest of the correspondence with the WS client until it disconnects from a Tuxedo instance. The WSL manages the pool of WS Handler processes and the demands by starting and stopping them in response to the load.
Workstation Handler (WSH): This is another process provided by Tuxedo that works in conjunction with WSL. This gateway process handles communications between WS clients and the Tuxedo server application. This WSH handles multiple WS clients within the same Tuxedo domain. A WSH works like a multiplexer to accommodate all the requests and replies with a particular WS client over a single connection.
Jolt Listener/Handler (JSL/JSH): These are Tuxedo listening and gateway processes for Java-based workstation clients; they are similar to WSL/WSH in terms of functionality.
TMQUEUE: This message-queuing manager is a Tuxedo-system-supplied server that enqueues and dequeues messages on behalf of programs.
TMQFORWARD: This message-forwarding server is a Tuxedo-system-supplied server that forwards messages from a queue to other servers.
DMADM: This is one of the three servers provided by Tuxedo for using the Tuxedo domain configuration. This is an administrative server that provides a registration service for gateway groups. The DMADM server works with other domain gateway admin servers (GWADM); during the initialization process, it registers the configuration information that is mandatory for the requesting gateway group. The DMADM server preserves all the names of registered gateway groups, and it also proliferates changes to these groups as they are made in the domain configuration file (BDMCONFIG). We will discuss domain configuration in Chapter 3, Development of Tuxedo – Various APIs.
GWADM: This Tuxedo system gateway admin server registers with the DMADM server to get the configuration data used by the other gateway group. This server accepts requests from the domain admin server for runtime information or changes occurred during runtime for a gateway group.
GWTDOMAIN: This Tuxedo system server is called Domain Gateways, and it is very asynchronous in nature. It has the multi-tasking functionality and can handle outgoing and incoming service requests to or from other remote domains.
LMS: The Local Monitor Server (LMS) is a Tuxedo system server. A LMS is required on each Tuxedo machine if the node needs to be monitored; we will discuss this in detail in Chapter 2, Configuration and Administration of Tuxedo, under Tuxedo System and Application Monitoring (TSAM).
GWWS: This is a Tuxedo system server and a major component for Service Architecture Leveraging Tuxedo (SALT). It works like a bidirectional (inbound and outbound) adapter that connects with other web service applications using SOAP over HTTP/S protocols.
Connecting WebLogic Domain: The WebLogic Tuxedo connector is an add-on product that works as a bidirectional adapter for Tuxedo services and WebLogic server applications. The adapter helps the WebLogic server's clients to call a Tuxedo service and Tuxedo clients to call any WebLogic server's Enterprise Java Beans (EJBs).

In this section, we introduced Tuxedo's client/server concepts in brief, its overall architecture, and its various important components. We will discuss them in detail in the following chapters to understand their functionalities and usage patterns. In the following section, we will see how to install Tuxedo and also see what the post-installation tasks are that you must carry out to make sure the installation is successful. The installation of Tuxedo is very simple even though it supports a wide variety of operating systems and hardware. We will focus on the basic installation procedure and its guidelines, which covers your primary requirement of installing Tuxedo.

Installation of Tuxedo

As mentioned before, Tuxedo supports various OSs and hardware; you need to make sure you get the right installable file.

Hardware and software requirements

The Oracle Tuxedo software needs to be installed on each server that will run the Tuxedo application, or can be called Tuxedo domain.

x86 or x86-64 – This denotes various CPUs based on x86 or x86-64 architecture. Most of the current platforms are supported; the following are the most common ones:
- HP 11i (32-bit/64-bit)
- IBM AIX 5.3 (32-bit/64-bit)
- IBM AIX 6.1 (32-bit/64-bit)
- MS Windows 7 (32-bit)
- MS Windows 2008 server (32-bit/64-bit)
- Oracle Enterprise Linux 5.0 (32-bit/64-bit)
- Oracle Solaris 10 (32-bit /64-bit) on x86-64
- Red Hat Linux Enterprise AS 5 (32-bit) on x86
Memory requirements – The following are the minimum memory requirements recommended by Oracle to run your application:
- 1 GB of RAM
- 4 MB of RAM for each Oracle Tuxedo system server
Hard disk – The following is the minimum hard disk requirement recommended by Oracle:
- 2 GB of disk space is required for Tuxedo installation

Note

Note that the Oracle Tuxedo installation program creates a temporary directory to extract the files from the archive prior to installing Tuxedo on the target system. So, it is important to have sufficient space during installation. The JRE is moved to the Oracle home directory from the temporary file at the end of the installation process.

For more details on hardware and operating systems, Oracle Tuxedo's support policy, or more related information, please refer to the following link:

http://docs.oracle.com/cd/E26665_01/tuxedo/docs11gr1/install/inspds.html

Platform-specific installer files for the Oracle Tuxedo product software are available for download at Oracle's corporate website:

http://www.oracle.com/technetwork/middleware/tuxedo/downloads/index.html

Tuxedo installation components

You can start your installation once you have downloaded the installation file, but it is good to know that there are seven installation sets bundled in Tuxedo, and you can choose any one of them during installation. They are listed as follows:

Full: All components of the Oracle Tuxedo 11g Release, that is, the server and client components
Server: The server components of Tuxedo
Full client: The client components of Tuxedo
ATMI (/WS) client: The workstation component of Tuxedo
CORBA client: The C++ client and SSL components of Tuxedo
Jolt client: The Java client (Jolt) components of Tuxedo
.NET client: The .NET version of the workstation client components of Tuxedo

Note

The Oracle home directory is where all the common files (executable and internal files) that are accessed by other Oracle components (residing on the same machine) are stored. It is very important to keep in mind that the home directory is important for ensuring that the Oracle software behaves correctly. During the installation, you are asked for this home directory. According to best practices, you need to have one home directory, though you may choose to have multiple in a system.

Installation procedures

The Oracle Tuxedo can be installed in three different ways; we will briefly go through each of them in the following sections.

Graphical user interface (GUI) installation

The graphical user interface installation is the GUI-based Oracle Tuxedo installation program that runs on Unix- and Windows-based systems. This is the most popular way to install Tuxedo.

The following are the steps to be followed for a GUI-mode installation on a Windows system:

Log in to the Windows system as an administrator (preferred), as you need admin privileges to install Oracle Tuxedo server components on a Windows system. To install Tuxedo client components, you do not need to be logged in as an administrator.
To install Oracle Tuxedo, click on the installer file to start the installation.
Continue running the GUI-mode installation process.
Log in to the system again after the Tuxedo installation is completed.

The following are the steps for a GUI-mode installation on a Unix system:

You need to log in as the Oracle Tuxedo administrator.
You need to go to the directory where you downloaded the installer and run the installation program, as shown in the following sample command:
```
UnixPrompt> sh filename.bin
```
Here, filename is the name of the Oracle Tuxedo installer file.

Note

You will get an error message and the installation process will fail if the GUI interface in your system is not available. In this case, you may want to use the silent or console-mode installation.

Console installation

The console installation is a text-based installation that is only available for Unix systems.

You need to log in as the Oracle Tuxedo administrator.
You need to go to the directory where you downloaded the installer and run the installation program, as shown in the following sample command:
```
UNIXprompt> sh filename.bin -i console
```
Here, filename is the name of the Oracle Tuxedo installer file.
To complete the installation, follow these steps:
1. Enter the number of your choice or press Enter to accept the default.
2. Enter back or previous at the prompt to review or change your selection.
3. Enter quit in response to any prompt to exit the installation process.

Note

Oracle strongly recommends Unix users to create a separate user account for the Oracle Tuxedo administrator and have the ownership of the Oracle Tuxedo files for that account.

Silent installation

The silent installation is a more automated way of installing Tuxedo. This installation reads the strings from a text file that you can create prior to beginning the installation. This can be used as the standardized installation for all installations in the enterprise in such a way that you set the installation configurations only once and use it multiple times. You need to create a properties file for the installer; for detailed step-by-step instructions, please go to the following link:

http://docs.oracle.com/cd/E26665_01/tuxedo/docs11gr1/install/inssil.html

As we are done with the installation (by either of the three processes), it is recommended to verify the Tuxedo ATMI software installation by running simpapp. The sample applications are installed during the Tuxedo installation. You can find this simple application under your Tuxedo directory; \samples\atmi\simpapp. There is a README file in the same directory for a walkthrough.