longpelaexpertise.com.au/ezine/WhatIsSOA.php?ezinemode=printfriend

LongEx Mainframe Quarterly - November 2008

management: What Exactly is SOA?

It can seem like you can't run away from SOA. We're all bombarded with hundreds of whitepapers, Redbooks and articles all indicating that it will solve all your computing problems. But what exactly is it, and is it worth all the hype? Let's take a look.

What is SOA?

Crusty old veterans like me will talk about the good old days when applications were relatively simple. They ran in one application environment like CICS or IMS, and on just one computer. You logged on, and did what you needed to do. But such simple applications are becoming the exception rather than the rule. Applications today are becoming composite applications. This means that to perform one task, you may run five applications on three different application environments on three different servers. And these servers probably won't be the same platform. One may be Microsoft Windows, one UNIX, and one zSeries Mainframe.

For one application to talk to another on a different platform is quite complicated. You need to think about:

  • The application programming interface (API) of the application you need to talk to - and they're all different.
  • The format of the data to pass to the target program, and what will come back.
  • Network communications. Are we using SNA or TCPIP?
  • Security
  • Data translation. Computers in different countries will use different locales (or code pages). Also, Mainframes use EBCDIC, other platforms use ASCII.

But what if we didn't have to worry about any of this? What if we had one single easy to use API? An API where all we needed to know was what data needs to be passed in, what will be returned, and where to send it. That's what SOA is all about.

In this ideal world, we have a program requesting a service, a program providing a service, and a gap between them called an Enterprise Service Bus. So it looks like this:

OK, this is all great. But here's the big secret: SOA isn't real. It's a set of concepts, ideas and practices. It doesn't offer anything concrete. To implement SOA, you need something else. There are a few 'something elses' available, but for Mainframe sites you'll be concentrating on two: SOAP and Websphere MQ.

SOAP

When people talk about SOA, the chances are that they'll soon be talking about Simple Object Access Protocol (SOAP). SOAP is a way of implementing SOA. It works like this:

  1. A service provider has a format of data it accepts, and format of what it will return.
  2. These formats are made available to any requester in the form of a Web Service Definition Language (WSDL - pronounced Wiz-Dal) document. This is an XML document in a certain format that requester programs can use to automatically format data being sent and received.
  3. The service requester sends an XML message over HTTP or Websphere MQ to the service provider requesting the service. It includes data as specified in the provider's WSDL document.
  4. The service provider receives this message, processes it, and optionally returns information to the requester (also in the format specified in the WSDL document).

The big feature of SOAP is that it uses standard web technology: HTTP and XML (though Websphere MQ can also be used to transport SOAP messages). So no special software is needed.

IBM has bought into SOAP in a big way. Websphere Application Server, CICS and IMS can now all support SOAP messages going in and out. However in the case of CICS and IMS it isn't necessarily straightforward.

Many people use the terms SOA and SOAP interchangeably. But don't be confused, they're very different things.

Websphere MQ.

Anyone using Websphere MQ is already implementing SOA. Websphere MQ has for many years provided sites with a robust, easy to use postal service.

Controlling your SOA Environment

As anyone with networking experience will know, getting two applications to talk to each other is just the beginning. If you have 200 applications on 50 servers in several geographical areas talking to each other, it's going to be hard to:

  • Fix problems. If an application is running slowly, where is the problem? On which server?
  • Setup and monitor security. How do you secure your services? How do you perform audits?
  • Manage services in case of a server failure or replacement. You may want two servers offering the same service for redundancy. How do requesters know which one to go to?
  • Monitor performance.
  • Monitor capacity, and plan ahead for future growth.

Lots of new software has been introduced in the past few years to address these problems, including:

  • IBM Websphere Enterprise Service Bus
  • IBM Websphere Message Broker
  • TIBCO Enterprise Message ServiceTM.
  • IBM Tivoli Composite Application Manager
  • CA Wily SOA Manager

Is SOA Worth It?

The SOA concept certainly looks appealing. It promises a lot, and may very well be your best answer for allowing new applications to easily access your existing core Mainframe applications and data. But as a Systems Programmer with a Mainframe point of view, I'd be very careful before implementing a large scale SOA solution. Here are my concerns:

  • Can SOA provide the performance needed? Mainframe workloads are usually far higher than other platforms. Can the current SOA technology deliver?
  • Will SOA dramatically increase usage of Mainframe resources such as CPU, memory and DASD?
  • Are SOA tools sufficiently mature and robust? I'm hesitant to be on the 'bleeding edge' of any new technology.
  • Can a SOA environment be managed? It seems to me that SOA environments can quickly get out of hand without correct management and procedures.
  • Are there sufficiently skilled people to support a SOA environment? As with any new technology, finding skilled people with required skills can be difficult.

However if these concerns can be addressed, SOA is definitely worth a look.


David Stephens