WEB SERVICES COMING OF AGE (AGAIN)

by Andy Longshaw

25 April 2003, marked the third anniversary of the publication of the Simple Object Access Protocol (SOAP) specification, version 1. Many outside the world of Web services probably missed this landmark, but the impact of SOAP and associated protocols over the past three years should not be underestimated. Neither should their impact be overestimated.

Despite the level of hype associated with Web services, progress has been "measured." Much of the first year in the life of SOAP was spent ironing out the interoperability issues inevitable in any specification-led initiative. The protocol has also undergone several major changes, including the inclusion of non-XML attachments and the replacement of the original message data description mechanism with the XML Schema data definition language from the World Wide Web Consortium (W3C). The current, ongoing SOAP specification is still clearing up some consequent updates from such changes.

The domain of Web services has suffered from the parallel development of the standards needed to support the desired level of interoperability. The key standards of Web Services Description Language (WSDL) and Universal Description, Discovery, and Integration (UDDI) both appeared within a year of SOAP and have since developed alongside it. Changes to fundamental XML standards and a plethora of new Web services standards have all added to the turbulence.

All of the standards work is ultimately just paper. In terms of real, delivered, mainstream systems, life is finally emerging from the primordial soup of Web services standards. After several years of applying the basic protocols on live projects, with their usual set of unexpected demands, there is a far clearer understanding of what Web services are -- and what they are not.

One thing they definitely are not is a way of simply accessing objects (despite the origins of SOAP's name). Using them as a form of simplistic, fine-grained "glue" similar to Java's Remote Method Invocation (RMI) or Microsoft's Distributed Component Object Model (DCOM) is an unwise path. In this respect, the tools can be deceptive. Many mainstream tools derive Web services definitions from source code, such as Java, C#, or Visual Basic classes. This can be dangerous in terms of incorrect granularity and the mapping of data types. In this sense, the ease of use of common tools can lead the unwary to make incorrect "assumptions." Coming from the other direction, WSDL editors can be expensive, and some are little more than WSDL-aware versions of Emacs or Notepad.

Being first is a risky business. In terms of Web services, there has been plenty of learning for the early adopters. The most effective learning comes from "doing" and making mistakes. Few people want to publicize their mistakes, or even sometimes their successes, but by following such successes and failures, the wider community can learn from them. To use Web services effectively in real-world business systems requires a different approach from many traditional distributed systems. Those who have survived and delivered their systems know the benefits of service-oriented architectures, well-defined interfaces, and well-thought-out data types in a Web services architecture. As we head toward the second generation of enterprise Web services applications, those lessons should be well heeded.

-- Andy Longshaw