|
|
|
|
|
|
Understanding the BEA eLink Adapter for Mainframe Solution
In today's rapidly changing environment, businesses must continue to address changes in their business needs through adjustments in their corresponding computer infrastructure. Packaged applications successfully automate many internal operations such as financial, manufacturing, and human resources tasks. However, these applications' data formats and interface protocols may be proprietary and much of the applications' functionality may not be accessible from any exposed API. The consequence is isolation of these systems, loss of flexibility, and the inability to change at a later time.
When business systems need to share information and capabilities to operate efficiently or to expand to the web, integration problems surface. Businesses need a greater exchange of information with systems that communicate at both a database and a process level within the organization as well as with customers' and suppliers' systems. Businesses need to develop systems that are open, robust, and flexible to change while retaining the systems they have already purchased, developed, or inherited.
Enterprise Application Integration
Enterprise Application Integration (EAI) meets these business needs by providing a solution for integrating computer systems and applications. EAI requires that the applications exchange function and data messages seamlessly with minimal or no change to the applications themselves. Whether streamlining is accomplished through web-enablement, the consolidation of user interfaces, or the removal of redundant applications, the primary goal is always to simplify the system and reduce the effort required to maintain and operate it. An EAI system must:
BEA eLink Adapter for Mainframe Overview
BEA eLink Adapter for Mainframe (eAM) meets EAI requirements by allowing ATMI applications to communicate with the mainframe. 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 eAM domain architecture extends the scope of ATMI platforms 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 domain gateway architecture is designed for the ATMI 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 ATMI programming paradigms to request services offered in other domains as if they were services offered within the local application.
The ATMI 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.
The eAM gateway communicates between independent Logical Units (LUs) using LU6.2 sessions and conversations. It adds multi-domain connectivity, bidirectional request/response, and conversations between ATMI platforms and SNA-based applications. It provides access to APPC applications based on SNA as well as inter-system communication with CICS/ESA. When accessing CICS/ESA systems, the eAM acts as a CICS/ESA region, capable of supporting the following sync-level 2 functions:
BEA eLink Adapter for Mainframe (eAM) is composed of two major components that can be configured to provide SNA solutions, the eAM gateway and the Communications Resource Manager. These components provide a bidirectional link enabling ATMI platforms such as BEA Tuxedo, eLink Platform, or WebLogic Enterprise to interact with IBM mainframe applications as either a client or server, using a CICS/ESA and IMS implicit LU6.2, or any IBM-supported Application Program-to-Program Communication (APPC) or CICS/ESA interface. Figure 1-1 illustrates the eAM architecture.
The eAM gateway (GWSNAX) runs in an ATMI platform environment and the Communications Resource Manager (CRM) can run in the native UNIX/NT environment or be distributed to the mainframe as a VTAM application. The CRM may also be distributed to another UNIX/NT system, separate from the ATMI platform.
Generally, the eAM domain is like other ATMI domain gateways. It uses the DMADM and GWADM servers for administration Within the eAM system, additional servers and processes support peer CICS/ESA and IMS connectivity and sync level 2.
Note: An ATMI platform is required, and a third-party SNA stack is required if the CRM is not installed on a mainframe. These products are sold separately.
Figure 1-1 eAM Architecture
The eAM gateway (GWSNAX) is an ATMI domain gateway that communicates with the CRM. The eAM gateway processes ATMI-to-mainframe requests and responses in conjunction with the CRM. Requests coming from the mainframe are mapped to ATMI services while requests originating in ATMI are mapped to mainframe programs that can be executed using a CICS DPL or DPT application, or started from an IMS queue.
Communications Resource Manager
The CRM runs as a separate native process. It enables APPC conversations and DPL protocols to flow into and out of the ATMI environment. The CRM obtains its configuration from the gateway. If the gateway is running on a platform other than the one on which the CRM is running, the CRM should be started before the ATMI platform is started so it will be monitoring the address specified in the gateway configuration.
A properly configured SNA protocol stack is required for the CRM to communicate with a mainframe, unless the CRM is running independently of the ATMI environment (distributed mode).
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|