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
- Network communications. Are we using SNA or TCPIP?
- 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
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
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.
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:
- A service provider has a format of data it accepts, and format of what it
- 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.
- 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.
- The service provider receives this message, processes it, and optionally
returns information to the requester (also in the format specified in the
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.
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
- 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
- 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
- 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.