TP Middleware keeping up with mainframe revival
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
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
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
"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
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
"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
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
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.
Rich Seeley is Web Editor for Campus Technology.