5.4 Integration Points
5.4.1 Architecture PerspectivesDifferent mainframe integration designs have different integration points, which may span multiple tiers and layers . This allows flexibility and options in choosing the integration point that can accommodate local technical requirements and constraints. Table 5-1 recapitulates a list of technology approaches used to wrap back-end mainframe applications as Web Services. It also identifies what architecture components need to be installed in the Business Tier (on top of the application server), Integration Tier (middleware), and Resource Tier (in the back-end legacy system). These architecture components can act as an integration point where Java servlets or EJBs can be a "delegate" or a broker (refer to section 6.7.6) that initiates a SOAP service request for the back-end business services running on the mainframe platform. CICS Transaction Gateway provides a middleware solution in the Integration Tier, where the server-side SOAP component can invoke a remote Web Service via ECI, EPI, or ESI calls to the back-end CICS applications. There is no additional component to be added to the application server (Business Tier), or the back-end legacy system (Resource Tier). The integration point with the mainframe is via the Integration Tier. CICS Web Support is a technology solution residing in the back-end CICS region to Web-enable 3270-based CICS applications. A server-side SOAP component can invoke a remote Web Service that accesses 3270-based CICS screens. There is no additional component needed in the Business Tier or the Integration Tier. The integration point is via the Resource Tier. Table 5-1. Integration Points for Mainframe Interoperability
Java technology is a multi-tier architecture approach to integrate with the back-end legacy system. A server-side SOAP component (such as EJB Web Service) can be created to integrate with the back-end via the Business Tier, the Integration Tier (using Java Connector), or the Resource Tier (using RMI/IIOP to invoke another EJB). The SOAP proxy on mainframe approach uses an application proxy with a transaction adapter to enable SOAP messaging. Forte Transaction Adapter needs to be installed and configured in the Integration Tier and the Resource Tier. The integration point is with the Forte Transaction Adapter. Figure 5-18 shows the same list of integration points under different tiers. CICS Transaction Gateway resides in both the Business Tier and the Integration Tier. CICS Web Support resides in the Resource Tier. Java technology supports multi-tier architecture design, and thus Java components span different tiers. Figure 5-18. Integration Points by Tiers A conscious design decision to pick an appropriate integration point should include consideration for future extension and scalability. Some integration points can be difficult to scale up or may incur higher integration costs. 5.4.2 Functional PerspectivesWeb Services integration can be initiated from a business function. In other words, a Web Service call may embed multiple function calls that come from different sources. These function calls may be EJBs or CICS transaction ids. In Figure 5-19, we show an example of how to open a private banking account. We need to create a Web Service call (Account Opening Web Service under the Business Tier) that consists of three Web Services calls, including credit checking, account opening in the Customer Master, and linking to existing bank products if available. In some instances, these Web Services calls may span different tiers and may require more than one integration technology. One Web Services call (such as credit checking) may be using a SOAP proxy in the Integration Tier, which will invoke a CICS transaction using CTG. Another Web Services call (such as account opening in the Customer Master) may be using a SOAP proxy to invoke a CICS transaction via CICS Web Support. The last Web Services call may be using an EJB Web Service that invokes the back-end CICS transaction wrapped as an EJB in the Resource Tier. These examples show that there are multiple integration points where developers can create Web Services to integrate with the back-end mainframe system. The design consideration may be based on the specific business functionality, which may reside in a specific tier (such as in the Business Tier or the Integration Tier). Figure 5-19. Integration Points by Functions 5.4.3 Mainframe Integration and Interoperability PatternsThere are two major mainframe integration and interoperability patterns discussed in this chapter. Synchronous or RPC-based Web Services can be designed by creating a server-side component that invokes CICS transactions via any of the integration components discussed earlier (such as CICS Transaction Gateway and CICS Web Support). Asynchronous or document-based Web Services can be designed by encapsulating existing WebSphere MQ (or JMS) messages in a SOAP envelope. The data content will then be sent using SOAP messaging over WebSphere MQ or JMS. The following section introduces these two patterns based on the mainframe technology options discussed earlier. Chapter 3, Web Services Technology Overview, discusses synchronous (or RPC-based) and asynchronous (or document-based) Web Services technology. A discussion of integration patterns is also provided in Chapter 6, Cross-Enterprise Integration. Synchronous Mainframe Web Services PatternContextMany mainframe applications are developed in COBOL running under CICS. As these applications are running in a proprietary operating environment, it is rather difficult for developers to reuse them or to interoperate with them from other front-ends or systems. Currently, the COBOL programs, after compilation, can be accessed via CICS ECI, EPI, or ESI calls. There are also some Web-enabling tools, such as CICS Web Support, that allow these CICS transactions and resources to be accessible from a browser. If combined with SOAP messaging, these tools can help create reusable Web Services that can invoke remote CICS transactions. For many financial institutions and service providers, legacy mainframe systems have been processing business transactions for many years , and there are very few system changes. However, the business functionality is not easily accessible from, or integratable with, the Java platform. Synchronous mainframe Web Services can be created to expose these business functionalities as a remote procedural call, and this does not require any application rewrite. In such a way, business functionality can be reused, and made available to different client devices (such as a mobile phone) and platforms (such as the Unix platform). ProblemOnline transactions developed in COBOL running in CICS are proprietary and cannot be easily integrated and interoperated with other platforms. To provide the same functionality on open systems to ease integration and interoperability with other systems, developers need to migrate to other platforms or perhaps rewrite the applications in other programming languages. This may have a long lead time in order to rebuild the same functionality. It would also be risky to the implementation, because many legacy applications do not have any technical documentation for the rewrite design. ForceThe technical considerations that affect the use of synchronous mainframe Web Services is the existing mainframe configuration and legacy system infrastructure. If the current operating environment does not support the use of any mainframe integration component such as CICS Transaction Gateway and CICS Web Support, it would not be viable to implement synchronous mainframe Web Services. For instance, older versions of the IBM mainframe (such as VSE) do not support CICS Transaction Gateway. If developers want to expose CICS transactions as Web Services, they need to upgrade their mainframe to z/OS from older operating systems. SolutionThere are a few mainframe integration products available from IBM and other mainframe vendors such as Jacada ( http://www.jacada.com ). These products help to build synchronous mainframe Web Services without rewriting the back-end CICS applications. They are like middleware that can expose CICS transactions via ECI, EPI, or ESI calls, which can then be wrapped as Web Services calls. It addresses the concern of long lead time in migrating the legacy applications to open systems or rewriting the applications on open systems. Figure 5-20 summarizes the different mainframe integration and interoperability options. A SOAP client invokes the remote business service by binding to a service end-point URL (via XML-RPC). The service end-point will be processed by the SOAP server-side component (SOAP tier or skeleton), which will initiate an ECI/EPI/ESI call. If an EJB component is used, the CICS EJB server will initiate an RMI/IIOP to invoke another EJB residing in the target CICS region. If a SOAP proxy is used, the application proxy will initiate an APPC program call to the remote CICS resources. The previous sections discussed the architecture and the technical processes for each technology option. Figure 5-20. Synchronous Messaging for Mainframe Interoperability This pattern is useful when there is a business requirement to access and process online CICS transactions by wrapping them as Web Services. Besides, it is appropriate when the current IT operating environment does not allow building a messaging or middleware infrastructure (such as JMS-compliant middleware) due to time and cost constraints. RiskConfiguring the mainframe integration components and exposing legacy applications as Web Services require some knowledge and experience of the IBM mainframe platform. The technologies behind these components are often proprietary in nature, and there are not very many experienced architects in the market. This is a risk to the implementation, because the implementation requires a high level of technical skills and support experience in mainframe integration and Web Services technology. ExampleHewitt Associates uses CICS Transaction Gateway to wrap back-end mainframe systems as Web Services (also refer to Chapter 2, The Web Services Phenomenon and Emerging Trends). This enables employee benefits system functionality to be available and reusable to a large number of business partners . The development took three to four months to complete, and there was no need to modify the back-end CICS programs. Asynchronous Mainframe Web Services PatternContextSome customers who operate many business applications on legacy mainframe systems may also have a message-oriented middleware infrastructure (such as WebSphere MQ). Such messaging infrastructure enables business information to be encapsulated in a business document and routed to different applications for sharing and for further data processing. However, to be able to make use of common business information, developers need to build a custom adapter for each front-end or application system, because each may support its own data format only. Thus, the custom adapter needs to translate the data content into a format that can be understandable by the front-end or application system. Another issue is that if the common business information needs to be exchanged with external trading partners (that is, Business-to-Business integration), there is no common middleware or messaging mechanism that can be easily agreed upon between two trading partners. A similar business scenario occurs when exchanging business data between two internal systems within an enterprise, where each system runs on different application platforms and the systems do not share a common middleware infrastructure. Asynchronous mainframe Web Services would be a good solution here, because it can wrap an existing business message in a SOAP envelope and exchange with multiple trading partners over different data transport or middleware (such as SOAP over MQ, and SOAP over JMS). SOAP messaging accommodates the issue of different connectivity requirements (using SOAP over different data transports) and different data format requirements (using XML parsers for easier data transformation). This becomes a time-to-market solution to expose business data messages as reusable Web Services that are encapsulated in proprietary mainframe systems and middleware infrastructures . ProblemCommon business data from the back-end mainframe systems that are encapsulated in existing message-oriented middleware are usually shared between multiple application systems in the mainframe. How can architects and developers expose the business data in a Web Service that can be accessible to other systems or external trading partners? ForceThere are two dependencies to support asynchronous mainframe Web Services: the availability of a common business data message used by the back-end mainframe systems and the availability of a message-oriented middleware infrastructure that connects to the back-end mainframe systems. The common data message is usually shared by multiple back-end mainframe applications or different software versions of the same business functionality. It can be used as an input service request or output business transaction data. For instance, an account balance inquiry data message is shared by multiple versions of retail banking systems. The availability of an existing message-oriented middleware infrastructure is important because Web Services technology can leverage on the current infrastructure to integrate and interoperate with the back-end mainframe systems. Building a huge middleware infrastructure that can connect to the back-end mainframe systems from scratch is very expensive and time consuming. SolutionMajor message-oriented middleware vendors support SOAP messaging today, with additional provider classes that enable SOAP messaging over different data transports including WebSphere MQ and JMS. This does not require building customized adapters or programs in the legacy mainframe systems to wrap the business data in a SOAP envelope. By enabling the WebSphere MQ or JMS queue manager to support SOAP messaging, business data encapsulated in the back-end mainframe systems and in the message-oriented middleware can be reused for data interchange between trading partners and systems. It is a cost-effective solution approach to Business-to-Business integration and internal system integration. Figure 5-21 depicts a scenario where service requests can be encapsulated in a WebSphere MQ format, wrapped in a SOAP envelope, and written to a MQ queue or JMS queue that can be processed by the back-end mainframe systems. A SOAP client sends a service request in a SOAP message to the SOAP server-side component. The SOAP server-side component (SOAP tier or skeleton) will then bind the messaging to the underlying data transport layer using WebSphere MQ or JMS. The WebSphere MQ or JMS queue manager needs to support SOAP messaging. Currently, WebSphere MQ version 5.0 or higher supports SOAP messaging over WebSphere MQ. There are also some JMS vendor products (such as Progress SonicXQ) that support SOAP messaging over JMS. Upon receiving the SOAP message, the queue manager will then unmarshal the SOAP envelope and retrieve the message payload in native MQ or JMS format. It can then route the message to the target queue residing in the mainframe CICS region. The same process applies to both WebSphere MQ and JMS technologies. Figure 5-21. Asynchronous Messaging for Mainframe Interoperability This pattern is a simple solution to Web Services enable an existing messaging infrastructure using WebSphere MQ or JMS. It is useful when there are different CICS transactions that need to be accessed and there is no standard way to invoke them (for instance, one CICS transaction may require an ECI call and another an EPI call). By consolidating these heterogeneous CICS transactions and online interfaces into a single message, developers do not need to build different program invocation or data access methods for each CICS transaction. Future enhancement to the application functionality will be more flexible and dynamic (for instance, it will be easier to add or aggregate new information elements to the remote CICS transactions without changing the back-end applications.) In addition, it does not require installing additional components to support asynchronous or document-based Web Services. RiskThere is a high design complexity in normalizing a common data message for multiple back-end mainframe applications. There may be a temptation for architects to simply use all existing data interfaces as the SOAP message payload. The risk is that irrelevant data in the SOAP message payload will increase data processing and XML data parsing time, which impacts the performance. ExampleProgress SonicXQ is an example of SOAP messaging over WebSphere and JMS and can be used to implement this pattern. 5.4.4 Design ConsiderationsSecurityUsually, either user id/password or SSL is used for authentication. Nevertheless, form-based or HTTP-based authentication may not be sufficient for today's Web security. Architects and developers need to understand that security should not be viewed as user id authentication only. Chapter 7, Web Services Security, has more discussion on this topic. Authentication DesignRACF is the legacy mainframe security infrastructure for authentication of user identity and credentials for mainframe resources. It is now enhanced to register SSL certificates (which requires some specific APARs or service packs ) and can integrate with LDAP/390. To use SSL certificates, architects need to configure the AUTHENTICATE parameter in the TCPIPSERVICE resource definition of the CICS. This is a feature in CWS called CWS Certificate Auto-registration. Upon successful registration of SSL certificates in RACF, CICS can retrieve the user id from the EXEC CICS EXTRACT CERTIFICATE USERID command. This design approach can leverage on and integrate with the existing security infrastructure of the legacy mainframe environment. The design dilemma is whether architects should use a Directory Server on Open Platform (Unix) rather than a legacy mainframe platform. One argument is that architects can scale up multiple Directory Servers on the Unix platform for better scalability. This can support federated Directory Servers (which is also known as Network Identity). There are a few factors to consider: total cost of ownership, scalability and extensibility of the platform, and whether any proprietary extended security features are used. A common misconception is that the total cost of ownership is usually the cost of obtaining the software license. In reality, the total cost of ownership also includes the cost of upgrading hardware (for example, the existing mainframe needs to upgrade to a G5 processor in order to run z/OS), the one-off and ongoing support or maintenance costs, additional hardware and software costs (such as additional Unix servers to host the Directory Servers, additional software required to run LDAP/390) to install and customize the authentication features, one-off and ongoing implementation costs for SSL- or PKI-based authentication and authorization, and integration costs. In addition, the business constraints and IT strategy for integrating with the legacy mainframe platform are important considerations. Thus, there is no easy answer to the design dilemma. EBCDIC ConversionThe mainframe interprets EBCDIC code pages but not ASCII. Java uses Unicode. Thus it is important to ensure that the mainframe integration technology includes EBCDIC conversion. For example, the CICS Transaction Gateway translates EBCDIC and ASCII into Unicode. |
