|  | BEA eLink for Mainframe SNA 3.2 Information Center
HOME | SEARCH | CONTACT | PDF FILES | WHAT'S NEW
| TABLE OF CONTENTS | PREVIOUS TOPIC | NEXT TOPIC

# 2. Understanding How the Software Works

## Overview of Domain Gateways

The BEA Domain gateway architecture grew out of a need for organizations to share services and data among computer applications while enabling application and administrative autonomy within single segments of the business. For example, a bank could have a number of separate applications, such as a loan application, a retail application, and so forth. Each application could span one or more computer nodes and could be administered independently from other applications.

The Domain, a separately administered application environment that is interconnected with other domains by gateways, was developed to address this need. To provide a common functional framework for gateways interconnecting individual domains, BEA developed the Domain Gateway architecture. This architecture specifies the common functionality and administrative interfaces needed for gateways to perform inter-domain communications. You can find a more detailed discussion of the BEA Domains gateway architecture in BEA TUXEDO Domain User Guide.

The BEA eLink family of products provides domain-compliant gateways that permit administration of the remote Transaction Processing (TP) system as a foreign domain. The BEA eLink for Mainframe SNA and BEA eLink for Mainframe OSI TP gateways are operating examples.

The Domains Gateway architecture extends the scope of BEA TUXEDO to provide coordinated transaction processing across an enterprise's geographic or organizational boundaries. Within each domain, the administrator determines which local services are available to other specific domains, thus enabling client applications to request those services.

The Domains Gateway architecture is aimed at the BEA TUXEDO application administrator, who makes services in other domains available to application programmers. The existence of applications within distinct domains is, however, totally transparent to the application programmers. They can use BEA TUXEDO programming paradigms to request services offered in other BEA Domains exactly as if they were services offered within the local application.

The BEA TUXEDO application administrator enables remote domains to access a subset of Local Services. This subset is called a Local Domain. The local domain helps the administrator provide secure "views" of the application.

Furthermore, the administrator can restrict access to local services through an Access Control Lists (ACL). The list designates which remote domains are allowed to issue requests to a particular local service.

Here are common features shared by all BEA Domains-compliant gateways:

- X/Open XATMI. Application programs using BEA TUXEDO can request services from applications running in another domain. Also, remote applications can request services from local servers.

- Administration. BEA Domains-compliant gateways can be booted or shutdown exactly like any other BEA TUXEDO server. Run-time administration is provided, and administrators can dynamically change the configuration to tune the performance of a gateway. Each compliant gateway supports a common set of administrative Application Programming Interface (API), tools, and configuration files.

- Multi-domain interaction. BEA Domains-compliant gateways can inter-operate with multiple domains at the same time.

- Transparent multi-network support. BEA Domains-compliant gateways can communicate with remote domains using different types of networks transparent to the application.

- Service names aliases. This permits the administrators to map service names used by the remote application to service names used by the local application. By using this feature, administrators can easily integrate applications that use different naming schemes.

- Data dependent routing. Administrators can use the configuration capability to define data dependent routing criteria for remote domains. This feature allows the gateway to select a remote domain according to a field value defined in the request (for example, an account number).

  ## The eLink SNA Domain

  The eLink SNA domain, shown in Figure 2-1, is the gateway for communications between independent Logical Units (LUs) using LU6.2 sessions and conversations. It adds multi-domain connectivity, bidirectional request/response, and conversations between TUXEDO and SNA-based applications. It provides access to SNA based APPC applications as well as inter-system communication with CICS/ESA. When accessing CICS/ESA systems, the SNA domain acts as a CICS/ESA region, capable of supporting the following sync-level 2 functions:

  - Bidirectional synchronous, asynchronous, and conversational service requests

  - Peer support for CICS/ESA and support for multiple remote MVS regions

  - Event monitoring and reporting

  - Both static and dynamic configuration support where allowed by SNA

  - Automatic Data conversion between Unix and Host formats

  - Security through Access Control Lists on the local domain

  - User and password security for CICS/ESA communications

    > Figure 2-1 BEA TUXEDO System /Domain Architecture

  The eLink SNA software enables the TUXEDO System clients and servers to interact with clients and servers in a non-TUXEDO, remote SNA domain. The remote and local domains must support SNA LU6.2 protocols in order to interact. A set of SNA sessions of type LU6.2 over which the local and remote domains communicate are established. Only independent LUs are supported.

  When two entities, in this case local and remote domains, interact via an LU6.2 session, a conversation is allocated to the session. The gateway and CICS program have exclusive use of the session during the conversation. When the conversation is de-allocated, the session becomes available for use by another client/server pair.

  For each client/server communication model, sessions are allocated for the LU6.2 conversation between the local and remote domains. The behavior of the applications at either end of a conversation depends on the type of client/server communication model in effect for the duration of the LU6.2 conversation.

  Refer to "Application to Application Programming Considerations" for more details about application behavior.

  ## The eLink SNA Domain Components

  The eLink SNA domain is composed of several elements that can be configured to provide SNA solutions. For the most part, the SNA domain is much like other BEA TUXEDO domain gateways; it uses the DMADM and GWADM servers for administration. With the eLink SNA system, additional servers and processes support peer CICS/ESA connectivity and sync level 2. Figure 2-2 shows each component of the eLink SNA product.

  > Figure 2-2 BEA eLink for Mainframe SNA Domain Components

  ### The DMINIT and SNACRM Servers

  Additionally, the eLink SNA software provides the DMINIT server, which can be used to start non-BEA TUXEDO servers at gateway group boot time. One such server is the SNA Communication Resource Manager (SNACRM). Both the SNACRM and the SNA PU 2.1 servers must be running before any other servers are booted. Configuring the SNACRM server is explained in the DM_SNACRM Section.

  ### Other Gateway Servers

  The SNA Domain Gateway (GWSNAX) uses the administrative servers provided with BEA TUXEDO software for domain and gateway configuration and administration. These are the Domain Administration Server (DMADM) and Gateway Administration Server (GWADM). Specific information about configuring the various sections of the SNA Domain Gateway can be found in the following:

  - The section "Configuring the System"

  - The `dmconfig` file description found in Appendix A, "Reference Pages," located in the back of this guide.

  - BEA TUXEDO/Domain Guide

  Copyright © 1999 BEA Systems, Inc. All Rights Reserved.
  Required browser version: Netscape Communicator version 4.0 or higher, or Microsoft Internet Explorer version 4.0 or higher.
  Last update: October 1, 1999.