In-Depth

TP Middleware keeping up with mainframe revival

• By Rich Seeley
• March 1, 2002

If past prognosticators had been correct, the world would no longer need transaction processing middleware, the mainframe would be dead and the network would be the computer. And if the network were the computer, why would you need middleware? Where is the middle of the World Wide Web? Where is the middle of the Internet? Where is the middle of the average LAN? In the ideal network, there would be nothing to be in the middle of. But the prognosticators were writing science fiction.

Back here on planet Earth in 2002, the network is not the computer and we still have mainframes. Those legacy mainframes are the back-end systems supporting the new or nearly new e-business and e-commerce front-end systems. And if there is a front end and a back end, there has to be a middle. And that is exactly where transaction processing middleware comes in.

Even with the Internet, even with XML, even with Web services, there is still middleware, because even in 2002, business computing features a lot more Rube Goldberg-style architecture than most computer scientists would care to admit.

Organizations have invested a lot of money in those old legacy back ends -- some mainframe fans prefer to call them "backbone" systems -- and in today's uncertain economy, most IT departments are not planning to replace them. This is not the year to unplug the mainframe.

But as surely as necessity is the mother of invention, this could be the year of innovation in transaction processing middleware.

There's life in the old mainframe yet
While much of the attention has been focused on new technologies, including J2EE, .NET and Component Transaction Monitors (CTMs) -- also known as "the new middleware" -- there is no ignoring good 30-year-old Customer Information Control Systems (CICS) running on OS/390 mainframes, which IBM has now renamed Z Systems and Z/OS. Even CICS has a new last name: the latest version is called CICS Transaction Server (TS) and it now includes support for Enterprise JavaBeans (EJBs).

Of course, some developers are skeptical about how quickly CICS managers in major corporations will adopt CICS TS. Joe Kline, chief software architect at Centrifusion Inc., a Chicago-based consulting firm, recalled that when he worked in-house in IT for a major insurance company, decisions to upgrade to the next version of CICS met with stiff resistance from those who believed the Texas adage: "If it ain't broke, don't fix it."

Far from being "broke," even old versions of CICS are considered bullet-proof. As far as transactions within the enterprise are concerned, CICS is the workhorse that never gets tired and never lets you down.

"These old CICS backbone systems are not going away anytime soon," Kline said. "One of the big retail clients we work with, their Web presence is logically just considered another store. That Web presence must communicate anything it needs to the backbone system. It needs to send that information back to a CICS region. The actual brick-and-mortar stores are going to continue to work with the existing backbone system, which is a mainframe-based system."

The very success of CICS presents something of a problem to developers of Web applications for e-business and e-commerce.

Bob Lytle, Centrifusion's CTO, pointed out that one of his major retail clients has 10,000 brick-and-mortar stores running on a mainframe backbone system that relies on CICS. This retailer's Web site, where shoppers can buy online, is the equivalent of one store. Is the IT department going to risk a near bulletproof system supporting 10,000 real stores just to open it up to one virtual store?

Lytle has an answer: "No way!"

This, then, is one of the dilemmas for transaction processing middleware in 2002. The new Web commerce sites have to link to the existing enterprise back-end or backbone systems without causing major heartburn for CICS managers. And, in Lytle and Kline's experience, if IT management perceives that exposing the mainframe system to the Web is risky, the Web integration project may very well go on the back burner, if not into the deep freeze.

"If they [IT management] see it as this huge nightmare to get this functionality ported in a component that can be run in a distributed transaction on the Web," Kline said, "they may elect not to expose that unit of work or that process as a Web service."

Playing it safe
Tim Panagos, director, technology evolution at Pegasystems, a Cambridge, Mass.-based company that develops rules technology for transaction processes, has also identified a general trend toward avoiding risk in 2002. In surveying the CIOs at customer sites, he found that the uncertain economy is impacting IT budgets and creating a go-slow climate for innovations.

"Toward the later half of 2001," he said, "we saw a lot of discretionary projects just vanish. People got very cautious about spending money and they weren't going to spend even the budgets they had been allotted. Now, most of these large institutions have put their budgets in for the next year, so the reality of the situation is that the next year is going to be, I think, a very defensive position for technology."

Gone are the freewheeling budgets of the 1999-through-2000 boom. There is a stronger "show-me-the-money" attitude among CIOs and other corporate executives who, if they are going to spend anything on new technology, expect a quick return on investment. This new wrinkle in the corporate culture helps explain why a retailer will not risk the income of 10,000 brick-and-mortar stores by exposing its backbone to the Web for one virtual store.

"We're not going to see discretionary spending on projects, especially where the ROI is anything shaky," Panagos predicted. "What we're going to see is spending on only things that are [considered to be] hard ROI, guaranteed and quick turnaround. Companies are not looking for anything beyond a 12-month turnaround for their return on investment."

