An Oracle Tuxedo domain, also known as an Oracle Tuxedo application, is a set of the 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:

Figure 3-1 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.

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 UBBCONFIG(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.

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.

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.

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 for every other server machine in the Oracle Tuxedo domain.

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

• How to Create a Configuration File in Setting Up an Oracle Tuxedo Application
• Creating the Configuration File for a Distributed ATMI Application in Setting Up an Oracle Tuxedo Application

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:

• Assigns service requests to specific servers. When a service is called, the bulletin board looks up servers that offer the requested service. Based on this information, and any data-dependent routing criteria, the bulletin board places the request data on the request queue of a valid server.
• Maintains dynamic information about the state of an application, such as how many requests are waiting on a given server’s queue and how many requests have been processed.
• Provides server location transparency, allowing an application to be developed independently of deployment. Therefore, development and deployment costs are minimized.
• Supports service name aliases, allowing multiple names to be assigned to the same service. This capability is useful for constructing interpreters, such as gateways.

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

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.

Figure 3-2 Bulletin Board and Bulletin Board Liaison

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

Distributing ATMI Applications Across a Network in Setting Up an Oracle Tuxedo Application

Setting Up the Network for a Distributed Application in Setting Up an Oracle Tuxedo Application

Managing the Network in a Distributed Application in Administering an Oracle Tuxedo Application at Run Time

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.

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

• Using the Oracle Tuxedo ATMI Workstation Component
• Administering Security in Using Security in ATMI Applications
• UBBCONFIG(5), WS_MIB(5), and WSL(5) in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference

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.

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

• Configuring Your ATMI Application to Use Transactions in Setting Up an Oracle Tuxedo Application
• Using Transactions in Tutorials for Developing BEA Tuxedo ATMI Applications
• TM_MIB(5) Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference

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.

Figure 3-6 Storing and Forwarding Messages Using TMQFORWARD

See Also

• Administering Your Application Queues Using Command-Line Utilities
• Using the ATMI /Q Component
• tpenqueue(3c) and tpdequeue(3c) in BEA Tuxedo ATMI C Function Reference
• APPQ_MIB(5), TMQUEUE(5), TMQFORWARD(5), and UBBCONFIG(5) in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference

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.

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.

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.

Figure 3-10 Domain Gateway Types

See Also

Administering Your Domains Application Using Command-Line Utilities

Using the Oracle Tuxedo Domains Component

DMADM(5), DMCONFIG(5), GWADM(5),GWTDOMAIN(5), and UBBCONFIG(5) in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference