FREE DM Review Site Registration!
Sign-up today and access DM Review on the Web!

Your FREE registration entitles you to:
FREE email newsletters

FREE access to all DM Review content

FREE access to web seminars, resource portals, our white paper library and more!

   

SOA and Your Mainframe – Understanding and Overcoming Common Concerns

Simply SOA

While service-oriented architecture (SOA) is enjoying a continued increase in both real-world implementations and marketing buzz, one area that raises more questions than answers is how the mainframe fits in SOA initiatives. The mainframe continues to be the mission-critical platform of choice for virtually every member of the Global 2000, local, state and federal governments. Most mainframes at large enterprises contain thousands and thousands of valuable line-of-business applications and serve as the central repository of record – where the so called “one version of the truth” is maintained. Mainframe applications and data drive the way the world does business – from ATM transactions to airline tickets and virtually every financial transaction on the planet. So why is it that the most significant computing platform in existence is subject to so much controversy over how, and even if, it should be included in SOA initiatives?

 

It’s really quite simple. While the mainframe is a ubiquitous computing platform driving business around the world, it is viewed as a “black box” by many architects and CIOs. On one hand, executives know it as a trusted partner of the business. Many mainframe programmers and business analysts enjoy long tenures at the same employer, many having 20-year plus careers with at the same employer. Contrast this with the newer Java and Web-centric technologies of the last decade where the average life span of an employee could be as little as 18 months. As a trusted confidant, the mainframe has helped bridge the unease that exists between business and IT. Yet, an air of mystery persists. Most organizations simply do not have a real understanding of the thousands of applications and diverse databases spanning multiple mainframe subsystems and database management systems (DBMS).

 

Beyond a lack of understanding of what applications reside on their mainframes, many in IT view the mainframe as old and Web-based technologies as new. Old stereotypes die hard. The mainframe is seen as a proprietary platform, with stove-pipe applications and nonrelational databases. Integration with the mainframe has historically been the realm of frail screen-scraping technologies or required risky changes to the code-base. This was true in the past, but there are now high-performance software solutions designed to leverage the performance, security and reliability of the mainframe in the world of Web interfaces and SOA.

 

This cloud of fear and confusion that permeates many IT executives who have not come up from the mainframe has led many organizations to choose not to involve this mission-critical platform in their early SOA initiatives. This is a mistake. If you’re a large enterprise with mission-critical applications running on the mainframe, you cannot ignore the platform as you formulate your SOA strategy. The heart of SOA is about reuse – both existing applications and data. The whole concept of application reuse isn’t such a novel idea. It’s been around a long time, and mainframe developers have been building reusable services from the beginning.

 

The mainframe should be an active participant in any SOA project, from tactical to strategic. In larger mainframe-centric organizations, whether they are CICS or IMS based, not only should the mainframe be an active participant, it should serve as the lynchpin in an enterprise SOA strategy.

 

Let’s examine some common concerns regarding SOA and the mainframe:

  1. Security. Opening up the mainframe outside of the firewall is a security risk.

     

    Applications have been extended beyond the mainframe for well over a decade. Security is always a key concern, and should be addressed as part of your SOA strategy. Many mainframe SOA tools exist that allow you to continue to leverage the Enterprise Security Manager (RACF, Top Secret, ACF2) and provide additional security for the transaction using WS-Security.

     

  2. Skill-set. My existing mainframe staff doesn’t have the right skill-set for SOA.

     

    This is a common fallacy. Organizations look to their mainframe developers who have deep knowledge of both the mainframe functionality and data and how the applications are used by the business. While it has been said that mainframe COBOL programmers lack the expertise to build services, this is not the case. There are tools that exist today that allow companies to leverage their mainframe staff to engender valuable Web services. There is no one more qualified to service-enable mainframe applications with the right granularity than the COBOL programmers who understand the mainframe code and the business. This allows services to be exposed in the right manner, possibly spanning subsystems and databases.

     

  3. Performance/Scalability. My applications are mission critical, and require XXX number of TPS (transactions per second) and the ability to scale to thousands of users.

     

    The performance of your service-enabled transaction will depend on many factors – network latency, size of the XML payload, third party tooling and application servers, how fine-grained the message is and even the performance of your underlying mainframe application.

     

    One of the most important tips for achieving superior Web services performance is tied to the actual size and level of complexity of the XML payload being transferred. As your Web service input document increases in the number of elements or file size, more processing is required for serialization and deserialization. In most cases, you should avoid breaking the service down into too fine-grained of a message.

     

    If you need to send or retrieve a 75K object that has 15 properties, each 5K long, you can retrieve all 75K as one Web service request, as 75 requests for 1K or some other combination, such as 15 requests for 5K each. Transferring the 75K in one single Web services request is the best-performing alternative. Transferring 1K, 50 times is the worst-performing alternative. The overhead cost of latency is the major factor.

     

    As you design services out of your core mainframe business logic, always keep performance in mind. In many cases, it is not enough to simply create a single function Web service. This may result in poor performance at run-time as it does not capture the true business process. A business service, whether from the mainframe or another system, is often a multi-function composite service. Building your business services with the right level of granularity will reduce any performance issues.

     

  4. Financial Concerns. I want to reduce not increase the amount of MIPS I’m running on our mainframe.

     

    This is a very valid concern in the age of expensive MIPS-based pricing. An increase in MIPS on the mainframe often results in “upgrade charges” from a host of third party software vendors. Application agility is the key issue to addressing this concern. You must consider solutions that allow deployment of mainframe-based Web services across the widest range of platforms, engendering true application agility. A flexible approach that allows for deployment of mainframe-based Web services across z/VSE, z/OS, CICS/TS, CICS, IMS, Windows, Wintel, UNIX and Linux allows you to make the decision where to house your SOA workload. You may choose to host all of your Web services on the mainframe, off the mainframe or perhaps use a hybrid approach to take advantage of the architectural benefits of the mainframe and the reduction in costs associated with a Linux or Windows server.

As you embark on an enterprise SOA strategy, do not neglect involving your mainframe. Gather feedback from industry analysts such as Gartner and Forrester. Talk to other companies who have been down the same path. The benefits gained from service-enabling your mainframe far outweigh any cost or risks involved. If your mission-critical business applications reside on the mainframe today, then you absolutely must leverage the mainframe as a key component in your SOA strategy.


Robert Morris, GT Software chief strategy officer, is responsible for the planning, integration and marketing of GT Software product solutions to the global market. Morris has an extensive background in application development and integration including experience with CASE methodologies, distributed systems as well as midrange and mainframe environments. He speaks frequently at customer and industry events including Gartner Symposium, Java One, IBM Common, IBM Transaction and Messaging, and IBM CICS and IMS. You can reach him at rmorris@gtsoftware.com.

For more information on related topics, visit the following channels:



Industry Vendors