Investigating IMS And SOA

By

Editing and SOA Research by Don Fowler

IMS Research by Ron Steele

 MCE 2005

 

 

What Is SOA?

SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners.

 

The reason that we want someone else to do the work for us is that they are experts. Consuming a service is usually cheaper and more effective than doing the work ourselves. Most of us are smart enough to realize that we are not smart enough to be expert in everything. The same rule applies to building software systems. We call it "separation of concerns", and it is regarded as a principle of software engineering.

 

How does SOA achieve loose coupling among interacting software agents? It does so by employing two architectural constraints:

1.        A small set of simple and ubiquitous interfaces to all participating software agents. Only generic semantics are encoded at the interfaces. The interfaces should be universally available for all providers and consumers.

2.        Descriptive messages constrained by an extensible schema delivered through the interfaces. No, or only minimal, system behavior is prescribed by messages. A schema limits the vocabulary and structure of messages. An extensible schema allows new versions of services to be introduced without breaking existing services.

 

A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.

Service-oriented architectures are not a new thing. The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification.

The directory shown in the figure to the left could be a UDDI registry. The UDDI registry is intended to eventually serve as a means of "discovering" Web Services described using WSDL. The idea is that the UDDI registry can be searched in various ways to obtain contact information and the Web Services available for various organizations.

All the messages shown in the figure are sent using SOAP. (SOAP at one time stood for Simple Object Access Protocol. Now, the letters in the acronym have no particular meaning as of latest SOAP standards.) SOAP essentially provides the envelope for sending the Web Services messages. SOAP generally uses HTTP, but other means of connection may be used. HTTP is the familiar connection we all use for the Internet. In fact, it is the pervasiveness of HTTP connections that will help drive the adoption of Web Services.

 

WSDL uses XML to define messages. XML has a tagged message format.

Web Services

The term "Web Services" can be confusing. It is, unfortunately, often used in many different ways. Compounding this confusion is term "services" that has a different meaning than the term "Web Services." In this paper, the term Web Services refers to the technologies that allow for making connections. Services are what you connect together using Web Services. A service is the endpoint of a connection. Also, a service has some type of underlying computer system that supports the connection offered. The combination of services - internal and external to an organization - make up a service-oriented architecture. 

 

For a Service Oriented Architecture, to better integrate business processes end-to-end in their enterprise and transact and interact with customers, suppliers, partners and employees, IMS V9 transactions can be published on the Internet as Web Services, connecting via SOAP and EJB bindings.

 

IMS Data and Transaction Integration with Web Services and Service-Oriented Architecture (SOA)

Web services provides the next step in the evolution of the Internet, allowing programmable elements to be placed on sites for distributed web access across platforms.

 

Enabled as Web services, the unchanged IMS Transactions, including those using MFS, can today support a Service Oriented Architecture (SOA).

This provides:

§ Leveraging past investments

§ Reducing new programming efforts

§ Aiding business process transformation

§ Aiding application integration with partners, suppliers, and customers.

 

For a complete detailed presentation on IMS as a SOA participant see

IMS Integration Strategy for On Demand Service Oriented Architecture at:

ftp://ftp.software.ibm.com/software/data/ims/shelf/presentations/IMSSOA.ppt

 

An additional paper of importance to the IMS user considering SOA exploitations is IMS On Demand Service Oriented Architecture Tools and Solutions at:

ftp://ftp.software.ibm.com/software/data/ims/shelf/presentations/IMSSOAWhitePaper.pdf

 

Proof Of Technology Offer

IBM is offering a no charge one-day session consisting of a combination of presentations and lab exercises. The IMS Proof of Technology session enables customers to gain an understanding of the different connectivity solutions that are available to access their IMS transactions and data. It is designed for customers who are looking for ways to exploit their IMS business processing assets using Web Services and remote data access technology.

 

This Proof of Technology has three parts:

The first part takes customers through the configuration of IMS Connect to show TCP/IP connectivity to IMS. The exercises in this section demonstrate the high level features and functions of the IMS Connect product.

 

The second part includes hands-on exercises using WebSphere Studio Application Developer Integration Edition to generate an IMS Web Service that can be deployed into an application server environment to access IMS Connect and IMS. This section is designed to show end-to-end connectivity from a generated web service that can invoke an IMS transaction.

 

The third part includes the configuration of the Information Integration Classic Federation (IICF) product on a z/OS server to access IMS. The exercises in this section show how to run the Data Mapper tool to create an SQL view of IMS databases.

 

The PoT attendees will also be given an opportunity to configure an ODBC client on their workstations that can be used to directly query the IMS data.

 

This offering is no charge but clients are responsible for their own travel, meal, and hotel expenses.

 

For further information, a Proof Of Technology Workshop on Web-Enabling IMS, or general Q&A, please contact ronsteele@earthlink.net or call 919-523-0305.