1. Overview Guide
  2. Oracle Tuxedo ATMI Core Components

2 Oracle Tuxedo ATMI Core Components

The following sections describe the Oracle Tuxedo ATMI components and the Oracle Tuxedo infrastructure:

2.1 Important Oracle Tuxedo Terms and Concepts

The following terms and concepts are fundamental to understanding the Oracle Tuxedo system and applications built on the Oracle Tuxedo system:
Tuxedo domain
An Oracle Tuxedo domain (also known as an Oracle Tuxedo application), is a set of Tuxedo system, client, and server processes administered as a single unit from a single Tuxedo configuration file. A 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. An Oracle Tuxedo domain may provide ATMI services, CORBA objects, or both.

Note:

A Tuxedo domain has the same meaning as a Tuxedo application.
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 UBBCONFIG(5) in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference File Formats, Data Descriptions, MIBs, and System Processes Reference.
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.
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 a Tuxedo domain is done through the master machine.
The master machine for a 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 a Tuxedo domain whenever the Tuxedo system is booted on the master machine.
Tuxedo bulletin board
The Oracle Tuxedo system uses the TUXCONFIG file to set up a bulletin board on each server machine in a Tuxedo domain. When a 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 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 a Tuxedo domain. Location transparency means that Tuxedo client and server processes do not have to be aware of the location of a resource (ATMI service, CORBA C++ object) within the Tuxedo domain. Namespace transparency means that Tuxedo client and server processes can use the same naming conventions (and namespace) to locate any resource in the Tuxedo domain.

2.2 Oracle Tuxedo ATMI Overview

Oracle Tuxedo ATMI is a set of core technologies that enables application designers to create ATMI applications that mix and match hardware platforms, databases, and operating systems. It provides all the features and benefits of a high-end online transaction processing (OLTP) system, including scalability, high-performance, mission-critical reliability, and open standards support.

At the foundation of Oracle Tuxedo ATMI is a proven, reliable transaction processor, also known as a transaction processing (TP) monitor. As shown in the following figure, a transaction processor is an example of a 3-tier client/server architecture, where the transaction processor supports the application logic between the GUI front-end and the back-end resource managers. Examples of resource managers are SQL databases, message queues, legacy applications, and other back-end services.

Figure 2-1 3-Tier Client/Server Architecture Using a Transaction Processor

3-Tier Client/Server Architecture Using a Transaction Processor diagram

By breaking the direct connection between the user interface front-end and the resource managers, a transaction processor controls all the traffic that links hundreds or thousands or even tens of thousands of clients with application programs and the back-end resources. A transaction processor ensures that global (distributed) transactions are completed accurately, provides load balancing, and improves the overall system performance. More importantly, a transaction processor makes an application’s server processes independent of the user interface front-end and any resource manager.

Oracle Tuxedo ATMI is a transaction application server that runs server-side applications and components. Besides managing an application’s server processes and managing transactions, Oracle Tuxedo ATMI also manages client/server communications, that is, allows clients (and servers) to invoke an application service in a variety of ways, including:

Request/response
Request/response transactions usually involve people and thus require immediate attention; they run in high-priority mode. Oracle Tuxedo ATMI provides an ATMI request/response transactional communication interface.
Conversations
Conversational transactions also usually involve people and thus require immediate attention; they run in high-priority mode. Oracle Tuxedo ATMI provides an ATMI conversational transactional communication interface.
Queuing
Queued transactions can run as high-priority or low priority messages. Oracle Tuxedo ATMI includes its own bundled version of recoverable queues called /Q.
Publish-and-subscribe
Publish-and-subscribe transactions usually run as high-priority messages. Oracle Tuxedo ATMI has a transactional publish-and-subscribe system called EventBroker.

Transactional communications use highly augmented versions of remote procedure calls, conversational peer-to-peer, queues, and publish-and-subscribe. However, most of the value-added elements are transparent to the programmer: The transactional client/server exchanges look like ordinary exchanges bracketed by start and end transaction calls. The distinguishing factor is that all resource managers and processes invoked through these calls become part of the transaction. A transaction processor, such as Oracle Tuxedo ATMI, orchestrates the actions of all the participants and makes them act as part of a transaction.

2.3 Oracle Tuxedo ATMI Architecture

