News

Standards issues can't stop Web services spread

• By John K. Waters
• July 8, 2004

Much has been made about the current state of Web services standards development. Several different organizations are now involved in the process of establishing the technical specifications for enabling applications to interact over the public Internet across organizational and domain boundaries -- which is the essential promise of Web services -- but no unifying authority exists to provide a clearly defined direction for those groups. Consequently, some argue, many potential users of Web services are holding back, waiting for the "standards madness" to sort itself out.

And yet plenty of developers aren't waiting around for the standards to coalesce (or congeal, as one writer put it). With enterprises like eBay and Amazon.com publishing their APIs, releasing SDKs and ramping up developer outreach programs to solicit applications that utilize Web services to interact with their systems, there's just too much opportunity to sit on the sidelines while the standards sort themselves out.

According to Gartner analyst Ray Valdes, developers currently wrestling with Web services are faced with a tradeoff between scaling back their requirements to meet the present day capabilities of platforms and toolkits, and maintaining the scope of their requirements with the understanding that there are gaps that will require custom-built code -- code that will need to be ripped out when that capability is embedded into the platforms down the road.

"You can go with basic Web services enablement," Valdes explained, "where you sprinkle some compiler directives, configuration parameters and key words into an existing, monolithic application and then turn it into a distributed Web services application. I call that 'Web services magic dust.' Unfortunately, the result is not magic, and will likely not perform as you want. Or you can stick with what is proven, what works -- the basic SOAP messaging, XML and WSDL -- and write your code to that low-level foundation. And that means you either scale back your application requirements to fit within that envelope, or you maintain your more ambitious application requirements but fill in the gaps with your own customer code that implements security and reliability, which tends to be a universally prevalent requirement for non-trivial applications."

But Valdes sees the details of Web services protocols and standards as low-level milestones along the path toward Service-Oriented Architectures (SOAs). That's the hard part, he said, and it goes beyond what vendors can provide and what standards are in place. It's a large-scale move and it's happening slowly, but it's going to require some real learning and growth on the part of developers.

"It's true that distributed computing has been around for a while," he noted, "but most developers have built only monolithic, non-distributed systems. They just don't have any practical experience building distributed systems."

How do they get that experience? By building smaller-scale, lower-risk systems that have some of the basic distributed architecture requirements of larger-scale systems. It's a tried-and-true approach, said Valdes.

"It's been a rule of thumb in system design and implementation that a successful, complex, large-scale, distributed system generally evolved from a functioning smaller-scale distributed system," he explained. "The large-scale systems that were built in the past either had horrific failures or very painful births. Very few large-scale distributed systems were designed in one fell swoop. The successful ones evolved from smaller-scale systems."