BEA Home | Events | Solutions | Partners | Products | Services | Download | Developer Center | WebSUPPORT
eLink OSI TP Doc Home | User Guide | Previous Topic | Next Topic | Contents | Index | View as PDF

Introducing BEA eLink OSI TP

This section covers the following topics:

- BEA eLink OSI TP Overview

- BEA eLink OSI TP Features

- BEA Tuxedo and eLink OSI TP Architecture

- OSI TP Software Overview

- OSI TP Domains Components

BEA eLink OSI TP Overview

BEA eLink OSI TP is a gateway connectivity product that makes it possible for OLTP application programs on BEA Tuxedo systems to perform global transactions and various non-transactional tasks with application programs in the following environments:

- Other BEA Tuxedo applications. An application (or administrative domain) is a single computer or network of computers that share a single BEA Tuxedo configuration.

- Other systems that implement the Open Group XATMI standard interface and OSI-TP standard protocols. These include Unisys A Series enterprise servers or Unisys OS 2200 enterprise servers that support Open/OLTP software and OSI-TP, Microsoft MTS through Unisys OpenTI, and ICL Open VME.

Figure 1-1 BEA eLink OSI TP Communicating with an OSI TP Partner

BEA eLink OSI TP implements the OSI-TP standard, a set of protocols that is used to:

- Establish and support dialogs between application programs on different computers.

- Facilitate commitment and rollback of global transactions that span multiple computers.

The Open Group XATMI standard is an interface that application programs use to communicate with other application programs both inside and outside of global transactions. It supports conversational and request/reply communication styles and is fully implemented by eLink OSI TP.

Data mapping and transformation between the BEA Tuxedo and mainframe environments is easily automated in BEA Tuxedo-based applications with the BEA Tuxedo typed buffer mechanism. This mechanism allows system administrators to predefine how data should be conveyed to the remote application. Application programmers do not need to be aware of this translation; they can simply continue using the buffer types defined for the local application. The eLink OSI TP software is designed to provide transparent access to remote services that reside outside a BEA Tuxedo application. In addition, eLink OSI TP provides remote application programs with access to local services.

Figure 1-2 BEA eLink OSI TP Sample Environment

BEA eLink OSI TP Features

The eLink OSI TP product supports the following features:

- Tightly-coupled and loosely-coupled transaction processing

- Full array of buffer translation options

- Optional AUTOPREPARE feature that allows requests to remote services to be automatically prepared

- Synchronous and asynchronous service requests and replies initiated from either the BEA Tuxedo or mainframe environments

- Conversational service requests and replies initiated from either the BEA Tuxedo or the mainframe environments

- Global Transactions with OSI TP partners

- Event monitoring and reporting

- Dynamic configuration support

- ASN.1 based data conversion

- Link-layer security and global user authentication to participating remote domains

- Multiplexed OSI TP connections with built-in keep alive functionality and enhanced flow control mechanism

- Multiple simultaneous request/response sessions and conversations

- Connections to remote domains

- Transaction recovery for failures occurring during the second phase of commitment

- Automatic suspension of remote services that have failed (through Tuxedo)

- NATIVE A Series COBOL Copybook Data Conversion

- XML Buffer Support

BEA Tuxedo and eLink OSI TP Architecture

A BEA Tuxedo application consists of client and server programs that operate across a network of BEA Tuxedo systems. Any client program can request services that are offered by any server program running on any computer in the application. The location of server programs is kept transparent because remote services are mapped to servers in a section of the configuration file. The eLink OSI TP architecture comprises two distinct internal components, nw-bea and nw-unisys. These two internal components extend the transparent access of the BEA Tuxedo system by sending requests to and receiving requests from remote systems through OSI TP and supporting network software. Figure 1-3 shows how this transparent access works.

Figure 1-3 Routing Service Calls through BEA eLink OSI TP

- When local BEA Tuxedo client programs send requests to remote systems, eLink OSI TP transforms those requests into OSI TP messages. When remote systems respond, eLink OSI TP transforms associated OSI TP messages into replies that local client programs can process.

- When remote client programs send OSI TP messages to local applications, eLink OSI TP transforms those messages into requests that local BEA Tuxedo service routines can process. When local service routines send replies, eLink OSI TP transforms those replies into OSI TP messages.

- When commitment protocol is sent for global transactions, eLink OSI TP transforms the protocol and manages the transaction commitment.

The eLink OSI TP software is implemented as an ordinary BEA Tuxedo server group that accepts standard BEA Tuxedo service requests and returns standard replies. The eLink OSI TP server group consists of the following components:

- A server program that includes the TMS service

- An administrative server

One eLink OSI TP server group acts as a gateway to multiple remote systems. The eLink connection manager can either:

- Use multiple communications targets

If you use multiple communication targets, you have a unique OSI TP endpoint called an association. When using unique communications targets, there is one association or connection to the remote system for each call to the remote system. After the call is complete, that association is reused by subsequent calls. There is a connection to the remote system for each simultaneous call made to the remote system. The association is released after a pre-set timer expires, turning unused resources back to the system. This pre-set timer is controlled by parameters specified in the OSI TP tailor file. Refer to Tuning OSI TP-Specific Tables with the TAILOR File for more information.

