CICS Gets Another SOA-Friendly Infusion
- By Stephen Swoyer
IBM Corp. last week announced a new version of its CICS Transaction Server for z/OS. Version 3.2 takes CICS even deeper into SOA, with new support for COBOL message definitions, improved integration with IBM and Tivoli management tools, and a host of other niceties, IBM officials say.
Version 3.2 isn’t the final word as far as CICS is concerned: IBM is mulling over a number of potential changes to its venerable mainframe transaction processing platform, including Web 2.0, event-driven, and even batch enhancements. That’s all in the future, however. For the present, IBM officials are content to position CICS 3.2 as the no-brainer hub for an organization’s -- any organization’s -- service-oriented architecture.
"What I think we find is that there’s a very substantial segment of our enterprise customers that would like to build an SOA hub around their mainframe," says Jim Rhyne, enterprise software platform chief architect with IBM. "They understand that the most critical of their applications and data are on the mainframe, but also they’re used to thinking of the mainframe as kind of a management and control point. What they’d like do is expand that so that SOA reaches a number of other platforms, with [the mainframe] functioning as this sort of point of control."
Enter CICS 3.2, which -- on top of the SOA-friendly amenities IBM introduced two years ago in CICS 3.1 (a release that Rhyne says effectively brought Web services capabilities to CICS) -- gets a few extra SOA-ready tweaks, too.
"[S]ince we released [CICS] 3.1, we’ve had the fastest rate of upgrade to that version than at any time through the history of CICS," Rhyne notes. "We’ve had just an intense amount of customer interest in the SOA features we’re providing in CICS, not just measured by customer upgrades, but just a lot of the questions and feedback and suggestions from customers about what they’ve like to see next. A lot of this has driven features we’re releasing [in CICS 3.2]."
CICS 3.2 boasts improved integration with IBM’s own CICSPlex management tool, as well as with Big Blue’s Tivoli management ecosystem. The idea, Rhyne says, is to give both tools better visibility into SOA-related workloads as they flow into and out of CICS.
"We’ve added some management APIs in the HTTP and the Web services stack that runs in CICS to allow better monitoring of workloads as they enter and exit a CICS environment through those particular portals," he indicates.
CICS 3.2 also boasts a new application response measurement (ARM) correlator, which helps improve problem detection when used in tandem with ARM-compliant management tools. "Previously this is something which had been very hard to do, so one of the things we provided in CICS Transaction Server 3.2 is support for this ARM Correlator. We have spent a lot of time and energy providing support for this capability that allows us to trace into all of our products to help accelerate problem-solving," Rhyne explains.
Other New Features
Elsewhere, Rhyne says, CICS 3.2 boasts new management APIs that enable more in-depth monitoring of SOAP traffic as it flows in and out of CICS, along with a number of performance and reliability optimizations, too.
"One of the problems people have in putting Web services interfaces around their existing transactions is that 15 or 20 years ago someone thought it would be a good idea to use COBOL language data features … [and] in the early versions of Web services for CICS, we didn’t really support mapping these types of data types very well. One of the things we’ve added is an extended capability for support of these more exotic types of data types," he explains.
In the past, Rhyne says, customers couldn’t easily convert these COBOL message definitions to XML, mostly because IBM’s existing implementation (in CICS 3.1) didn’t support what he describes as "exotic" use cases. "We’ve fixed that," Rhyne avers.
In addition, he says, CICS 3.2 supports 64-bit exploitation for channels and containers. "We’ve seen people starting to flow some rather large messages using [CICS’] channels and containers capabilities, so we added the ability to move the channels and containers above the 31-bit address space, so even if you’re dealing with large flows, it doesn’t take away from the 31-bit address range," he indicates.
Embarking on SOA Projects
Since IBM shipped its first Web-services-ready version of CICS (3.1) two years ago, many CICS shops have embarked -- with varying degrees of aggressiveness -- on service enablement projects.
Rhyne says they’re typically doing one or two things: either exposing CICS and other mainframe workloads to other applications via Web services, or -- more ambitiously -- doing the former, but tapping the mainframe (and CICS Transaction Server) as the hub of an organization-wide SOA effort.
"It’s a combination of those two things. We see a number of customers coupling WebSphere on zSeries with CICS. We also have introduced a feature called the Service Flow Run-time, and the Service Flow Modeler," he says. "That allows us to do some synchronous choreography within the CICS environment itself. This is really designed to enable customers to simplify their environment by not having to purchase products that do external choreography … [so they get] much better performance with native choreography than with an external choreographer talking to CICS through a TCP/IP pipe."
Most customers, Rhyne observes, are working with SOA. "The bulk of the customers seem to have moved on from planning and kicking the tires to serious implementation. One of the things historically that’s been difficult is getting good connectivity between Windows and the mainframe, and Web services basically solved that problem. That’s one of the reasons most [CICS] customers are either investigating or actively pursuing SOA."
Future revisions of CICS could boast native support for Web 2.0 features, along with the plumbing necessary to help companies transition to an event-driven architecture.
"There are parts of Web 2.0 having to do with providing information on mashups, and also [support for newer] programming languages like PHP. We’re starting to see a lot of customer interest in [this], so we’re looking at some of that stuff -- things like what should we do in future versions in order to support Web 2.0," Rhyne comments.
"There’s a lot of interest especially in our banking and financial customers, but also in [the] transportation and medical [industries] for event-driven architectures, so the issue there is [when] something happens -- it’s not like a synchronous request … this is something that’s a lot different and has to be a lot more dynamic."
Finally, Rhyne says, the nature of batch -- good old batch -- also seems to be changing. IBM just isn’t sure how it’s changing, Rhyne concludes -- although the CICS team has its collective ear to the ground.
"A lot of customers are struggling to grapple with the fact that there’s no batch window anymore, so how do they get to a 24x365 operation … and still retain data consistency," he points out, "so they’re looking at moving to parallelization of batch streams [and] moving to doing batch work incrementally alongside OLTP work they do normally. We’re looking to see what role CICS should have in this transformation of batch applications. These are all things that we think are going to have an impact on the future of CICS, [although] there’s not anything that is firmly planned enough that [we can commit to] taking a new direction."
Stephen Swoyer is a contributing editor for Enterprise Systems. He can be reached at firstname.lastname@example.org.