When asked how to compose CICS business services, some think the answer is simple – use modeling to compose applications into business services that can be exposed as Web services within an SOA or made to plug-and-play with an ESB. If only it were simple....
In the CICS world, it turns out that modeling is NOT good for certain purposes, particularly describing or representing interactions with fine-grained terminal-oriented applications.
Modeling and CICS
In software engineering, the word “modeling” usually refers to a formal, top-down approach to describing how a solution will function. (Unified Modeling Language, a general-purpose modeling language that includes a standardized graphical notation used to create an abstract model of a system, is one example.) Modeling implies a level of abstraction higher than the ultimate implementation.
But for anyone involved in CICS integration, the critical questions are how and how well modeling works with CICS applications.
Let’s imagine I use a modeling tool to record a sequence of interactions with a CICS terminal-oriented, or “visual,” application. Let’s also imagine that when I press STOP, the tool generates a visual/graphical notation of these steps on the screen. What is it I modeled?
Did I model a business process? No. Did I model the application? No. So what did I model? I modeled me! I modeled my interaction with this particular application this one specific time!
The sequence of interactions I recorded does not represent all the pathways through the application, all the functions it can perform, or, critically, all its error conditions. There is no assurance that my “model” is correct or complete. To account for everything that may occur, you would have to model all these steps separately, then somehow knit all the models together. Ultimately, the level of abstraction of the model would be virtually identical to the actual implementation. That’s not modeling; it’s madness.
The Right Tool
When you compose a CICS business service from existing CICS applications, you engage in two distinct activities. First, you create something new – the business service – by defining the high-level building blocks of the service and how it will be exposed. This activity lends itself nicely to modeling.
Second, you specify the implementation of these building blocks. This boils down to codifying – i.e., programming – how your existing CICS applications must be operated to implement desired functionality. This second activity does not play to the strengths of modeling.
Consider this distinction in the context of the two types of CICS applications.
COMMAREA programs – with their well-defined inputs, outputs, and operational characteristics – are often well-suited to a modeling approach (although I’d caution that as a COMMAREA program’s operational level becomes more complex, modeling become less effective).
CICS terminal-oriented applications are another story. Evolved over many years with an eye toward productivity of trained users and optimal efficiency, they often defy the black-and-white, if-then-else mentality of modeling tools. In fact, when a modeling tool is used to describe the operation of a CICS terminal-oriented application, the tool itself often becomes the limiting factor – a hammer trying to turn a screw.
Modeling tools are perfect for describing a business service at the macro level – the top-level flow of the service, top-level decision points (conditional processing, looping constructs), and the invocation of coarse-grained CICS programs. A different approach is required to describe micro flows – the specific steps required to operate or interact with a terminal-oriented application and low-level data gathering, conditional processing, and looping constructs.
Modeling and Scripting
What’s the right way to express the operation of a CICS terminal-oriented application? SCRIPTING! But not just scripting per se. It is scripting used to intelligently operate a series of terminal-oriented transactions and access data within the context of a modeled CICS business service.
Ideally, such integration scripts would be developed and executed within the CICS environment. They would be able to access any CICS visual transaction, non-visual program, or data source – and many non-CICS resources. And they would enable system architects, process designers, and application developers to create services that automate and aggregate existing fine-grained transactions and data sources.
Scripts are concise; they are able to codify the well-defined steps in the operation of a terminal-oriented transaction; and they lend themselves to human understanding. Each step is visible and easily comprehended as part of the overall process. In contrast, modeling diagrams with any degree of real-world detail or complexity tend to become large and unwieldy, with models embedded inside models. When working on the lowest-level model, it is almost impossible to comprehend how it corresponds and interacts with the higher-level models.
In a high-volume, high-fidelity CICS integration architecture, modeling and scripting have important roles. But when it comes to intelligently operating a series of terminal-oriented transactions, scripting wins, hands down.
