In-Depth
Best Practices: Troubleshooting Web Services Performance on zSeries
Although there are performance problems associated with Web services technologies, companies have plenty of available options
Like it or not, Web services standards such as XML and the Simple Object Access Protocol (SOAP) have been much hyped as cure-alls for most enterprise host integration needs. Not surprisingly, however, the hype attending Web services has also fomented a backlash of sorts, with some frustrated adopters even casting aspersions on the viability of the technology.
As a result, some prospective users are skeptical of these technologies—even if they’ve experimented only slightly with XML and Web services. Take Kevin Kinney, a mainframe operator with a financial services company, who describes the experience of a colleague who explored the use of XML in his company’s environment. “I have a friend who … [is] an acknowledged expert on SGML, having given presentations around the world,” he explains, noting that this individual works for a prominent automotive manufacturer. “We got [to] talking about XML. He told me he describes XML as ‘SGML with a better publicist.’”
The problem, this expert says, is that XML simply generates too much data. “I'm told the reason is that converting to XML doubles the size of a database. When you're working with individual databases well into the terabyte range, this gets to be a concern,” Kinney concludes.
As strange as it may sound, Jim Rhyne, a distinguished engineer and eServer tools and enterprise modernization architect with IBM Corp., says that an example like this isn’t surprising. Big Blue is very bullish about XML and Web services, Rhyne stresses—when they’re used intelligently. The trick, he says, is to first understand the strengths and weakness of the technologies in order to make judicious use of them when and where they’re appropriate.
“XML has many advantages, but it’s important to keep in mind that it also has different requirements for things like storage [space], [network] bandwidth, or processing performance,” he says, noting, for example, that XML messages are typically larger, consume more bandwidth, and require more processing power than some other protocols.
Mark Vanston, a senior program director with consultancy META Group, agrees, noting that if there’s one shortcoming associated with the use of XML and Web services, it’s a requirement for additional processing power during XML parsing. “I think people are realizing that there are issues with it and it’s taking a while to come out. There’s performance issues, mainly,” he concurs.
Matching XML to Your Resources
In fact, Rhyne concedes, some organizations—such as the World Wide Web Consortium (W3C)—have mistakenly pushed XML as a panacea for tasks as disparate as data storage, data presentation, and data processing.
That’s just not realistic, he says. “What’s going on here is there’s some tension in this space between the interests of the open standards community, the W3C in particular, for whom XML is sort of the lingua franca—it’s the universal communication language and if you have to buy extra performance, well, that’s part of the entry into the game,” he explains. “The other side of that is that we have established commercial protocols … where it’s important for people to be able to make maximum use of the network bandwidth that they have, and the processing power that they have, and they’ll go to extraordinary lengths to handcraft messages to optimize their system."
For applications where performance, network bandwidth, or storage aren’t concerns—because such resources are plentiful or because of the lightweight requirements of the application itself—straightforward SOAP XML messages are typically all that’s needed. “If you’re not performance-sensitive, you can use XML directly, and we have things like high speed XML parsing technology to help you cope with that,” he explains.
Unfortunately, Rhyne acknowledges, SOAP-over-HTTP messaging may not cut it in all applications—particularly in mainframe environments, where resources are typically micromanaged. “For some folks, it may be that their principal problem is dealing with network bandwidth issue, for example, because transmitting [SOAP messages] is three to ten times the expansion factor for data that’s been packaged as XML,” he observes.
The principal problem, explains Luigi Suardi, development manager in the R&D operations group with BMC Software Inc., is that XML is typically translated from more concise binary data formats, resulting in bloated XML messages. “Web services have a certain level of performance hit because of the richness of the metadata and the transformation from a binary format data structure into XML and so forth,” he points out.
Mitigating the Performance Impact
Nevertheless, experts say, customers do have options to mitigate the performance impact of Web services, particularly if they’re running S/390 or zSeries mainframes.
For starters, says IBM’s Rhyne, Big Blue has built very efficient XML processing facilities into its COBOL and PL/1 compilers. This ensures that mainframe systems can process XML messages more efficiently than other platforms, he claims. “When we put the XML facilities in COBOL and PL/1, we very deliberately went for high-speed technology. So one of the things we’ve found is that in typical batch applications, doing the XML parsing adds maybe 10 percent to the overall processing cost, and it would be even less for a transactional application, because in trans applications there’s so much set up and tear down.”
For users concerned that SOAP messages may gobble up their available network bandwidth, IBM recommends a healthy dose of compression. “One of the things that we’ve found is that there are various kinds of very effective compression techniques that have been used on XML to get the size back down to something reasonable,” Rhyne suggests.
IBM has currently submitted an XML compression algorithm to a standards body for review, he says, and Big Blue might eventually decide to build a hardware-based XML compression facility into zSeries, just as it did with the CMOS Cryptographic Coprocessors and IBM PCI Cryptographic Coprocessor on its zSeries and S/390 mainframes, respectively. “It’s certainly something that we’re looking at. The guys who do the sort of very deep-level operating-system work that work closely with the hardware guys, they’re always looking at places where some combination of low-level operating system services and hardware can improve processing capacity. So XML, encryption, compression—these are just a few of the things people have been looking at,” he says.
Leveraging WSDL
Nevertheless, he concedes, there are applications—for example, high-throughput OLTP—in which neither of these approaches will be of much help. In this case, Rhyne recommends eighty-sixing SOAP-over-HTTP messaging in favor of another approach. “You don’t literally need to use SOAP-over-HTTP,” he points out, arguing in favor of an approach that leverages the Web Services Description Language (WSDL). “Our strategic direction is to use WSDL as an interface definition language that’s capable of describing not just SOAP-over-HTTP but any number of other kinds of protocols as well.”
Instead of exchanging garrulous SOAP-over-HTTP messages, Rhyne explains, customers can “describe things like COBOL data structure interfaces into CICS applications through the CICS Transaction Gateway using WSDL.” There’s a WSDL description and a binding for this kind of data encoding and transport mechanism, Rhyne argues, and for customers that can’t afford to skimp on performance, it’s an excellent alterative to SOAP-over-HTML. “Just simply moving to WSDL gives them a lot of advantages of a service-oriented architecture in terms of being able to connect into these applications, but they don’t lose anything of what they’ve got in terms of performance,” he argues.
Developers may balk at the ostensible complexity of using WSDL in lieu of SOAP-over-HTTP, but Rhyne says that Big Blue’s WebSphere Studio IDE can simplify much of this activity. “Within WebSphere Studio today you an put together something that makes it look to the client like he’s talking XML to a CICS application,” he explains. “There is even an adapter that runs in WebSphere that actually converts that XML into a CICS Comm Area.”
The Technologies Today
There’s enough hype associated with XML and Web services to make even the most credible of mainframe professionals skeptical, allows META Group’s Vanston, but the simple fact is that many Big Iron shops are effectively using these technologies today. “There are a bunch of clients out there who are using it for repurposing issues, there’s a lot of people going through CICS interfaces using XML schemas to build some objects, that’s probably its primary use,” he points out. “There are a fair number of financials that are doing it. The airlines are doing it. They’re typically building reusable schemas.”
Similarly, says IBM’s Rhyne, although there are performance problems associated with the use of these Web services technologies, companies have plenty of available options. “I haven’t met a customer yet whose requirement for performance can’t be met in this way [by using WSDL to describe COBOL data structures into CICS applications],” he concludes. “Essentially what that does is it leaves in place all of your existing communication structures, but allows you to also accept transactions that are encoded in XML by converting those transactions into the Comm Area form that’s understood by the application.”