Basic Architecture of the BEA Tuxedo ATMI Environment

The following figure illustrates the basic architectural elements of a BEA Tuxedo ATMI environment: external interfaces to the environment, the ATMI layer, the MIB, BEA Tuxedo system services, and the environment's interface with standards-compliant resource managers.

 
 

External interface layer

This layer consists of interfaces between the user and the environment. It includes both tools for application development and administration, such as the BEA Administration Console. The BEA Administration Console can interact with standard management consoles. Thus a user can manage a BEA Tuxedo ATMI environment and a network configuration from one console. In addition, application architects and developers can build their own administrative tools or application- or market-specific tools on top of the MIB.

ATMI (Application-to-Transaction Monitor Interface)

The interface between an application and the BEA Tuxedo ATMI environment. ATMI provides an interface for communications, transactions, and management data buffers that works in all environments supported by the BEA Tuxedo ATMI interface. ATMI defines the interface between application programs and the BEA Tuxedo system. It offers a simple interface for a comprehensive set of capabilities. It implements the X/Open distributed transaction processing (DTP) model for transaction processing. An abstract environment, the ATMI supports location transparency and hides implementation details. As a result, programmers are free to configure and deploy BEA Tuxedo applications to multiple platforms without modifying the application code.

Messaging paradigms

Different models of transferring messages between a client and a server. Examples include request/response mode, conversational mode, events and unsolicited notification.

Management Information Base (MIB)

The MIB is an interface that enables users to program and administer a BEA Tuxedo ATMI environment easily. MIB operations enable you to perform all management tasks (monitoring, configuring, tuning, and so on). The MIB allows you to perform one task to one object at a time or to build toolkits with which you can batch tasks and/or objects. 

BEA Tuxedo Services (Administrative Services and Application Processing Services)

 Services and/or capabilities provided by the BEA Tuxedo ATMI environment infrastructure for developing and administering applications. The application processing services available to developers include: data compression, data-dependent routing, data encoding, load balancing, and transaction management. The administrative services include: centralized application configuration, distributed application management, domains partitioning, dynamic reconfiguration, event and fault management, IPC message queues, and workstation management. 

Resource Manager

A software product in which data is stored and available for retrieval through application-based queries. The resource manager (RM) interacts with the BEA Tuxedo ATMI environment and implements the XA standard interfaces. The most common example of a resource manager is a database. Resource managers provide transaction capabilities and permanence of actions; they are the entities accessed and controlled within a global transaction.

How to Setup Environment Viarable In the Tuxedo Client Application?

As we know, to let Tuxedo client application connect to Tuxedo server application correctly, the traditional way is to create a configuration file in the Tuxedo installation directory and add an environment viarable pointing to this file.

In some casees, you maybe want to setup the these environment virables in your program, the following steps domostrate how to do this.

1. Create a configuration file, for example, and name it tuxenv.ini using any text editor.

2. Copy and paste the following settings to the above file:

[TUXCOMM]

TUXDIR=<Directory where Tuxedo installed>

WSNADDR=//<HostName>:<Port No>

You can find the host machine name by using:

• hostname in Windows platform
• uname in Unix

3. Save this file to the same folder where the client application is.

4.  In the program, add the following statement before you call tpinit:

rtn = tuxreadenv("tuxenv.ini","TUXCOMM");

if (rtn < 0)

{

   fprintf(“error on tuxreadenv“);

   ...  

}

if (tpinit((TPINIT *) NULL) == -1)

{

   fprintf(stderr, "tpinit failed with error %s ", tpstrerror(tperrno));

   exit(1);
}

The ATMI imposes no limit on the size of messages sent to and from Tuxedo application services. However, the ATMI automatically compresses messages, or transfers them by using temporary disk files, if the messages exceed an internal size threshold (by default, 32,000 bytes of application message data). As a consequence, request messages and reply messages larger than this threshold might incur additional processing overhead and might not provide as high a level of performance as smaller messages. You can change the default compression threshold by changing the value of the CMPLIMIT parameter in the MACHINES section of the ubbconfig file.

Cofiguring WSL in the UBBCONFIG file

By default, each Workstation Handler may handle up to 10 workstation clients. For performance, you may want to reduce this multiplexing value (-x option) on the command line of the Work Station Listener.

Now you will have to add a server in the SERVERS section called WSL. TUXEDO already knows about this server so you don't have to build it, just configure it and supply the correct command line options. The entry in the server section should look like:

WSL SVRGRP=BANKB1

SVRID=200

CLOPT="-A -- -n //abc:2600 -d/dev/tcp -x2 -m1 -M2";

For all TUXEDO servers, the command line options to the left of the double dash are options the TUXEDO uses. In this case, the A tells TUXEDO to advertise this service. The options to the right of the double dash are Server Specific command line options. The -n is the network address. This is the port and IP address that the listener will listen on.

The -d is the transport device. On most systems, this is /dev/tcp. The installation handbook gives some details of what the network transport device (also called the BRIDGE device) should be set at. One important thing to note is that once you have figured out what to set it at, it should be set that way here on the WSL command line options, in the BRIDGE section of the NETWORK section of a multiple machine configuration, and also at the workstation in the environment variable WSDEVICE.

The -x2 option indicates that each Workstation Handler should handle two workstations, and the -m and -M options are the minimum and maximum number of servers. One thing that often confuses people about server minimums and maximums is that the -m option is the number of servers that TUXEDO will start at boot up. The -M maximum option is the maximum number of instances of that server which an administrator can bring up. TUXEDO will not automatically bring additional instances up; this is simply a "high-water" mark of how many instances of this server and administrator will allow to be brought up.

If your entry were the one above, you could change it to look like this:

CLOPT="-A -- -n //myserver:6001 -m 2 -M 10 -x 50 -p 6002 -P 6011"

where:

• -p argument specifies the lowest port number that a WSH process will try to listen on.
• -P argument specifies the highest port number that a WSH process will try to listen on.

If your firewall does NAT-ing of IP address, you must use -H option in CLOPT too. If you need data encryption, you have to install Tuxedo security module and use -z and -Z option for encryption levels.