BEA TUXEDO Architecture

BEA TUXEDO is primarily architected for the Unix operating system, which typically runs on symmetric multi-processor (SMP) machines. Unix is a general-purpose operating system, and does not provide the services required for support of transaction processing applications (for example - transaction management, load-balancing, process restart). BEA TUXEDO provides such services internally, thereby providing an OLTP environment for applications on Unix. An important design goal of BEA TUXEDO is to be portable across Unix implementations and underlying hardware platforms.

Aspects of the BEA TUXEDO architecture which are pertinent to this discussion are as follows:

• Shared Memory.

• Interprocess Messages.

• Transaction Management.

• Process Management.

• Load Balancing.

Shared Memory

SMP machines provide a single physical memory-space which is shared by all cpus in the machine. Memory may be shared between processes regardless of the cpu executing the process.This facet of SMP architecture is exploited by BEA TUXEDO which uses shared memory extensively for data-structures, such as:

Bulletin board (BB) . This contains current configuration and processing state information.Some information in the BB is global and is replicated on every machine in the TUXEDO application (for example, the names and locations of all servers offering a particular service).Other information is local, and visible only within the SMP on which the BB exists (for example, the actual number and type of client requests currently waiting on a local server request queue).The BB is accessed by clients, servers, and the "bulletin board liaison" (BBL) process.

Global transaction table (GTT). This contains current transaction state information. The GTT is accessed by "transaction management server" (TMS) processes

A single SMP equals a TUXEDO "machine" .The BBL is responsible for updating the global information in the BB. There is a BBL on every machine in the application. There is also a single "master" BBL process (the "distinguished" BBL (DBBL)), which is responsible for keeping all the replicated BBs synchronised.Process access to shared-memory is controlled via the use of a combination of user and Unix semaphores.

Interprocess Messages

Client-server communication between processes on the same machine is effected via use of Unix messages and queues. Because Unix messages cannot span machines, communication between processes on different SMP machines is via network transport mechanisms (for example,TCP/IP). A TUXEDO system process (the "Bridge" process) exists on every machine in the application. Bridges are TUXEDO system servers whose function is to route requests from local clients to remote machines, and to route requests from remote machines to local servers (Bridges communicate with each other across the network). Since the scope of a Unix message queue is local to that Unix o/s instance (that is, to a single SMP machine), all the server processes reading from a particular queue must be local to that machine.

Transaction Management

BEA TUXEDO relies on the use of external resource managers for application data-access (for example, RDBMSs). BEA TUXEDO and external RMs cooperate to perform global transaction co-ordination (via the X/Open XA interface). TUXEDO servers may access one or more external RMs as part of a single global transaction. TUXEDO is responsible for coordinating each such RM, so that they all commit, or all roll-back their branch of the transaction (transaction atomicity). This is achieved via the TMS system server process. There is a TMS process for each server group defined in the application. Each TMS manages that portion of the transaction branch executed by servers in its group. One TMS acts as the transaction root. This TMS "knows" which other server groups were involved in the transaction and broadcasts two-phase commit messages to the TMSs in those groups. The subordinate TMSs coordinate with their RM via the XA interface and return the reply to the root

TMS.

The root TMS in each TUXEDO domain, plus each RM involved in the transaction, write a synchronous transaction log record during transaction commitment. There is one TUXEDO physical log-file per machine, plus one physical log-file for each RM instance.

Process Management

One of the key functions of a TP monitor is to provide fast, reliable access to business applications to many clients simultaneously. In TUXEDO, this is done by making server processes available which serially execute client requests (TUXEDO servers are singlethreaded). To ensure server availability, a periodic polling mechanism is used to check whether all server processes are up and running (the periodicity of this check is configurable). Each server instance is "pinged" by its local BBL. If a server has failed, TUXEDO will clean-up and restart the offending server process. If a whole machine fails, the servers on that machine become unavailable until either the machine is manually recovered, or the servers are migrated administratively to another machine. And there is at least one server group for every RM "instance" configured per application. Servers within a server group may only access a single RM instance. e.g. an Oracle instance, or an Informix instance. Servers in different server groups may access the same or different RM instances.

Load Balancing

Fast-response time to clients is achieved via parallelism: several identical server process instances are started, and client requests are distributed evenly between them.If these instances are configured as a multi-server single-queue (MSSQ) set,4 then load balancing is achieved between the servers in the MSSQ-set, since only an idle server will read a request off the queue. If only a single MSSQ-set (or single server) is configured to offer a particular service, then no further load-balancing is required. If however more than one MSSQ-set (or single server) offers a service, then requests must be distributed evenly between the server queues. Two flavours of such load-balancing pertain, within a machine (the client and all servers offering the service are located on the same machine), and across machines (the client and servers offering the service are located on different machines). In both cases, the target server is selected at the client. Within a machine , the BB contains current statistics as to the load on each server queue, and hence exactly the least-loaded server queue can be selected. This is not the case for servers on remote machines (the local site cannot reasonably "know" the load on remote servers; there is no global view). So,in this case a simple, weighted, "round-robin" algorithm is used to toggle between servers on different machine.

1. History of Tuxedo.

2. What is Tuxedo ?

3. Componets of Tuxedo.

4. Core Services of Tuxedo .

5. ATMI Highlights.

6. Rich Messaging with Tuxedo.

7. ATMI and Tx Verbs.

8. Tuxedo Buffer Management.

9. Simpler Administration Advantages.

10. Configuration and Management.

11. Domain support

12. Heterogeneous DTP - Scenarios

13. Domain Architecture

14. Q Description and Q Components

15. Event Broker

16. Management Information Base (MIB).

17. Jolt and Jolt Componets.

18. WebLogic server and Tuxedo connector

2.Tuxedo Basics.

1. How to Build a simple Tuxedo Application.

2. Typed Buffer in Tuxedo and Basics ATMI for Buffer Allocation.

3. Basic ATMI Functions in Tuxedo.

a).Asynchronous Operations.

b).Unsolicited Message Handling.

c).VIEW/VIEW32 Buffers.

d).FML/FML32 Buffers.

e).Conversational Client Communication.

f).Publish/Subscribe(Event Broker).

g).Security.

h).Transaction Management.

i).Working with Queue.

j).Network and Work station Clients.

4. Inter domain Communications

5. Weblogic Tuxedo Connector

6. Jolt.