Introducing Oracle Tuxedo ATMI

Oracle Tuxedo System Administration and Server Processes

The following sections describe the core Oracle Tuxedo system administration and server processes that together form the infrastructure for ATMI applications built on the Oracle Tuxedo system:

Oracle Tuxedo ATMI Infrastructure

The following categories of Oracle Tuxedo system processes provide an infrastructure for the efficient routing, dispatching, and management of application service requests, application queues, and event postings and notifications for ATMI applications:

Before exploring these categories of Oracle Tuxedo system processes, you should have a good understanding of the following important Oracle Tuxedo terms and concepts.

Oracle Tuxedo Domain

An Oracle Tuxedo domain, also known as an Oracle Tuxedo application, is a set of Oracle Tuxedo system, client, and server processes administered as a single unit from a single Oracle Tuxedo configuration file. An Oracle Tuxedo domain consists of many system processes, one or more application client processes, one or more application server processes, and one or more computer machines connected over a network.

The following figure presents a high-level view of an Oracle Tuxedo domain.

In Oracle Tuxedo terminology, a domain is the same as an application—a business application; both terms are used as synonyms throughout the Oracle Tuxedo user documentation. Examples of business applications currently running on Oracle Tuxedo are airline and hotel reservation systems, credit authorization systems, stock-brokerage systems, banking systems, and automatic teller machines.

The application processes running on the client side of an Oracle Tuxedo client/server application are usually referred to as application clients or simply clients. The application processes running on the server side of an Oracle Tuxedo client/server application are usually referred to as application servers.

Oracle Tuxedo Configuration File

Each Oracle Tuxedo domain is controlled by a configuration file in which installation-dependent parameters are defined. The text version of the configuration file is referred to as UBBCONFIG, although the configuration file may have any name, as long as the content of the file conforms to the format described on reference page UBBCON FIG(5)in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference. Typical configuration filenames begin with the string ubb, followed by a mnemonic string, such as simple in the filename ubbsimple.

The UBBCONFIG file for an Oracle Tuxedo domain contains all the information necessary to boot the application, such as lists of its resources, machines, groups, servers, available services, and so on. It consists of nine sections, five of which are required for all configurations: RESOURCES, MACHINES, GROUPS, SERVERS, and SERVICES.

The binary version of the UBBCONFIG file is referred to as TUXCONFIG. As with UBBCONFIG, the TUXCONFIG file may be given any name; the actual name is the device or system filename specified in the TUXCONFIG environment variable.

Oracle Tuxedo Master Machine

The master machine, or master node, for an Oracle Tuxedo domain is a server machine containing the domain’s UBBCONFIG file, and is designated as the master machine in the RESOURCES section of the UBBCONFIG file. Starting, stopping, and administering the one or more server machines in an Oracle Tuxedo domain is done through the master machine.

The master machine for an Oracle Tuxedo domain also contains the master copy of the TUXCONFIG file. Copies of the TUXCONFIG file are propagated to every other server machine—referred to as non-master machines—in an Oracle Tuxedo domain whenever the Oracle Tuxedo system is booted on the master machine.

In a multiple-machine domain running different releases of the Oracle Tuxedo system software, the master machine must run the highest release of the Oracle Tuxedo system software in the domain.

Oracle Tuxedo TUXCONFIG Environment Variable

The TUXCONFIG environment variable defines the location on the master machine where the tmloadcf(1) command loads the binary TUXCONFIG file. It must be set to an absolute pathname ending with the device or system filename where TUXCONFIG is to be loaded.

The TUXCONFIG pathname value is designated in the MACHINES section of the UBBCONFIG file. It is specified for the master machine and for every other server machine in the Oracle Tuxedo domain. When copies of the binary TUXCONFIG file are propagated to non-master machines during system boot, the copies are stored on the non-master machines in accordance to the TUXCONFIG pathname values.

Oracle Tuxedo TUXDIR Environment Variable

The TUXDIR environment variable defines the installation directory of the Oracle Tuxedo system software on the master machine. It must be set to an absolute pathname ending with the name of the installation directory.

The TUXDIR pathname value is designated in the MACHINES section of the UBBCONFIG file. It is specified for the master machine and for every other server machine in the Oracle Tuxedo domain.

Oracle Tuxedo Bulletin Board

The Oracle Tuxedo system uses the TUXCONFIG file to set up a bulletin board (BB) on each server machine in an Oracle Tuxedo domain. When an Oracle Tuxedo server process becomes active, it advertises the names of its services in the bulletin board. Some information in the bulletin board is global and is replicated on every server machine in the Oracle Tuxedo domain (for example, the names and locations of all servers offering a particular service). Other information is local and is visible only on the local bulletin board (for example, the actual number and type of client requests currently waiting on a local server request queue).

