Are you beginning to plan your Service-Oriented Architecture (SOA) strategy but don’t know where to start? Or, are you already there and regret some of your prior decisions? Some early adopters might contend that the benefits of SOA don’t outweigh the cost. To eliminate setbacks and cost overruns, you should know what to look for when selecting a mainframe integration vendor.
Follow these 10 tips for better results with your mainframe integration vendor:
1. Research, question, and validate architectural options:
This step is most important when researching integration vendors; it requires due diligence in determining your particular requirements. You must weigh several factors when researching what architecture is best suited for your particular purpose.
There are three different schools of thought about integration architecture: distributed (anything that doesn’t reside on the mainframe); mainframe (no distributed run-time components); and hybrid (varying degrees of mainframe and distributed footprints):
- Distributed followers may look to an architecture that doesn’t require the installation of any additional software on the mainframe. This is certainly advantageous where there’s no access to the mainframe such as when the mainframe is outsourced, or where there’s limited contact with mainframe personnel or resources. Installation and configuration processes are faster, requiring no mainframe coordination. While performance is good, greater throughputs, load balancing, and failover are achieved through distributed server proliferation; also known as “server farms.”
- Mainframe proponents will look to architectures that are solely resident on the mainframe and possibly within various Object Transaction Monitors (OTMs) such as CICS. These products are unmatched in performance and scalability due in part to the intrinsic nature of the mainframe. Server farm and network complexity are replaced with a more complex internal architecture that requires mainframe knowledge and a coordinated project effort.
- Hybrid deployments are relatively new and uniquely combine the best of distributed and mainframe architectures. In this configuration option, some of the CPU-intensive processing can be shifted from the mainframe to distributed platforms for better workload sharing. This may be vital to mainframe shops that are MIPs-conscious and leery of making mainframe upgrades, since many software products have a MIPs-based pricing and maintenance structure. In a hybrid deployment, XML processing can be distributed, which may be more efficient than having your mainframe parse thousands of XML messages a second. As an added benefit, there may be reduced network traffic due to the added layer of abstraction that a hybrid deployment offers. Since the hybrid distributed server handles the XML parsing, this leaves only the “XML-stripped” raw application data that’s passed over the network to the mainframe server component.
No single architecture is ideal for every application; there are advantages and disadvantages to each. (For more on this topic, see the August/September 2005 z/Journal article, “Exploring Options for Mainframe Integration.”) Unfortunately many of the battles surrounding the selection of one of these architectures is one of comfort level, since neither of these groups is comfortable in the other’s back yard. Don’t be too quick to jump simply due to a bias ideology. Can your vendor support all three architectures? If so, you’ll enjoy great flexibility in deploying future projects.
2. Research and understand your microflow requirements:
Mainframe application systems such as CICS were around long before SOA or any standards-based programming techniques. Many early applications, while following standards set forth by the programming languages, had few standards to follow when it came to input and output mediums, and mainframe 3270 screen presentation in particular. As such, many applications with screen input and output became “tightly coupled” by weaving 3270 screen-based, pseudo-conversational logic with the business application logic. This interaction doesn’t fit with the “loosely coupled” synchronous model required for Web Services.
An estimated 80 percent of all mainframe applications are based on a tightly coupled model and can’t participate in SOA without restructuring the application to support “loose coupling.” The microflow eliminates the need for this costly restructuring by wrappering existing applications that have the screen and business logic inextricably intermingled, so they will appear to be loosely coupled. The microflow is responsible for isolating the user of the service from the access plumbing; in this case, the screen interactions and 3270 control information by encapsulating the mainframe application process flow.
Microflow deployments are handled in a variety of ways. Each is unique and requires an understanding to determine its acceptance within your enterprise architecture. There are two crucial components involved with microflow execution: the Microflow Script (MS) and the Microflow Processor (MP), or engine. Depending on the vendor’s integration architecture, these may be independent components or combined. Independent microflow scripts contain all the information necessary to enable the MP to successfully navigate the target application. Combined components contain the MS information plus the executable code inherent in the MP. For a detailed discussion of what questions you should ask a vendor about their support for microflows, see the accompanying sidebar.