Oracle Tuxedo ATMI consists of the following main components:

  • Oracle Tuxedo transaction processor and infrastructure

    Provides the core services needed to run and administer a distributed ATMI application.

  • Oracle Tuxedo Workstation

    Allows ATMI clients to reside on intelligent workstations and communicate over a network connection with an ATMI server application.

  • Oracle Tuxedo /Q

    Provides a messaging and queuing capability to allow ATMI clients and servers to communicate across networks without being linked by a private, dedicated, logical connection.

  • Oracle Tuxedo EventBroker

    Provides a publish-and-subscribe capability that brokers the distribution of application and system events between ATMI clients and servers.

  • Oracle Tuxedo Domains

    Offers the ability to connect ATMI applications that are logically and physically separate so that the combination appears to the user as a single application.

2.4 Oracle Tuxedo Transaction Processor and Infrastructure

The Oracle Tuxedo infrastructure provides the bedrock client/server architecture for both Oracle Tuxedo ATMI and Oracle Tuxedo CORBA. The transaction processor and infrastructure discussed here and illustrated in the following figure constitute the Oracle Tuxedo ATMI environment, which provides request/response and conversational communication interfaces, transaction support, and application-processing and administrative services for a distributed ATMI application.

Figure 2-2 Oracle Tuxedo ATMI Environment

Oracle Tuxedo ATMI Environment Diagram

2.4.1 System Management Interface

The Oracle Tuxedo system management interface, common to both Oracle Tuxedo ATMI and Oracle Tuxedo CORBA, can accommodate tools for administration, such as those described in Management Tools, and tools for application development, such as Simple Network Management Protocol (SNMP) agents. Oracle Tuxedo provides an open tool environment that is supported by many third-party tools.

2.4.2 ATMI Programming Interface

Oracle Tuxedo ATMI supports an ATMI programming interface that offers procedural library-based programming using a set of C or COBOL procedures. ATMI provides an interface for communications, transactions, and data-buffer management that works in all ATMI environments supported by the Oracle Tuxedo system. The ATMI interface and the Oracle Tuxedo system implement the X/Open distributed transaction processing (DTP) model for transaction processing.

The Oracle Tuxedo ATMI interface provides a foundation for request/response and conversational communications.

2.4.2.1 Request/Response Communications

Programmers use the ATMI request/response functions to send a single request from a requesting process, and to receive a single response from the called request/response server process. Request/response is a simple type of dialogue. The rules for communication during request/response are fixed: the client asks for a service and the server responds. The client never sends more than one message as part of its request, and the server never sends more than one response in its reply. For the requesting process, the execution of a request/response service can be synchronous or asynchronous.

2.4.2.2 Conversational Communications

Programmers use the ATMI conversational functions to establish and maintain state-preserving connections—context kept from message to message—between a requesting process and the called conversational server process. Specifically, programmers use the ATMI conversational functions to:

  • Open a connection to a conversational server
  • Begin and end a transaction during the conversation
  • Have a conversation span multiple machines and resource managers
  • Detect and provide notification of connection failures
  • Terminate the connection when satisfied that the task has been completed

A conversational server is dedicated to the originating requester for the duration of the connection. The Oracle Tuxedo system automatically spawns a new copy of a server if one is not available when a conversational connection is requested. Thus, using the ATMI conversational programming interface, programmers can define transaction boundaries within their application so that the work performed can be treated as an atomic unit. What this statement means is that within a single Oracle Tuxedo transaction, the work performed is either committed or rolled back as a single unit of work, which keeps all the databases synchronized, even if there are machine failures.

2.4.2.3 ATMI Interface Documentation

For more information on the Oracle Tuxedo ATMI interface, see ATMI Introduction.

2.4.3 FML Programming Interface

In addition to the ATMI interface, Oracle Tuxedo ATMI supports a Field Manipulation Language (FML) programming interface, which is a set of C language functions for defining and manipulating storage structures called fielded buffers. Fielded buffers contain attribute-value pairs in fields, where the attribute is the field’s identifier, and the associated value represents the field’s data content.

If the FML and its fielded buffer concept are specified by the application designers, application programmers have a rich array of functions for the definition and management of FML fields and buffers (See Managing Typed Buffers.) The selection includes functions to move data back and forth between a fielded buffer and a C structure or COBOL record (referred to as a VIEW), the members of which parallel the buffer’s fields.

