|
|
The following sections describe the BEA Tuxedo ATMI components and the BEA Tuxedo infrastructure:
The following terms and concepts are fundamental to understanding the BEA Tuxedo system and applications built on the BEA Tuxedo system:
A BEA Tuxedo domain, also known as a BEA 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. A BEA Tuxedo domain may provide ATMI services, CORBA objects, or both.
| Note: | A Tuxedo domain has the same meaning as a Tuxedo application. |
Each BEA 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 BEA Tuxedo 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.
The master machine, or master node, for a BEA 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.
The BEA 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.
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.
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:
Request/response transactions usually involve people and thus require immediate attention; they run in high-priority mode. BEA Tuxedo ATMI provides an ATMI request/response transactional communication interface.
Conversational transactions also usually involve people and thus require immediate attention; they run in high-priority mode. BEA Tuxedo ATMI provides an ATMI conversational transactional communication interface.
Queued transactions can run as high-priority or low priority messages. BEA Tuxedo ATMI includes its own bundled version of recoverable queues called /Q.
Publish-and-subscribe transactions usually run as high-priority messages. BEA 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 BEA Tuxedo ATMI, orchestrates the actions of all the participants and makes them act as part of a transaction.
BEA Tuxedo ATMI consists of the following main components:
Provides the core services needed to run and administer a distributed ATMI application.
Allows ATMI clients to reside on intelligent workstations and communicate over a network connection with an ATMI server application
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.
Provides a publish-and-subscribe capability that brokers the distribution of application and system events between ATMI clients and servers.
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.
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.
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.
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.
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.
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.
For more information on the BEA Tuxedo ATMI interface, see Introducing BEA Tuxedo ATMI.
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.
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.
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:
The Workstation component involves the following software processes:
An ATMI client process that runs on a machine on which the BEA Tuxedo Workstation client software is installed.
A BEA Tuxedo listening process, running on a BEA 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.
A BEA Tuxedo gateway process, running on the BEA Tuxedo server machine, that handles communications between Workstation clients and the BEA Tuxedo server application. A WSH process resides within the administrative domain of the application and is registered in the local BEA 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 BEA Tuxedo server application.
For more information about the BEA Tuxedo Workstation component, see the following documents:
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.
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.
For more information about the BEA Tuxedo /Q component, see the following documents:
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.”
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.
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.
For more information about the BEA Tuxedo EventBroker component, see the following documents:
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.
| 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. |
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.
For more information about the BEA Tuxedo Domains component, see the following documents:
|