The bulletin board provides location and namespace transparency within an Oracle Tuxedo domain. Location transparency means that Oracle Tuxedo client and server processes do not have to be aware of the location of a resource within the Oracle Tuxedo domain. Namespace transparency means that Oracle Tuxedo client and server processes can use the same naming conventions (and namespace) to locate any resource in the Oracle Tuxedo domain.

See Also

Oracle Tuxedo Administration Processes

The Oracle Tuxedo administration processes automate most of the management tasks for a distributed application, including:

This discussion focuses only on the administration processes that set up and manage the bulletin board in an Oracle Tuxedo single-machine or multiple-machine application (domain):

For a description of the administration processes used to start up, shut down, and dynamically reconfigure an Oracle Tuxedo application, see Oracle Tuxedo Management Tools.

What Is the Role of the Bulletin Board?

The bulletin board (BB) is a memory segment in which all the application configuration and dynamic processing information is held at run time for an Oracle Tuxedo application. It provides the following functionality:

Each server machine in an Oracle Tuxedo application contains a bulletin board.

What Is the Role of the Bulletin Board Liaison?

The Bulletin Board Liaison (BBL) is an Oracle Tuxedo administration process running on each server machine in an Oracle Tuxedo application that coordinates changes to the local bulletin board and verifies the sanity of the software programs that are active on the local machine. There is one and only one BBL running on each server machine—including the master machine—in an Oracle Tuxedo domain.

What Is the Distinguished Bulletin Board Liaison (DBBL)?

The Distinguished Bulletin Board Liaison (DBBL) is the Oracle Tuxedo administration process that makes it possible to distribute an application across multiple server machines. The DBBL ensures that the Bulletin Board Liaison (BBL) server on each server machine is alive and functioning correctly. The DBBL runs on the master machine of an application and communicates directly with all administration facilities.

The DBBL ensures that configuration and service addressing information is replicated to the bulletin board on each server machine in the configuration. Servers located on remote machines are accessed through the Bridge process running on the local machine. Servers on the local machine are accessed directly. All local communications are performed through high performance operating system message queues. Remote communications are performed in two phases. First, service requests are forwarded to a remote machine through the (local) Bridge. Second, when a request reaches the remote machine, operating system messages are used to send the request to the appropriate server process.

See Also

Oracle Tuxedo Workstation Servers

The Oracle Tuxedo Workstation server processes allow Workstation clients—remote ATMI clients—to reside on a remote machine that does not have a full Oracle Tuxedo server-side installation, that is, a machine that does not support Oracle Tuxedo administration servers or a bulletin board. All communication between a Workstation client and the Oracle Tuxedo server application takes place over the network.

Workstation clients need enough of the Oracle Tuxedo system software to package the information associated with a request. They can then send that information to a pair of Workstation Listener (WSL) and Workstation Handler (WSH) server processes running in an Oracle Tuxedo application that supports all the Oracle Tuxedo system software, including ATMI functions and networking software. The following figure shows how the WSL and WSH processes connect Workstation clients to the Oracle Tuxedo server application.

What is the Role of the Workstation Listener?

The Workstation Listener (WSL) is an Oracle Tuxedo listening process, running on an Oracle Tuxedo server machine, that accepts connection requests from Workstation clients and assigns connections to a Workstation Handler also running on the server machine. It also manages the pool of Workstation Handler processes, starting and stopping them in response to load demands.

An administrator can define several WSLs in an Oracle Tuxedo domain to distribute and balance the workstation communication load across multiple server machines.

What is the Role of the Workstation Handler?

The Workstation Handler (WSH) is an Oracle Tuxedo gateway process, running on the Oracle Tuxedo server machine, that handles communications between Workstation clients and the Oracle Tuxedo server application. A WSH process resides within the administrative domain of the application and is registered in the local Oracle Tuxedo bulletin board as a client.

Each WSH process can manage multiple Workstation clients. A WSH multiplexes all requests and replies with a particular Workstation client over a single connection.

See Also

Oracle Tuxedo Authentication Server

The Oracle Tuxedo authentication server, named AUTHSRV, allows system administrators to configure the additional security needed to authenticate and authorize Workstation clients. AUTHSVR provides a single service, which verifies whether the user has the correct authentication level.

Administrators can configure Oracle Tuxedo applications with incremental levels of authentication and authorization. Administrators can configure an application so that all servers except AUTHSVR have restricted access to shared resources, such as shared memory and message queues.

Application designers can replace AUTHSVR with an authentication server that implements logic specific to their application. For example, a company may want to develop a custom authentication server so that it can use the popular Kerberos mechanism for authentication.

See Also

Oracle Tuxedo Transaction Management Server

The Oracle Tuxedo transaction management server, named TMS, is responsible for coordinating global transactions, on behalf of Oracle Tuxedo ATMI applications, from their point of origin—typically on the client—across one or more server machines, and then back to the originating client. TMS tracks transaction participants and supervises a two-phase commit protocol, ensuring that transaction commit and rollback are properly handled at each site.

Coordinating Operations

