Tech Guide: Three Tiers Minus One

The purpose of Web-services software is to expose data that belongs to a mainframe database application, making it accessible by outside programs and means other than the mainframe application's own terminal screen

InformationWeek Staff, Contributor

August 13, 2003

3 Min Read

The third category of Web-services-enablement software is the one that's generating the most attention, and even some controversy. CommerceQuest Inc.'s Traxion Business Process Management suite "Web-service-enables all CICS resources, and then further gives [customers] the opportunity to create composite services by assembling together these individual services, all from the mainframe and/or from other Web-services-enabled components elsewhere in the network," says Paul Roth, chief technology officer at CommerceQuest. The result is a business process that exposes itself from the mainframe as a Web service, bypassing middleware entirely.

ClientSoft Inc.'s ServiceBuilder software for Windows Server adopts an either/or approach, letting customers incrementally disuse middleware services as they see fit. "Solutions that utilize the application logic are typically the most valuable, because they take advantage of the 20 or 30 years' worth of business rules that have been encapsulated in many of these programs," says Brian Anderson, ClientSoft's director of product marketing.

The elimination of the middle tier is a new architectural trend, says Pete McCaffrey, IBM's director of product marketing for zSeries. "More and more, we're seeing customers move toward two tiers, with this middle tier getting squeezed out," he says. "So you may be seeing the beginning of a trend as a result of our embrace of open standards, but also the result of the technologies that are now being deployed that are going to drive us more toward at least a physical two-tier implementation."

But not everyone is so enamored by these claims that they're prepared to toss the middle tier entirely. Karen Larkowski, executive VP at analyst firm the Standish Group, is skeptical. "There are no benefits that I can think of and many costs to consider," she says. Without middleware outside the mainframe to perform the job of mediation, Larkowski says, companies are left to write infrastructure code by themselves or interpret the code produced by automated tools. "The biggest problem here is the cost of failure. We have found that applications which include homegrown middleware have a near 90% failure rate," Larkowski says.

Cutter Consortium analyst and author William Ulrich is more intrigued by the two-tier option but also warns of the dangers involved, such as creating new transactional logic that the underlying original logic does not, and cannot, expect. There's also the fact that simply wrapping Web-services documents around existing transactions bypasses what could be many companies' key problem: the spaghettilike behavior of the transactions themselves. "In reality," Ulrich says, "you're not really addressing the underlying segregated architecture."

There are benefits, such as improving workflow and eliminating the green-screen hassle, Ulrich says. But as far as improving the application itself is concerned, "you're putting icing on a half-baked cake," he says. "You still have a lot of starting and stopping, you don't have [proper] flow from system to system, a lot of the underlying systems use batch processes, and there's a lot of inelegant handshaking going on behind the scenes. You're not making that go away."

Return to main story, Five Ways To Modernize Your Mainframes

Illustration by Doug Ross

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights