API Programming

e-docs > Tuxedo > Using the Tuxedo TOP END Domain Gateway with ATMI Applications > API Programming

Using the Tuxedo TOP END Domain Gateway with ATMI Applications

API Programming

This topic includes the following sections:

See Also

Characteristics of the APIs

Using the BEA Tuxedo ATMI (API) with the TEDG

The BEA Tuxedo application programming interface (API) that you use to communicate with BEA TOP END is called the Application-to-Transaction Monitor Interface, or ATMI. BEA Tuxedo client and server programs use ATMI functions to communicate with BEA TOP END client and server programs through the TOP END Domain Gateway (TEDG).

To a great extent, the way in which ATMI functions are used to communicate with BEA TOP END applications is identical to how ATMI functions are used to communicate with other BEA Tuxedo programs or applications through other domain gateways. The primary difference is that the TEDG does not support the same functions and features as other domain gateways. Because the TEDG connects two similar but not identical client/server environments, only features common to both environments can be supported when these environments are interoperating. This set of features common to both the BEA Tuxedo and BEA TOP END systems is provided by the TEDG through configuration, feature mapping, and exposing supported features at the ATMI programming interface in a way that closely matches the standard use of the ATMI.

As with other domain gateways, the TEDG is viewed by the BEA Tuxedo client as a BEA Tuxedo server; it maps requests from BEA Tuxedo client programs to BEA TOP END servers. When a BEA TOP END client makes a request, the TEDG maps the request and sends it to a BEA Tuxedo server. For this reason, the TEDG is viewed as a BEA Tuxedo client by the BEA Tuxedo server.

From a programming perspective, the TEDG is transparent to BEA Tuxedo ATMI applications; it looks like a BEA Tuxedo application and is accessed through the same ATMI functions used to access any BEA Tuxedo application. As with all applications that communicate, a BEA Tuxedo application and a BEA TOP END application must be designed to work together on requests, responses, and error handling. Because the TEDG configuration and mapping affect this interaction, the application designer must understand the TEDG configuration.

Characteristics of the BEA Tuxedo ATMI lists the supported and unsupported features of the BEA Tuxedo ATMI.

Limitations of Supported ATMI Features

Some of the supported ATMI features have limitations and special requirements when used for communication via the TOP END Domain Gateway. These limitations and requirements ensure that BEA Tuxedo and BEA TOP END applications have a common method of communicating. Some of the limitations are:

Conversational communication is limited to the following format:
- One process sends a single message and then releases control of the conversation.
- Another process responds with a single message and then releases control of the conversation.
Because the features provided by BEA TOP END RTQ and BEA Tuxedo queuing are not identical, several options in each API are unavailable.
The BEA Tuxedo system supports embedded FML32 buffers; the BEA TOP END system does not. These buffers are ignored by the TEDG and allowed to go through the gateway. If embedded FML32 buffers are used in a BEA Tuxedo application that is accessed by BEA TOP END clients, however, a failure may occur on the BEA TOP END node.
Public/private key encryption of application messages is supported between the BEA Tuxedo application and the TEDG but does not apply to messages between the TEDG and a BEA TOP END application. BEA Tuxedo configuration options that require the use of encryption are enforced. The ability to auto-encrypt messages from a BEA TOP END application is provided. Public/private key encryption for the TEDG is handled the same way that this type of encryption is handled for other non-TDomains BEA Tuxedo gateways.
Digital signatures are supported for application messages sent between the BEA Tuxedo application and the TEDG but are not supported for messages between the TEDG and a BEA TOP END application. BEA Tuxedo configuration options that require use of encryption are enforced. The ability to auto-sign messages from a BEA TOP END application is provided. Digital signatures for the TEDG are handled the same way that digital signatures are handled for other non-TDomains BEA Tuxedo gateways.

See Also

Characteristics of the APIs
"Introduction to the C Language Application-to-Transaction Monitor Interface" on page -7 in the BEA Tuxedo ATMI C Function Reference

Using the BEA TOP END CSI with the TEDG

The BEA TOP END application programming interface (API) is called the Client/Server Interaction facility, or CSI. BEA TOP END client and server programs use CSI routine calls to communicate with BEA Tuxedo client and server programs through the TOP END Domain Gateway (TEDG). To a great extent, the way in which CSI routine calls are used to communicate with BEA Tuxedo ATMI applications is identical to how CSI routines are used to communicate with other CSI applications. The primary difference is the features or options supported for each routine. The TEDG supports a set of features common to both the BEA Tuxedo and BEA TOP END systems through configuration, feature mapping, and exposing supported features at the CSI programming interface in a way that closely matches the standard use of the CSI.

The TEDG is viewed by the BEA TOP END client as a BEA TOP END server and maps requests from BEA TOP END client programs to a BEA Tuxedo server. When a BEA Tuxedo client makes a request, the TEDG maps the request and sends it to a BEA TOP END server. For this reason, the TEDG is viewed as a BEA TOP END client by a BEA TOP END server.

From a programming perspective, the TEDG is transparent to BEA TOP END applications: it functions like a BEA TOP END application and is accessed using the same CSI calls used to access a BEA TOP END application. As with all applications that communicate, both the BEA TOP END application and the BEA Tuxedo application must be designed to work together on requests, responses, and error handling. Because the TEDG configuration and mapping affect this interaction, the application designer must understand the TEDG configuration.

For lists of supported and unsupported features of the BEA TOP END CSI, see Characteristics of the BEA TOP END CSI.

Limitations of Supported CSI Facilities

Some of the supported CSI features and interfaces have limitations and special requirements when used for communicating via the TOP END Domain Gateway. These limitations and requirements ensure that BEA Tuxedo and BEA TOP END applications have a common method of communicating. Some of the limitations are:

Conversational communication with an application context is accomplished by mapping to the BEA Tuxedo conversational paradigm. There are limitations to the use of function qualifiers with the TEDG. A traditional BEA TOP END application may use function qualifiers to indicate the step of the conversational interaction; this is not possible with the TEDG. Successful communication in a conversational manner requires adapting one or both of the applications to the features available through the TEDG mapping of context to conversations.
Because the features provided by BEA TOP END RTQ and BEA Tuxedo queuing are not identical, a number of options in each API are unavailable.