To coordinate all the performed operations and all the modules affected by a transaction, TMS directs the actions of one or more resource managers, such as relational databases, hierarchical databases, filesystems, document stores, message queues, and other back-end services. Together, TMS and the resource managers maintain the atomicity of a transaction, but it is TMS that actually manages the two-phase commit protocol and the recovery (if needed) for the transaction.

Tracking Participants with a Transaction Log

In the transaction log (TLOG), TMS logs a global transaction only after receiving all “yes” replies from the global transaction participants at the end of the first phase of a two-phase commit. A TLOG record indicates that a global transaction should be committed; no TLOG record indicates that the transaction should be rolled back. Each server machine in an Oracle Tuxedo domain should have its own TLOG.

See Also

Oracle Tuxedo Message Queuing Servers

The Oracle Tuxedo message queuing servers provide for time-independent communication among clients and servers in an Oracle Tuxedo ATMI application. They make it possible for an application, within a global transaction, to store client and server generated messages to stable storage for processing later. A client or server process involved in message queuing communications decides when it wants to retrieve a message off its queue.

The Oracle Tuxedo message queuing servers consist of a “message queue manager” server named TMQUEUE and a “message forwarding” server named TMQFORWARD.

What is the Role of the TMQUEUE Server?

The TMQUEUE server stores (enqueues) and retrieves (dequeues) messages on behalf of clients and servers. The following figure shows how TMQUEUE works.

What is the Role of the TMQFORWARD Server?

The TMQFORWARD server dequeues messages and forwards them to the appropriate servers for processing. TMQFORWARD is needed only if queued messages require a service call. For example, a queue may be used (on an Oracle Tuxedo client or server) for interprocess communication in which one process places the message on the queue and another removes it. The following figure shows how TMQFORWARD works.

See Also

Oracle Tuxedo Publish-and-Subscribe Servers

The Oracle Tuxedo publish-and-subscribe servers provides asynchronous routing of application and system events among the processes running in an Oracle Tuxedo ATMI application. An event is a state change or other occurrence in an application program or the Oracle Tuxedo system that may be of interest to an administrator, an operator, or the software. Examples of events are “a stock traded at or above a specified price” or “a network failure occurred.”

The Oracle Tuxedo publish-and-subscribe servers consist of an “application event” server named TMUSREVT and a “system event” server named TMSYSEVT. The TMUSREVT server handles application events on behalf of clients and servers, and the TMSYSEVT server handles system events on behalf of clients and servers. The following figure shows how TMUSREVT and TMSYSEVT work.

See Also

Oracle Tuxedo Domains (Multiple-Domain) Servers

The Oracle Tuxedo Domains (multiple-domain) server processes extend the Oracle Tuxedo system client/server model to provide transaction interoperability across transaction processing (TP) domains. This extension preserves the model and the ATMI interface by making access to services on the remote domain (or accepting service requests from a remote domain) transparent to both the application programmer and the end-user.

The Oracle Tuxedo Domains server processes consist of a “Domains administrative” server named DMADM, a “gateway administrative” server named GWADM, and one of several types of “domain gateway” servers—for example, the TDomain gateway server, implemented by the GWTDOMAIN process. The following figure shows how DMADM, GWADM, and GWTDOMAIN work.

Here is another figure demonstrating the connectivity in a Domains configuration.

What is the Role of the DMADM Server?

The DMADM server provides a registration service for gateway groups. This service is requested by GWADM servers as part of their initialization procedure. The registration service downloads the configuration information required by the requesting gateway group. The DMADM server maintains a list of registered gateway groups, and propagates to these groups any changes made to the Domains configuration file (BDMCONFIG).

How multiple domains are connected and which services they make accessible to one another are defined in Domains configuration files, the text and binary versions of which are known as DMCONFIG and BDMCONFIG, respectively. Each Oracle Tuxedo domain involved in a Domains configuration requires its own Domains configuration file.

What is the Role of the GWADM Server?

The GWADM server registers with the DMADM server to obtain the configuration information used by the corresponding gateway group. GWADM accepts requests from DMADM for run-time statistics or changes in the run-time options of the specified gateway group.

What is the Role of the Domain Gateway Servers?

Domain gateways are highly asynchronous, multitasking server processes that handle outgoing and incoming service requests to or from remote domains. They make access to services across domains transparent to both the application programmer and the application user.

As shown in the following figure, the Oracle Tuxedo system supports several types of domain gateways, to allow an Oracle Tuxedo application to communicate with other Oracle Tuxedo applications or with applications running on other TP systems.

See Also

System Services Available to Different Types of Oracle Tuxedo Configurations

The following table lists the Oracle Tuxedo system services available for an Oracle Tuxedo single-machine, multiple-machine (distributed), and Domains application. The single-machine and multiple-machine applications are Oracle Tuxedo domain configurations. The Domains application is an Oracle Tuxedo Domains configuration consisting of two or more Oracle Tuxedo domains communicating with one another via TDomain (GWTDOMAIN) gateways.