IMS & SOA: Answers to the Most Commonly Asked Questions

by Robert Morris
March 17, 2009

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.