Product Overview

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Oracle Tuxedo ATMI Core Components

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


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:


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

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:

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.


Oracle Tuxedo ATMI Architecture

Oracle Tuxedo ATMI consists of the following main components:


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

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.

The Oracle Tuxedo Administration Console and SNMP agents can interact with standard management consoles, which enables administrators to manage an Oracle Tuxedo ATMI or CORBA environment and a network configuration from one console. In addition, application architects and developers can build their own administrative tools or application-specific or market-specific tools on top of the Tuxedo management information base (TMIB) accessible through the MIB interface.

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.

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.

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:

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.

ATMI Interface Documentation

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

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 Typed Buffers for a brief description of data 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.

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 “What Are Typed Buffers?” in Introducing Oracle Tuxedo ATMI.


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:

Workstation Communication

The Workstation component involves the following software processes:

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

Workstation Documentation

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


Oracle Tuxedo /Q

Oracle Tuxedo /Q is a transactionally enabled, XA compliant, application queuing system incorporating typed buffers. /Q provides for time-independent communication among clients and servers in an Oracle Tuxedo ATMI application.

/Q makes it possible for an ATMI application, within a global transaction, to store client and server generated messages to stable storage for processing later. A Q-enabled client or server process decides when it wants to retrieve a message off its queue. However, because the operation is within the scope of a transaction, the Oracle Tuxedo system ensures that either the message will eventually be processed or the entire transaction will be rolled back.

/Q can be combined with Oracle Tuxedo Workstation to store and retrieve messages from Workstation clients. The interface for this combination is available in both the C and COBOL programming languages.

Storing and Retrieving Messages

Time-independent client and server programs communicate by storing (queuing) messages for each other in application queues. Messages can be retrieved (dequeued) in any of several ordering schemes, including last in, first out (LIFO), first in, first out (FIFO), priority order, and time-based order. More than one client and server can access the same queue. The following figure shows at a high level how message queuing communication works using /Q.

Figure 2-4 Queue-Based Messaging

Queue-Based Messaging

/Q Documentation

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


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

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-5 Event Subscription, Posting, and Notification

Event Subscription, Posting, and Notification

Posting an event in a global transaction means that all of the work, including work not related to the posting, is ensured to be complete if the transaction is successful. If any work performed within the transaction fails, all the work done within the transaction will be rolled back.

EventBroker Documentation

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


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-6 Domain Gateway Types

Domain Gateway Types

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.

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.

Domains Documentation

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

  Back to Top       Previous  Next