The BEA Domains 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 Connect family of products provides domain-compliant gateways that permit administration of the remote Transaction Processing (TP) system as a foreign domain. The BEA Connect SNA and BEA Connect 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 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 TUXEDO programming paradigms to request services offered in other BEA Domains exactly as if they were services offered within the local application.
The 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 List (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:
The BEA Connect SNA Domain, shown in Figure 2-1, is the gateway for communications using LU6.2 sessions and conversations to a CICS/ESA region. 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:
The BEA Connect SNA Domain
BEA Connect SNA allows 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 inter-operate. A set of SNA sessions of type LU6.2 over which the local and remote domains communicate are established. When two entities (in this case local and remote domains) communicate 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, non-conversational or conversational, parallel 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 Chapter 7, "Programming Considerations," for more details about application behavior.
The Connect 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 TUXEDO domain gateways; it uses the DMADM and GWADM servers for administration. With BEA Connect SNA, additional servers and processes support peer CICS/ESA connectivity and sync level 2. Figure 2-2 shows each component of the Connect SNA Product.
Connect SNA additionally 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" on page 4-3.
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 DMINIT and SNACRM Servers
Figure 2-2 BEA Connect SNA Domain Components
Other Gateway Servers
dmconfig file description found in Appendix A, "Reference Pages," located in the back of this guide.
