IMS & SOA: Answers to the Most Commonly Asked Questions
by Robert Morris
March 17, 2009
** Read this article online at http://www.mainframezone.com/applications-and-databases/ims-soa-answers-to-the-most-commonly-asked-questions
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.
Not all SQL-based queries are good candidates for Web services. For example, if a query returns lots of data, converting that response to XML may result in a verbose response that can affect response time and overall performance.
Q: There’s much discussion about top-down and bottom-up approaches for SOA. What does this mean in the context of service-enabling IMS?
A: Top-down service design, where business processes drive the development of the Web service, is a best practice for mainframe SOA. Even so, bottom-up design seemingly allows faster delivery of some basic services. Each has its place in an enterprise that’s implementing or converting to applications based on SOA.
With the top-down approach, the mainframe developer works in advance with the consumer of the service, identifying the functional and data requirements, resulting in the WSDL definition. It’s then up to the mainframe developer to map the supporting mainframe components to the service requirements defined in the WSDL. This process is often referred to as delivering services at the right level of granularity. This means delivering the proper Web service interface based on the consumer’s needs. This also introduces a new requirement: the ability to deliver composite services.
Q: What are composite services? Do I need them, and what’s the best approach?
A: Composite services are Web services that combine more than one “step” to complete processing. A step is basically an autonomous unit of work. A good example is executing an IMS transaction.
Orchestration is a capability that defines how to combine multiple steps into a composite. This resulting composite will represent a series of steps into a new logical unit of work. Orchestration is the key to providing IMS-based Web services at the right level of granularity. IMS developers and architects should investigate tooling that provides orchestration capabilities that enable the delivery of composite services—allowing a singular Web service to combine steps and deliver the desired functionality at the right level of granularity.
The alternative to the composite approach is to service-enable each individual transaction, and then attempt to combine the “little Web services” into the correct Web service with a Web Services Business Process Execution Language (WSBPEL) tool. Technically, this approach will deliver the correct service, but you’ll be faced with a service that’s too complex, has too many layers, and may not meet performance objectives.
Q: What if I need to combine IMS transactions with other data sources (e.g., 3270 screens, multiple IMS subsystems, various data sources, CICS, etc.)?
A: Orchestration is a critical component for SOA success. A proper strategy for IMS transaction orchestration is to ensure you have the ability to access not only a singular IMS transaction, but multiple IMS transactions. You should be able to add functions that gather data from a multitude of additional subsystems, including 3270 screens, multiple IMS subsystems, VSAM files, CICS, and even Web services.
Q: Can IMS conversational transactions be SOA-enabled?
A: Contrary to what most developers consider conventional, IMS conversational transactions can be SOA-enabled. To be able to convert an IMS conversation into a Web service, you’ll need to be able to track and specify the start of the IMS conversation, the continuation of the conversation, and how or when to end it. This way, you can service-enable the IMS conversation without leaving any open resources. Figure 1 shows how an IMS conversational transaction can be service-enabled.
Q: Can I pull in data from external Web services into my existing IMS transactions?
A: It’s possible to synchronously execute external Web services. To achieve this, it’s best to employ a solution that will do the work of helping you locate the Web service, call it, and provide the calling program with the response data. lf you have an existing IMS transaction that would benefit from data through external Web services that are available, you can add simple code into your program and issue a singular Application Program Interface (API) call.
Q: What about designing services for reuse?
A: The whole concept of application reuse isn’t so novel. It’s been around a long time, and IMS programmers have been building reusable services from the beginning. IMS developers were arguably the first services-based developers. While they weren’t using Web services and XML, they were building reusable IMS transactions. These IMS transactions are completely reusable services that can be orchestrated to accomplish scores of transactions or business processes.
Q: What about resource utilization and scalability?
A: As SOA adds layers of processing, scalability, performance, and resource utilization are always concerns. Companies sometimes will choose to begin with a small test case. If it’s successful, they’ll then deploy on a larger scale.
Ensure you choose a solution that’s efficient and capable of good performance. As companies seek to lower costs and take advantage of new functionality, they need the ability to service- enable workloads and shift them to environments such as Linux on System z and to leverage specialty engines.
Summary
IMS is ready for SOA. Its role as a robust, proven transaction system is the perfect match for SOA. IMS developers are already seasoned and knowledgeable, and can undertake virtually any SOA project. The key to success is to fully understand your requirements and select products that can directly meet those requirements. Proper preparation will ensure your initial and long-term service-enablement efforts will result in resounding acceptance and support.
