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.
Note:
|
Often, the term domain, or application, is intended to mean the server-side software of a Oracle Tuxedo client/server application.
|
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 a 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 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
and 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 (BB) is a memory segment in which all the application configuration and dynamic processing information is held at run time for a Oracle Tuxedo application. It provides the following functionality:
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.
•
|
UBBCONFIG(5), WS_MIB(5), and WSL(5)in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference
|
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.
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.
•
|
AUTHSVR(5)in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference
|
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.
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.
•
|
TM_MIB(5)in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference
|
The TMQUEUE server stores (enqueues) and retrieves (dequeues) messages on behalf of clients and servers. The following figure shows how
TMQUEUE works.
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 a 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.
•
|
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).
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.
•
|
DMADM(5), DMCONFIG(5), GWADM(5), GWTDOMAIN(5), and UBBCONFIG(5) in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference
|
|
|
|
|
|
|
|
|
|
|
|
|
tmloadcf, tmunloadcf, tmboot, tmadmin, ...
|
|
|
|
DMCONFIG, BDMCONFIG, DMADM, GWADM, GWTDOMAIN, DMTLOG
dmloadcf, dmunloadcf, dmadmin
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|