Getting Started With SOA: 10 Tips for Better Results With Your Mainframe Integration Vendor

by Doc Mills
March 1, 2006

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. 

3. Know your integration requirements upfront:  

Do you need access to mainframe raw data from various file structures, or access to applications where your requirements permit the use of data that’s already been manipulated through applications? Usually, it’s the latter. In today’s highly regulated environment, it may be prudent to take advantage of existing secure application interfaces to data rather than expose raw mainframe data through new Web-based interfaces. 

If application integration is required, ask if the vendor supports an architecture designed to take advantage of the transaction monitor’s unique framework such as CICS. Data integration platforms dictate an architecture independent of the transaction monitor and must be closer to the database, where it makes sense from a performance perspective to do so. These integration platforms run in their own independent mainframe address space while servicing requirements from many different databases.