Mainframe SOA

In many conversations I participate in regarding Service Oriented Architecture (SOA), part of the conversation oftens leads to "....how best can I incorporate my mainframe in the SOA architecture...".  There are a number of mainframe SOA-enabling options, and in this post I will share my opinion on the application of a short-list of tried and true approaches.

From my point of view the mainframe is very similar to incorporating a service interface on most other existing IT investments.  The common primary objective is to extend the reach and reuse of key data and business logic from the mainframe to other applications and business processes such as trading partner interactions over the internet, business-to-customer portals and business intelligence applications like dashboards and data marts.  The other common objective is to have a more flexible capability to "re-locate" processing from mainframe compute cycles to a different platform in order to optimize the use of computing resources while not breaking upstream and downstream system interfaces.

These common two objectives often mean that loosely coupling through a platform independent interface is a top-tier requirement to maximize reach, reuse, and location independent processing.  Given this, I see three primary approaches to mainframe SOA which meet these objectives and loose coupling requirement.  Each of these approaches can be readily used for both inbound and outbound data flows to and from the mainframe, yet have a different set of pros and cons.

The first approach is to use a [STR archive available for a limited time at http://www.sei.cmu.edu/str/str.pdf] message-oriented middleware (MOM) or message queue (MQ) to act as a network protocol and data payload "bridge" between the mainframe and an established service interface which is implemented on an intermediary like Intel SOA Expressway or other application server.   The main advantages are that this type of architecture supports reliable messaging to protect messages from loss, works well in asynchronous integration patterns, and can be effectively triggered through event-driven transactions.  However, the extra middleware (MOM / MQ) is a fairly substantial performance overhead, so for high volume and low latency data exchanges this approach can cost significant budget to scale.

The second approach is to use a web services framework for the mainframe which is available from a host of vendors.  SOA Software and GT Software represent a couple of specific examples.  In this case, mainframe assets like CICS transactions and IMDB databases are directly exposed with a SOAP web service interface.  It is a slick technology upgrade that is easy to deploy.  However, like with any web services implementation security, performance, protocol interoperability still needs to be covered.  This means adding a SOAP web service interface to a mainframe does not guarantee reliable interoperability in a SOA environment.  Often denial of service protection and support for security approaches beyond WS-Security are needed.  Also, in many SOA architectures there are web services, REST, and other bindings to service end-points creating the need for an additional intermediary like Intel SOA Expressway to support these additional security and interoperability scenarios with high performance.

The third approach is to directly apply an integration middleware product to a data feed on the mainframe.  The integration middleware often converts data structures between a cobol copybook and XML.  The integration middleware also handles the network protocol translation between what the mainframe can understand and what the other protocols in the SOA architecture (like web services, REST over HTTP, JMS, etc.) require.  The main benefit of this approach is that business rule processing can be readily put into the integration middleware and offloaded from the mainframe without a functional or regression impact to the overall IT landscape.  This offload is only a net benefit however, if the integration has the performance characteristics to continue meeting business SLA's and not causing transaction "drag" in other parts of your architecture.  Intel SOA Expressway provides the cobol copybook conversion function and protocol translation at very high levels of execution performance through straightforward configuration.

The common theme here is that it takes more than a web service to create a SOA-capable mainframe.  Needs for capabilities like message reliability (option 1), support for SOA-enabling a diversity of mainframe assets (option 2), and business rule offload (option 3) will drive which option is the most appropriate way to go.  Yet, a secure, high-performance and flexible service intermediary like Intel SOA Expressway is a common piece of infrastructure needed to establish a SOA-capable mainframe.

Thanks for getting this far.  I look forward to hearing from you about your mainframe SOA initiatives and your approach to incorporating the mainframe into your SOA architecture.

Joe

For more complete information about compiler optimizations, see our Optimization Notice.