When it comes to a legacy application with a real legacy to protect—namely, billions of records' worth of important information of all kinds—IBM's Customer Information Control System, better known as CICS (usually pronounced "kicks" for those not already in the know) is something of a nonpareil as an important information repository and access tool. But the methods for bringing this information together with modern Web services and applications have been interesting to describe and sometimes tortuous to implement.
In fact, many first generation Web-to-mainframe applications depend on what is euphemistically described as "screen scraping." In this approach to data access, a Web-based application opens a virtual terminal window (usually some kind of TN3270 session) in a back-end, enters commands through that window to the mainframe and then grabs the resulting data in character form from the resulting terminal output (that's where the aforementioned screen activity comes into play). That's because CICS applications have traditionally been built only for access through such mechanisms and weren't architected to separate operation of the business logic from the presentation of results, either logically or physically.
Given that XML is a tool designed to permit arbitrary representation of data of all kinds, it would seem tailor-made for this kind of thing. But when it comes to CICS, "this kind of thing" involves a huge amount of work. Though it does allow enterprises to sidestep the use of 3270 data streams and screen-scraping, it also involves acquisition of tools carefully constructed to understand internal CICS data layouts and organizations and able to map them into explicitly defined XML schemas of one kind or another.
Take HostBridge for CICS Integration as a case in point: this custom (and proprietary) integration software actually runs on a mainframe inside the CICS environment, built around the CICS Transaction Server's Web Support (CWS) and 3270 Bridge features. CWS enables HTTP clients (usually Web browsers) to communicate directly with CICS application programs without involving some kind of intermediate gateway or Web server in the middle of that activity, while 3270 Bridge defines a mechanism whereby data may flow into or out of a CICS transaction without generating a 3270 stream as output, or expecting a 3270 stream as input. This enables HostBridge to handle all IO operations for a CICS transaction without using 3270 streams at all.
One key ingredient in the HostBridge "special sauce" for this implementation comes from the XML markup used to pass data between the CICS environment and Web-based applications. Essentially it provides an explicitly-labeled version of all the transaction status and description data, along with equally-well labeled input or output field data, depending on the direction of data flow for the specific message in motion. This technique enables developers to avoid the specific dependencies on data layout and formats that screen-scraping inevitably entails – where data isn't labeled and can't be easily parsed, sorted or searched – and where any changes to the host application require commensurate changes to the data processing inside what's being scraped off the screen.
As such this makes an admirable case for how XML helps to bridge the sometimes formidable gap between legacy data applications and repositories, and modern front-end clients that enterprises would like to employ to access such information. For more information on this process, and some extensive examples of the actual XML markup employed in HostBridge, check out the Bitpipe white paper Integrate CICS Using XML.
About the author
Ed Tittel is a full-time writer and trainer whose interests include XML and development topics, along with IT Certification and information security topics. Among his many XML projects are XML For Dummies, 4th edition, (Wylie, 2005) and the Shaum's Easy Outline of XML (McGraw-Hill, 2004). E-mail Ed at etittel@techtarget.com with comments, questions or suggested topics or tools for review.
