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.