eb services are a new breed of cat in software development. Self-contained, self-describing, modular applications that can be published, located, and invoked across the Internet, Web services are intended to automate a wide range of business functions, everything from providing stock quotes to processing credit card transactions to any of a 1,001 other services.
Not surprisingly, Microsoft and Sun are engaged in a catfight at the moment over what exactly constitutes a standard set of Web services protocols, a fight being thrashed out in bureaucratic infighting centering on membership in the would-be industry-wide standards body, the Web Services Interoperability Organization (WS-I), which does not yet count Sun among its members.
Above and beyond protocol squabbling, a software design principle that's been around for a while in various incarnations, Design by Contract (DbC), offers a unique perspective on what kind of design "methodology" to apply to Web services and how to best specify the components that make up Web services. (DbC was pioneered by Bertrand Meyer, creator of the Eiffel language; see Meyer's book, Object-Oriented Software Construction, Second Edition, Prentice Hall, 1997 for a more complete description of DbC.) By associating a specification with core Web service elements, DbC gives developers the ability at the design phase of development to reduce conceptual flaws and promote a better understanding of work scope, something that will be especially important in coming years as the Web service environment becomes more and more dynamic.
At their most generic, Web services are business processes that can be discovered and run over the Internet using agreed-upon standards such as XML and SOAP. As all but the most uninformed (and possibly unwashed) already know, SOAP currently stands for the Simple Object Access Protocol. I say 'currently' because there is movement underfoot in the Microsoft camp to redefine the SOAP acronym as the "Service Oriented Architecture Protocol" as a way to give more respect to the underlying Service Oriented Architecture (SOA).
This proposal is part of a dawning recognition on the part of methodologists such as Clemens Szyperski of Microsoft Research that Web services are a movement away from object-oriented architectures. Szyperski, the author of a highly respected book on component development Component Software: Beyond Object-Oriented Programming (Addison-Wesley, 1998), acknowledged as much in a recent article, "Components and Web Service," when he defined Web services as components paired with 'service provider' operators.
Szyperski's insight is in line with the perspective of the average developer, for whom Web services represent a fairly straightforward extension to existing component models, such as Sun's Enterprise JavaBean (EJB) specification or Microsoft's Component Object Model (COM). The key element in the new SOA is the universally supported transfer syntax defined by XML where invoking a Web service normally means sending an XML document to a designated URL endpoint and receiving another XML document back from that URL.
For any given Web service, the XML transfer document needs to be able to document what messages the Web service accepts and generates—that is, to document the Web service contract (in the Design by Contract sense). WSDL fills that role: it is an XML-based contract language jointly developed by Microsoft and IBM with the goal of making it easier for developers and developer tools to create and interpret contracts. While WSDL is the rapidly emerging standard, over the past several years Microsoft and IBM have proposed many different contract languages: SDL (Service Description Language), SCL (Service Contract Language), and Network Accessible Services Specification Language (NASSL). All these are superceded by WSDL. The Web services contract written using WSDL is an XML document that contains both an abstract definition of the service and how the service binds to a particular network implementation and data format bindings.
However, it's the structure of this XML transfer document that is causing the most fur to fly in the messaging catfight between Sun and Microsoft. While it's true that a Java API for WSDL (JWSDL) specification is currently in the works (as part of the Java Community Process) and the current version of the Forte for Java IDE automatically generates descriptive Web services documents in WSDL format, Sun's position on WSDL appears to be recalcitrant, at best. It's Microsoft and IBM who are currently leading the effort to get the WS-I to rubber stamp WSDL as the default XML-based contract language.
Introduction
Design by Contract in UML
