Applying Service Oriented Architecture (SOA) to IMS ...

Applying Service Oriented Architecture (SOA) to IMS based Legacy Systems

Author Name: Arvind Radhakrishnen

Abstract In this era of Globalization, organizations have to be flexible to the ever changing business demands and IT is required to be agile to the changes in the business processes. Most fortune 500 companies run their critical IT operations on legacy systems and are looking to make the existing applications more agile. As a strategy for aligning IT to business processes Service Oriented Architecture (SOA) has been gaining momentum. SOA provides opportunities to combine the advantage offered by the new technologies and at the same time re-use the legacy infrastructure. This paper presents a brief introduction of how SOA can transform legacy IMS based system to a strategic business asset.

1. Introduction As technology evolved over the years, organizations have started demanding more and more from their business applications and information infrastructure. To cater to these needs, new technologies are emerging. However, legacy systems are involved in mission critical business logic and systems like Fund Transfer, Stock Exchanges etc. There are cases where these legacy codes have been re-written to new generation programming languages. But the cost of re-writing the code can be huge and changing the business logic is risky. However organizations realize that in order to stay competitive they need to evolve their IT systems along with the fast growing Internet world. This paper illustrates on how existing legacy IMS based systems are being made more agile by including SOA based architecture.

1.1 Challenge of Converting Legacy IT Asset to Web Service To remain competitive companies have to respond quickly to rapidly changing environment by adjusting their business processes. Further to survive in this competitive world, organizations need to extend their business processes through multiple customer contact channels and across Web. This is being facilitated by the new and emerging e-Business technologies. They are changing the paradigms in which companies are developing and maintaining the applications. These applications are built and maintained on separate platforms, integrated through sophisticated mechanisms and matter to business now more than ever before. The reason is because the customer’s first experience of a business is through a web-site rather than the traditional face-to-face or through phone. Web applications have become interactive and they drive business as they have become face of the organization. Also, with the outsourcing and off-shoring gaining momentum the organizations have started feeling the need for integrated solutions that can enable the teams spread across the globe to work effectively. Organizations have started developing new applications to survive in the “Globalization Era”. It is estimated that in the year 2007, about 25% of the IT spending will be on the development of new applications. The cost of developing and maintaining new applications on newer and emerging technologies are much lower than that of the legacy systems. This has made the CIO’s and IT managers of the companies to rethink on their legacy IT systems. The need for legacy systems to be modernized and re-engineering is felt across the industry. However this process needs to be evolutionary, making the integration of the system in phases rather than dramatic changes that would send shock waves to the company’s IT budget.

The new E-Business applications developed on technologies like Java and .NET using the SOA architecture are inherently distributed and multi-tier. In typical three tier architecture the business logic is separated from presentation and data access logic. The expectations from data access tier are:

● ● ● ●

Provide high performance. Sustain high performance under peak concurrent loads. Maintain high availability. Support centralized management and administration.

IMS based legacy systems satisfy all the above requirements for a data access tier. This can be reaped into a lot of cost savings. By leveraging the combination of legacy IMS and new GUI rich applications, we can achieve reusability, flexibility and lot of cost savings. Each time an existing component is re-used, the cost saving accrue from not having to insert a new business flow or maintain the same in another application. By implementing SOA on IMS systems we can make the change to business processes more flexible as organizations gear up for the competition with lesser cost of development of applications.

1.2 Introduction to IMS and Transaction Management System IBM’s Information Management System helps organizations with high availability, scalability and support for new and emerging technologies. IMS Transaction Management System and the Hierarchical Database Management System have been scoring big on the scale performance and cost. IMS uses Transaction processing that has makes the distributed computing reliable. Large enterprises are dependent on Transaction Processing Systems for critical operations and Hierarchical Databases are preferred over Relational Databases when performance is preferred over productivity.

3. Importance of IMS IMS has been helping customers run their businesses for nearly 40 years As per IBM, more than 95% of the fortune 1000 companies use IMS. The following statistical data will illustrate the importance of IMS.

● ● ●

Over 15 million GB of Production data on IMS. Over 50 billion transactions run through IMS per day, where individual companies have run over 100 million transactions per day. Nearly $3 Trillion goes through IMS per day.

IMS continues to enjoy such success when relational products (like DB2) are more mainstream and easy to use. The reasons include the speed and the database size. IMS is known to handle more than 7 million transactions in an hour (21,000 transactions per second). Another benchmark shows IMS serving 6000 transactions per second across TCP/IP. These are impressive numbers indeed. Also the database size has recently been increased to support over 40 terabytes of data. IMS now provides High Availability Large Database online reorganization capability. This is totally non-disruptive, with zero outage to customers for those applications that cannot go offline.

2. Block Diagram of SOA implemented IMS Systems A Block diagram showing SOA is implemented in IMS based legacy systems is shown below:

Figure 1: Block Diagram of SOA based IMS Systems IBM IMS SOAP Gateway is a Web services solution that enables IMS applications to interoperate outside of the IMS environment through Simple Object Access Protocol (SOAP) to provide and request services independently of platform, environment, application language, or programming model. This is the gateway for enabling the legacy IMS systems to a web enabled service. Different client applications built on Microsoft .NET, Java can submit SOAP request to drive the business logic. The SOAP processor and IMS processor act as middleware and process the SOAP messages. The SOAP Gateway (middleware) converts it to an IMS input message and sends it to IMS through IMS Connect. IMS Connect is a TCP/IP listener / server application that enables the communication between SOAP Gateway and IMS Open Transaction Manager Access (OTMA). The SOAP Gateway also receives message from IMS and converts it to a SOAP message and sends it back to the client.

1. IMS SOAP Gateway IMS SOAP gateway helps integrates IMS systems in a SOA environment. It enables the IMS applications to operate outside of IMS environment to provide and request services independent of platform, environment, application language or programming model. Any application, irrespective of the technology on which it is built can submit SOAP requests into IMS to drive the business logic of COBOL applications. The SOAP gateway requires a Web Service Description File for deploying the IMS transaction as a web service. It is an XML file used by clients to discover and invoke the service. It exposes the operations that the service exposes. We generate the WSDL and Correlator file using WebSphere Developer for zSeries using the COBOL copybook layout for input and output messages for IMS transaction. The WSDL file is published to UDDI or a Repository so that the web service client can use the same to generate web service request. For installation and configuration of IMS SOAP gateway, please refer ftp://ftp.software.ibm.com/software/data/ims/soap/imssoap921.pdf When the IMS SOAP Gateway receives an incoming SOAP request, the Gateway processes the SOAP header and retrieves the correlation and connection information for the input request. The SOAP gateway can either pass the XML data directly to IMS CONNECT or convert into string of bytes to be carried over TCP/IP connection. We can choose either of the options depending on where we want the XML data to be transformed (on the gateway side or IMS side). Before sending data to IMS CONNECT, appropriate headers are also added. IMS CONNECT sends back the response from the COBOL application to SOAP gateway. The gateway in turn

wraps SOAP header and sends the response back to the client

2. IMS CONNECT IMS Connect is a first generation connector that provides an application-programming interface (API) called Open Transaction Manager Access (OTMA) so that TCP/IP Connections can access IMS. OTMA is a connectionless client server protocol that provides interface specifications for communication with the IMS. The logical connection between OTMA and IMS CONNECT is called TPIPE. IMS CONNECT calls XML Adapter to convert the incoming XML data to application byte stream and vice versa for outgoing messages. This is an optional component and allows the IMS Transactional requests to be in XML and no changes to existing IMS COBOL applications be required. This conversion support identifies the appropriate XML adapter and XML converter. The XML converter driver is generated by using WebSphere Developer for zSeries and the COBOL copybook for input and output messages. It is then uploaded to IMS host, compiled, linked and made accessible to IMS CONNECT. A block diagram illustrating the XML Adapter and XML converter inside the IMS CONNECT is as follows:

Figure 2: Block Diagram of IMS CONNECT Once the input XML data is converted to application byte stream, it is passed to IMS Message Queue for processing. The Transaction Manager (TM) runs the program corresponding to the transaction, which processes the input message. After processing by the program, the Transaction Manager (TM) routes the reply back to OTMA, which in turn routes it back to IMS CONNECT. The Transaction Manager and OTMA depend on the OTMA Client name and TPIPE name for identifying the source/destination of the response message. IMS CONNECT then uses the XML adapter to convert the response to XML and send it back to SOAP gateway. There are some restrictions in using XML data conversion support provided by IMS CONNECT. These are:

1. IMS SOAP Gateway v9.2 is the only supported gateway. 2. XML Adapter only supports single segment messages. 3. Inbound and Outbound messages must be encoded in UTF-8. There is an alternate approach in which the COBOL application can be modified to process the input XML data directly. This would eliminate the need for XML Adapter in IMS CONNECT. Depending on the cost of development either of the above approach could be taken.

3. Case Study: SOA implemented on IMS based systems in a leading bank of US. TCS is a central player in outsourcing of the important IT functions of this bank located in US and is involved with the application development, enhancement, and other tasks. The Bank maintained different data sources for customer and account information depending on the location in which the account was opened. This had an impact on the customer experience, as the bank had separate applications to access information from the different mainframe data sources. With the advent of web based e-Business applications, the Bank realized the need for growing and evolving the bank’s legacy systems. The bank wanted to consolidate their business functionalities and wanted to retain the legacy mainframe assets. As TCS was already taking care of the production support, hence it was invited for helping the bank in this project. The existing system setup was too complicated because of multiple data sources and region based business logics implemented in different applications. Hence during initial project stages, it was decided to create new applications that would leverage the existing data sources. To support it, a logic was deduced which would identify the data source based on the account number and/or customer unique identification number. The project used the onsite-offshore model and used the waterfall model for development. The requirements were gathered at onsite and development and unit testing were carried out at offshore. Subsequently, the system testing, implementation and user acceptance testing happened at onsite while offshore provided the support. The architecture design involved a Three View Model: User Interface: Users access the application via browser. Business Interface: The core of the business logic is object oriented and involves JSP, EJB and Servlets. Data Interface: The data is stored in the backend Mainframe based IMS database systems. To access this data source, a middleware based on Webmethods was used. Development on the different interfaces was carried out by different teams and a collaboration mechanism was formed through the onsite co-ordination. The issues that would come in the interactions between the systems would be taken up and resolved at onsite, while any development or re-testing of the interfaces would be done at offshore. The Business Interface Level had small sub-applications which implement the logic for selecting the data source. These small applications support the overall system architecture. To illustrate the data flow between different interfaces, we will consider this scenario. During login to Online Banking, the JSP at User Interface sends request to the servlet running in the Business Interface. The servlet sends SOAP request to a middleware (SOAP Gateway) to find the customer and account details. The middleware finds the corresponding data source by using the sub-applications. SOAP Gateway translates the incoming SOAP request and sends it to corresponding IMS host. The IMS CONNECT on the IMS host receives the message and passes it to Transaction manager for processing. The Transaction Manager invokes the corresponding program and it gives back the response appropriate to the request. The response message is then routed back to middleware (SOAP Gateway) through IMS CONNECT and again back to the requesting servlet, which again routes it back to the JSP to display data on the browser. As could be seen above, the IMS transactions are behaving as services which could be invoked by front end eBusiness applications on need to need basis. This is how SOA was implemented and enabled Bank to retain and reuse the legacy architectures, saving a lot of cost.

Initially, the interaction between SOAP Gateway and host IMS systems was based on fixed API for inbound messages (to IMS) and outbound messages (from IMS). In subsequent developments, the need for more applications grew and it was realized that the existing API’s were not standardized and could not be re-used. Hence a new set of standardized API’s were created to facilitate the interaction between IMS and SOAP Gateway. There are two API’s; one for inbound message to IMS and the other one for outbound message from IMS. Both the API’s comprise of two parts:

1. API Header 2. API Detail The project involved development and standardization of the API’s which could be used for future development. A sub-routine was developed on the host IMS to validate the API header. The API header would give details about the IMS transaction. Upon standardization the efforts involved in the development and testing of newer e-Business applications has been reduced by 20%. The development and testing is henceforth carried out only for API Detail. For Inbound messages to IMS, the API Detail would specify the inputs to the IMS Transaction. For outbound messages, it would contain the expected data from the IMS Data store. Hence API Detail part would be dependent on the requirement of the front end application. By leveraging SOA based architecture, following applications have been successfully developed and deployed.

● ● ●

New thick client GUI based application for Placing and Removing Hold on Accounts irrespective of the data source location. This has saved about $1.8 million annually to the bank. Enhanced Call Center Applications that can inquire on the account details, cheque clearing details, hold inquiry, fund transfer and Loan Inquiry irrespective of data source location. Enhanced Interactive voice response (IVR) systems that can retrieve transaction details. The customer delight with IVR is now increased by about 0.15% and an improvement of 0.08% in the percentage of calls that are completed in IVR (as opposed to an agent).

As a business result of the above, the customer experience is now about 84% (Customer experience is a satisfaction percentage gathered by survey by external vendor). The end result of SOA implementation is the development of GUI rich front-end applications backed by legacy mainframe asset, resulting in competitive edge and cost-savings. The scope for the enhancement is unlimited but is restricted by the “Cost of Opportunity”.

3. Conclusion IMS although may be old, but it has evolved over the years to support the needs of modern databases and applications. IMS is being continuously enhanced with the features it needs to continue to support your business. With IMS supporting SOA based architectures, it makes a good business sense to retain and re-use the investments done in the past which can result in lot of cost savings for the organizations.

4. Reference 1. IBM Soap Gateway enables IMS applications to inter-operate outside of IMS environment through SOAP. More details can be found in http://www-306.ibm.com/software/data/ims/soap/ 2. IMS Transaction Manager facilitates access to applications under IMS. To find more on how it works, refer to http://publib.boulder.ibm.com/infocenter/zoslnctr/v1r7/index.jsp?topic=/com.ibm.zmiddle.doc/zmiddle_29.html 3. An inside look at WSDL http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci811272,00.html 4. Enterprise Data Integration: A critical piece in a Service-Oriented Architecture http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci1171085,00.html