dcsimg
RealTime IT News

Myths And Realities of Web Services

NEW YORK -- Web services  and service-oriented architecture (SOA) have been the holy grail in computing for at least 20 years.

After all, the idea behind Web services, such as reusing code so applications don't have to repeat basic tasks when they speak to each other, is re-making the Web as a more dynamic global communications network. Want to add mapping features to your site? Maybe the ability to add a few "pushpins"? Welcome to the data-exposing world of Web services and the protocols they're built upon.

Just beware of the upside and downside of some protocols behind Web services, experts say.

"The good news about Web services is that we have open standards behind them," said James Metzler, vice president with IT consulting firm Ashton, Metzler & Associates. This means applications can communicate over any type of platform without proprietary systems getting in the way. "The bad news is that we don't have all we need yet," he added.

Some of the messaging protocols for Web services need to be refined, networking experts said during the Interop trade show and conference here.

Take the XML  messaging standard for piping information across networks between applications. They can be quite the network hogs.

"Web services are real, but we've also learned that they're not perfect," said Peter Haggar, senior technical staff member in IBM's emerging technologies group.

Not that he's slamming XML messaging. XML messages help applications act on what's in the message body and content.

That helps servers prioritize the types of Web services requests traversing a network and decide which type of security policies should be applied to the messages.

XML-based messages also help networks segregate purchase orders from plain old queries and then find the least-busy server to act on those requests.

But all that messaging can become verbose. Because text-based XML messages take longer to process, the payloads in those messages can incur extra processing costs in the network. That can become an inhibitor to the adoption of Web services and SOAs.

"There are many applications that don't use XML today because it's too large and processes too slowly," Haggar added. He said that's why standards bodies are mulling a switch to a binary XML format in order to reduce the processing size of text-based XML messages.

That's not a panacea, either.

"It's not as simple as creating some other format," Haggar said. "XML works because it works. With binary XML, you may end up introducing interoperability issues," which are anathema to the open standards that drive Web services adoption.

Haggar said IBM is working with industry partners and a committee within standards body W3C to address the chatty XML problem.

Then there are issues with the SOAP messaging format, a lightweight XML-based messaging protocol for carrying messages about Web services across a network.

Turns out that envelope system is not as lightweight as everyone thought.

SOAP support has "kind of stunk for [open source scripting languages] PHP, Python and Perl," said Chris DiBona, open source program manager for Google.

"There are times when SOAP is too much of an interface for a simple Web service," he added.

When you add the time to process an XML message with an object model using SOAP, it just gets a little slower.

Still, SOAP was the right technical decision to make when Google was releasing its Web search application programming interface code . "It's just a little crufty right now," he said, using a common developer term for software or a system that's too complex. DiBona was quick to note that support for SOAP has improved in the most recent version of open source scripting language PHP (version 5).

Although it may be considered "too thick" for some Web services applications, the bottom line is that SOAP is what the industry has to use if developers want their Web sites to provide all kinds of fun ways for users to pull information and interact with their sites.

DiBona's advice: "Start with whatever your favorite language is, and see what it supports" among Web services standards. "In my opinion, SOAP isn't great on PHP yet, but it's getting better."

It's also up to the tool makers to address the issue, too, said Rick Fleischman, director of product marketing for ActiveGrid, which provides a service-oriented application platform built on the lightweight architecture of the LAMP (Linux, Apache, MySQL, PHP/Python/Perl) software infrastructure stack.

"I think the complexity with protocols lessens as better tools come out," he said. "There is a learning process involved and a process of exploring what backend systems can be exposed [to other networks]. In an ideal world, you shouldn't have to deal with these protocols. That's what tools are for."

The processing and network latency issues with XML and SOAP may be a headache, but they're not enough to stop Web services adoption in its tracks, said Sundar Rajan, director of Web architecture for communications software provider Avaya.

"We're going ahead with XML because it makes it so much easier to integrate systems," thanks to the common language of XML, he said. Plus, "hardware is getting cheaper, so you can always add more servers if more processing power is needed," Rajan added.

"In terms of time to market and usability of Web services, XML is a godsend and a gift. I don't think anybody is stopping their deployments because of these issues."

DiBona and other panelists agreed, pointing to Amazon.com's exposure of Web services APIs as one compelling example. "You can do amazing things with it, such as create entire stores, or emulate the Amazon.com site yourself. From a business and technology standpoint, it's remarkable."