Legacy systems over SOAP and REST
Integrating modern applications with your legacy systems running on z/OS can be challenging. Your z/OS system is likely to have an IBM MQ interface and very likely speaks with fixed length formatted messages. Not only that, but those messages are probably encoded in EBCDIC.
It is, to put it mildly, difficult to parse MQ messages with fixed length payload in, say, JavaScript. Not impossible, mind you, but difficult. Software engineers working on new systems will not be very productive in this environment.
There are essentially two ways to approach this:
Path #1: Bite the bullet
You work with your engineers and somehow get the job done at the expense of lot of engineer’s days. Next project it happens again. Except that the next project is .NET and has to be done all over again. This works. But it is painful, slow, and expensive. And maybe worst of all — it is difficult to maintain.
Parth #2: Use the force
Provide SOAP and REST WebServices to the new consumers that prefer them. By using IBM Integration Bus (formerly WebSphere Message Broker) it is easy to expose WebServices to interface to your legacy systems. Not only that, but you can provide both SOAP and REST, XML and JSON making life much easier for everyone.
Integration Bus translates between different protocols and formats easily and naturally. It’s core functionality, built very efficiently and reliably. It is done once and the newly available services can be consumed by everyone who needs them, be that JavaScript, .NET, or the next, yet unpublished, fad.
Using Integration Bus streamlines the process, provides services of higher quality, and does this faster and for a lower cost. It has number of other advantages to boot. Here are some:
Maintenance
Maintenance becomes a whole lot easier. When new service is needed or an old service needs to be updated, this is done in one place and consumers can start using the new service straight away.
Service Aggregation
Legacy services need not be mapped to Web Services 1:1. Legacy services can be consolidated, packaged, and easier interface can be made available for new systems. This not only provides interfaces that are easier to use and saves on development and debugging time, but is also more efficient. Transactions that are on a critical performance path execute more quickly and users get better response times.
Avoiding Duplication
When a new system needs to use a service that has been made available previously, it is already there. Newly developed systems benefit from previous investments.