- Configure eLink OSI TP to multiplex all communications per remote system

To multiplex all communications per remote system, you must have the version of eLink OSI TP that has this feature and your remote system must support OSI TP multiplexing. When using multiplexing, all data is streamed or collected and sent to the remote system. Data messages are sent and received in an efficient manner increasing scalability and performance. The XATMI data representation is still used, but the representation of internal OSI TP data exchanges is optimized.

Some remote targets, such as remote BEA Tuxedo applications, also support BEA eLink OSI TP. In this situation, eLink OSI TP servers associated with the local gateway communicate with eLink OSI TP servers associated with remote gateways through OSI TP.

Other products such as remote Unisys A Series Open/OLTP systems, Unisys OS2200 systems, Unisys OpenTI for MTS interoperability, and ICL TPMS for Open VME provide analogous functionality with which local eLink OSI TP servers can interact.

The eLink OSI TP software maintains its own control information in shared memory, in much the same way that BEA Tuxedo software itself maintains the Bulletin Board. Although eLink OSI TP accesses the BEA Tuxedo Bulletin Board, BEA Tuxedo does not access eLink OSI TP control information.

To a remote system that supports the Open Group XATMI standard (more specifically, an XATMI application service element), the eLink OSI TP server group appears as a communications resource manager (CRM).

Multiplexed Flow Control

When the multiplexed protocol is used, flow control is implemented in the following manner. When the amount of data buffered to a particular RDOM exceeds the threshold defined by StartFlowControlThreshold, GWOSITP sends a request to Tuxedo to unadvertised all services associated with the particular LDOM and RDOM involved. This allows all call and connect requests already accepted by GWOSITP to complete normally without being aborted. If one or more redundant RDOMs are configured with the same services advertised, then Tuxedo will automatically route new requests to these other RDOMs. If no other RDOM advertises the services, new tpcall or tpconnect requests will get a TPENOENT error.

When the amount of data buffered to a particular RDOM falls below the threshold defined by StopFlowControlThreshold, GWOSITP sends a request to Tuxedo to advertise all services associated with the LDOM and RDOM involved.

Because of the lag time between detecting flow control and unadvertising the services, it is possible for the amount of buffered data to exceed the value of StartFlowControlThreshold by a significant margin. Therefore, care should be taken when configuring StartFlowControlThreshold with a large value.

Note: For more information about the StartFlowControlThreshold and StopFlowControlThreshold parameters in the TAILOR file, refer to Tuning OSI TP-Specific Tables with the TAILOR File.

OSI TP Software Overview

Open Systems Interconnection (OSI) is a computer network architecture developed by the International Organization for Standardization (ISO) in cooperation with other standards Organizations. OSI standards define protocols for communication between diverse computer systems in a network.

Benefits of OSI

By conforming to OSI standards, computer hardware and software vendors can enable applications on a local computer system to communicate with applications on remote computer systems that are manufactured by another vendor or have a different architecture from the local system.

OSI Reference Model

The OSI architecture is based upon a framework that divides the networking tasks and requirements into seven layers. The layers are groups of related functions or tasks, intended to make their interfaces and functions easier to understand.

Each layer contains entities that perform specific functions in the communication process. Entities throughout the network that are in the same layer and perform the same functions on different systems are called peer entities. They communicate with each other in a standard way. This is called protocol.

In the OSI Reference Model, peer entities cannot communicate directly. On the sending system, a layer entity uses peer protocols to attach a header containing routing and control information to the message being sent. It then passes this information down to the next layer. That layer adds its own header information and passes it to the next lower layer.

When the message reaches the receiving system, entities in each layer:

- Read and remove the information in the headers added by their peers on the sending system.

- Pass the remaining message up to the next layer.

The following figure illustrates the seven common protocol layers of the OSI Reference Model.

Figure 1-4 OSI Reference Model

Transaction Processing Services

OSI TP works with Tuxedo to provide the following services:

- Marks the beginning of a distributed transaction.

- Coordinates the commitment and rollback of a distributed transaction.

- Performs automatic recovery of all communications paths in the event of a failure.

OSI TP Domains Components

The eLink OSI TP software and other eLink products act as gateways between BEA Tuxedo systems and other online transaction processing environments. Connections with remote systems are established by configuring eLink OSI TP as an ordinary BEA Tuxedo server group that identifies remote systems and available services.

The eLink OSI TP gateway is composed of several elements that can be configured to provide OSI TP solutions. For the most part, the OSI TP domain is much like the other domain gateways. It uses the DMADM and GWADM servers provided with BEA Tuxedo for administration.

The following diagram describes each component of the eLink OSI TP product.

Figure 1-5 Domain Components

BEA eLink OSI TP uses the following administrative servers for domain and gateway configuration and administration:

- DMADM - Domain administration server

- GWADM - Gateway administration server

- GWOSITP - OSI TP Domain Gateway

Note: The gateway, GWOSITP, must be started AFTER the other servers.

Specific information on configuring the various sections of a domain are covered in the BEA Tuxedo document, BEA Tuxedo /Domain Guide.

Copyright © 2002 BEA Systems, Inc. All rights reserved. Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.