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

BEA Tuxedo ATMI Core Components

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


Important BEA Tuxedo Terms and Concepts

The following terms and concepts are fundamental to understanding the BEA Tuxedo system and applications built on the BEA Tuxedo system:


BEA Tuxedo ATMI Overview

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

BEA Tuxedo ATMI is a transaction application server that runs server-side applications and components. Besides managing an application’s server processes and managing transactions, BEA 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 BEA Tuxedo ATMI, orchestrates the actions of all the participants and makes them act as part of a transaction.


BEA Tuxedo ATMI Architecture

BEA Tuxedo ATMI consists of the following main components:


BEA Tuxedo Transaction Processor and Infrastructure

The BEA Tuxedo infrastructure provides the bedrock client/server architecture for both BEA Tuxedo ATMI and BEA Tuxedo CORBA. The transaction processor and infrastructure discussed here and illustrated in the following figure constitute the BEA 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 BEA Tuxedo ATMI Environment

BEA Tuxedo ATMI Environment

System Management Interface

The BEA Tuxedo system management interface, common to both BEA Tuxedo ATMI and BEA 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. BEA Tuxedo provides an open tool environment that is supported by many third-party tools.

The BEA Tuxedo Administration Console and SNMP agents can interact with standard management consoles, which enables administrators to manage a BEA 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

BEA 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 BEA Tuxedo system. The ATMI interface and the BEA Tuxedo system implement the X/Open distributed transaction processing (DTP) model for transaction processing.

The BEA 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 BEA 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 BEA 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 BEA Tuxedo ATMI interface, see Introducing BEA Tuxedo ATMI.

FML Programming Interface

In addition to the ATMI interface, BEA 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 BEA Tuxedo FML, see Programming a BEA Tuxedo Application Using FML.

Typed Buffers

BEA 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 BEA Tuxedo system in which to place their data.

Typed buffers are data structures defined by application programmers and made known to the BEA Tuxedo system. Because the BEA 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 a BEA 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.

BEA 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 BEA Tuxedo ATMI.


BEA Tuxedo Workstation

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

Advantages of the BEA 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 BEA Tuxedo server application.

Figure 2-3 Connecting Remote ATMI Clients

Connecting Remote ATMI Clients

Workstation Documentation

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


BEA Tuxedo /Q

BEA 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 a BEA 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 BEA Tuxedo system ensures that either the message will eventually be processed or the entire transaction will be rolled back.

/Q can be combined with BEA 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 BEA Tuxedo /Q component, see the following documents:


BEA Tuxedo EventBroker

BEA 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 a BEA 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 BEA 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 BEA Tuxedo EventBroker component, see the following documents:


BEA Tuxedo Domains

The BEA Tuxedo Domains component extends the BEA 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 BEA Tuxedo system offers the following types of domain gateways to allow a BEA Tuxedo application to communicate with other BEA Tuxedo applications or with applications running on other TP systems.

Figure 2-6 Domain Gateway Types

Domain Gateway Types

Note: BEA 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 BEA Tuxedo CORBA applications.

Transparency Between Domains

In a BEA 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 BEA Tuxedo Domains component, see the following documents:

  Back to Top       Previous  Next