The FML function set has a companion function set, FML32, designed for use with larger records with more fields.

For more information on Oracle Tuxedo FML, see Programming an Oracle Tuxedo Application Using FML.

2.4.4 Typed Buffers

Oracle Tuxedo ATMI applications send and receive their data in typed buffers. Instead of allocating memory directly from the operating system, applications allocate typed buffers from the Oracle Tuxedo system in which to place their data.

Typed buffers are data structures defined by application programmers and made known to the Oracle Tuxedo system. Because the Oracle Tuxedo system knows about the application data buffers, it can optimally manipulate them during communication. Typed buffers contain information about themselves (metadata), which allows application programmers to transfer data without needing to know which data representation scheme is used by the machines on which the application’s clients and servers are running. Typed buffers allow applications to maintain machine independence.

Each buffer type supported by an Oracle Tuxedo release has its own set of routines that can be called automatically to initialize; send and receive messages; and encode and decode data without programmer intervention. The set of routines is called a typed buffer switch.

Oracle Tuxedo provides different kinds of typed buffers, including FML and FML32, and allows application designers to define their own typed buffers. For more information about typed buffers, see Managing Typed Buffers in Introducing Oracle Tuxedo ATMI.

2.5 Oracle Tuxedo Workstation

The Oracle Tuxedo Workstation component allows 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 remote ATMI client and the Oracle Tuxedo server application takes place over the network.

Advantages of the Oracle Tuxedo Workstation component include:

  • Less administrative overhead
  • Greater security—keeps clients off the Oracle Tuxedo server machines
  • Off loads CPU cycles and decreases process context switches on Oracle Tuxedo server machines
  • Smaller footprint

2.5.1 Workstation Communication

The Workstation component involves the following software processes:

Workstation Client
An ATMI client process that runs on a machine on which the Oracle Tuxedo Workstation client software is installed.
Workstation Listener (WSL)
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 them in response to load demands.
Workstation Handler (WSH)
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. The following figure shows how these processes are used to connect remote ATMI clients to the Oracle Tuxedo server application.

Figure 2-3 Connecting Remote ATMI Clients

Connecting Remote ATMI Clients

2.5.2 Workstation Documentation

For more information about the Oracle Tuxedo Workstation component, see the following documents:

2.6 Oracle Tuxedo EventBroker

Oracle Tuxedo EventBroker is a transactionally enabled, XA compliant, application publish-and-subscribe system that provides asynchronous routing of application events among the processes running in an Oracle Tuxedo ATMI application. It also distributes system events to whichever application processes want to receive them.

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.”

2.6.1 Mediating Between Producers and Consumers of Events

There are producers of events, called publishers or suppliers, and consumers of events, called subscribers. EventBroker mediates between the producers and consumers about the distribution of events. The following figure shows how publish-and-subscribe communication works using EventBroker.

Figure 2-4 Event Subscription, Posting, and Notifications


Event Subscription, Posting, and Notifications Diagram

When an event is posted in a global transaction, all work, including non-related work, is ensured to be complete if the transaction fails. In the event of any failures within the transaction, all work done within that transaction will be undone.

2.6.2 EventBroker Documentation

For more information about the Oracle Tuxedo EventBroker component, see the following documents:

2.7 Oracle Tuxedo Domains

The Oracle Tuxedo Domains component extends the Oracle Tuxedo system client/server model to provide transaction interoperability across TP domains—business applications. 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 Domains component makes this possible via a highly asynchronous multitasking domain gateway that handles outgoing and incoming service requests to or from remote domains.

The Oracle Tuxedo system offers the following 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 2-5 Domain Gateways Types


Domain Gateways Types Diagram

Note:

Oracle Tuxedo CORBA applications also use the Domains component to interoperate with one another and share resources. Only the TDomain gateway type—implemented by the GWTDOMAIN process—is applicable to Oracle Tuxedo CORBA applications.

2.7.1 Transparency Between Domains

In an Oracle Tuxedo Domains configuration, an administrator can configure which services of a domain are available to other domains in the configuration. The clients and the participating applications themselves do not need to know anything about the Domains configuration. All they need to know is what services or factory objects are available and how to access those services or objects. If applications were to include information about domains, changing configurations would require that the applications be rewritten as well.

2.7.2 Domains Documentation

For more information about the Oracle Tuxedo Domains component, see the following documents: