IMS & SOA: Answers to the Most Commonly Asked Questions

by Robert Morris
March 17, 2009

Service-Oriented Architecture (SOA) is a pivotal integration practice that brings disparate applications and systems together to achieve the agility and flexibility required to meet today’s business needs. Enabling new and existing applications to access corporate information is critical to growing the business and reducing application development costs. However, is it really possible to use all your technical assets, including the mainframe, in an SOA?

Architects and developers alike agree that mainframe SOA is achievable, yet when it comes to integrating these assets, most of them attempt these projects using tools with limited capabilities, which usually results in not meeting the real requirements of the desired solution. Many organizations are realizing that leveraging mainframe assets in an SOA is feasible, but only if the right tools are in place.

What About IMS?

IMS, one of the mainframe’s most proven transaction systems, celebrated its 40th birthday last year. IMS and SOA have recently generated lots of talk, but what does SOA mean for the IMS developer?

IMS has been delivering on the promise of SOA for more than 40 years. IMS provides the ability to construct applications from existing functions or services, as most IMS transactions are individual, stateless transactions—just like a standard Web service. By reusing IMS transactions and data, services can be quickly and easily isolated and exposed from existing systems with minimal impact to the underlying applications. As SOA becomes a common, accepted pattern for application development and integration, IMS is uniquely positioned to participate—if not lead—the change. Nevertheless, several key questions repeatedly emerge when organizations consider SOA and IMS/DB and IMS/DC. This article addresses the most common questions.

Q: Can I really reuse existing IMS/TM transactions and expose them as Web services?

A: Absolutely. IMS transactions can be turned into Web services using tooling available from several Independent Software Vendors (ISVs). IMS transactions are inherently stateless, making them perfect candidates for service-enablement. While this is architecturally feasible, existing inputs and outputs may not exactly match what you require in the new Web service. The key is to use a solution that lets you control which inputs and outputs will be rendered in the new Web Services Description Language (WSDL). Additionally, you must consider where the service will run (on or off the mainframe).

Q: Can IMS databases be exposed as Web services?

A: Yes, and there are several Web services solutions available that expose IMS data sets as Web services. It’s critical to leverage technology that doesn’t just work with single, online IMS data sets. You can use SQL-type commands to “join” multiple databases into one Web service. This allows developers with knowledge of SQL to create data services without requiring additional training or knowledge of Web services. These data services can be orchestrated as part of a business service to deliver value to the customer.