Put another way, the risk-averse climate does not make this the best budgetary year to launch new technology, even in an ROI-producing system such as transaction processing middleware.

"What people are going to look for are not things that are radical and new, because in reality that means unproven," Panagos said. "I think 2002 is going to be a little bit of back to the future. We're going to see a lot of effort along the lines of 'How do I get more out of what I've already got?' The spending on that is going to be fairly modest and it is going to be limited to things where you can really demonstrate that there will be cost savings this year in this application or by making these changes," he said.

"I think, in general, the wish list for 2002 is going to be very different from what it was in 2000 or 2001," Panagos continued. "In 2002, the IT wish list is going to be about 'How can I save my organization money?' By doing things more efficiently, by cutting down on infrastructure, by reducing my total cost of ownership of these processing applications. I still want to have relationships with my customers and get the transactions through, but I've got to figure out a way to cut the cost of doing that."

So despite hype from Bill Gates and others, Centrifusion's Lytle does not see Web services replacing traditional middleware anytime soon. The resistance to risky and possibly expensive new technology is just too strong in the glass houses this year.

The bottom line is that CTMs are going to have to meet CICS more than halfway for the technology to be adopted quickly. Centrifusion's Kline estimates it will need to be a 75/25 split.

Old meets new
"I think what our customers are looking for is ease in having these older legacy systems participate in distributed transactions," he said. "To the degree that these CTMs don't go more than half way, it's going to slow down their penetration."

So the question is: Can the new technology (CTMs) and the old technology (CICS) get along in the interest of better Web transactions for end users?
Kline thinks the accommodation will require the new technologists to stop treating the old technology like an ailing great uncle who is always rumored to be dying but manages to keep showing up at New Year's parties. CICS is more like forever-young Dick Clark.

"The new Component Transaction Monitors like the J2EE Framework and the .NET Framework, what they need to do going forward, and I think they are, is acknowledge that these mainframes and older middleware products like CICS aren't going away," said Kline.

But there's the rub. CICS is not going away but it is 30-year-old technology that was developed decades before anyone beyond university computer science centers and the Department of Defense had ever heard of the Internet. The transactions CICS was originally designed for were done primarily by clerical personnel working at dumb terminals. It worked with standard data input. It was never designed for the dynamics of Web commerce. Its creators never worried about fickle consumers pushing a virtual shopping cart through a virtual store and then deciding to chuck the whole order at checkout.

"I think the hardest part of developing with these two -- the old technology versus the new technology -- is the older TP monitors are not geared to participate in a distributed transaction," Kline explained. "There's really no easy way to tell it [the mainframe system] 'Oh, what I just told you to do, pull that back.' Whereas if you're working entirely in the new context with distributed transactions, you have phase two commits, and you can say: 'Everything we've done, just roll it back.'"

So the challenge is to adapt CICS to work in a distributed transaction where customers with Web browsers are constantly telling the system: "I want this book and this MP3 player ... no, wait, I want the MP3 player but forget the book. And I think I'll shut this down before I buy anything and go to the store and try out the MP3 player first. Goodbye."

Kline said Sun Microsystems and the other participants developing the specifications for phase two of the Java Connection Architecture (JCA) are working on this issue.

BEA Systems, San Jose, Calif., addresses the problem with its eLink Adapter for Mainframe, which, according to the company, "provides transaction support" for Z Systems (nŽe OS/390) running either IBM's CICS or BEA's own trademark Tuxedo.

Using an extension of the Component Object Model (COM) dubbed COM Transaction Integrator (COMTI), Microsoft offers support for CICS or IMS transactions in its BizTalk Server. For B2B projects, including two-phase commits, COMTI is designed to integrate mainframe transaction programs with BizTalk Server "by wrapping the CICS or IMS transaction data and execution calls into COM components, then exposing them in method calls and automation parameters."

Not surprisingly, IBM is also tackling the issue both in the new and upcoming versions of CICS, but also in its entire WebSphere platform, both of which are considered transaction processing middleware, according to David Chew, director of IBM WebSphere Enterprise Transactions Systems.

"We consider both of those as middleware, and the integration of those as middleware," Chew explained.

Currently, IBM is enhancing both WebSphere and CICS so they work well together in the very kinds of distributed transactions Centrifusion's Kline talked about.
"We have started to build things within the systems to leverage each other," IBM's Chew said. "For example, last year, CICS came out with its most recent version, CICS TS Version 2, which supports EJB in addition to the WebSphere family. You can use the same WebSphere Studio development tools to build EJB-based applications, not just for WebSphere, but also for those deployed in CICS. So we are getting integration and relationships from within those subsystems, as well as tighter and tighter integration between them."

On the horns of a dilemma between old and new transaction processing middleware, perhaps the safest choice this year is to say: "Let's support both." Where budgets allow, innovators in corporate IT can develop Web commerce and e-business apps of J2EE platforms or even .NET, as long as they support and facilitate the use of CICS on the backbone.