by Roger Smith

By associating a specification with core Web service elements, Design by Contract 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.

Web 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 thousand and one 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.

DbC is widely acknowledged to be a powerful technique for writing reusable and interoperable software. The three key elements of DbC–preconditions, post-conditions, and class invariants-are supported directly at the language level in Eiffel* and Eiffel#* (the 'managed code' version of Eiffel that runs on Microsoft's .NET* platform).

Although Java* and C++ do not yet directly support DbC, there are a raft of third-party tools that extend DbC support to these languages (including iContract*, Parasoft's* Jcontract* for Java, and GNU Nana for C/C++*.

Not surprisingly, it's also possible to model DbC in the Unified Modeling Language v. 1.1 using OCL (Object Constraint Language), a declarative language subset of UML. In their book The Object Constraint Language: Precise Modeling With UML (Addison-Wesley Object Technology Series*), authors Jos Warmer and Anneke Kleppe show in great detail how OCL can be used to model invariants (to apply conditions to classes) and pre- and post-conditions (to constrain the operations of a class). Likewise, Craig Larman in Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (Prentice Hall*: 2nd edition 2001) discusses the use of OCL for Design by Contract. The 'system contract' DbC approach advoca ted by Larman is a variant on the Warmer and Kleppe UML/OCL DbC approach, since Larman thinks OCL might be overkill for most projects because of the added complexity of including textual OCL documents as addendum to UML diagrams. (See the sidebar "The Dying Days of DISCO" for information on another simple modeling approach, Object Role Modeling.)

Larman's UML 'system contract' DbC approach suggests a way to model Web services as components in a Service Oriented Architecture, while at the same time abstracting the emerging Microsoft/IBM WSDL contract language via Use Cases containing pre- and post-conditions (see an example of a "Use Case for a Web Service Stock Buy Order"). Converted to XML and embedded in XML transfer documents, it's conceivable that Use Cases containing pre- and post-conditions could move the Web service Design by Contract concept a little higher up the abstraction food chain, away from XML messaging languages such as WSDL. Because Design by Contract is a proven technique for reducing conceptual flaws and promoting a better understanding of work scope, it makes the most sense that the contract in DbC should be specified in the design phase of development. In the case of self-contained, modular Web service applications, it is even more important to have documented artifacts that your development team can refer to throughout the development lifecycle. Figure 1 shows a conceptual Web services architecture modeled as UML Component Diagrams.



Figure 1. A Conceptual Architecture for Web Services Modeled in UML with Component Diagrams

In this model, each Web service is modeled as a software component or a building block that together will make up a distributed application or assembly of business processes. Each component is made 'self-describing' by embedding a Use Case in the XML transfer document. To ensure interoperability, the XML Web service 'wrapper' around the Use Case must be able to accept requests to perform a specific set of tasks and respond to such a request using agreed-upon open messaging standards.

In the above diagram, the service provider component provides a service interface for a software asset that manages a specific set of tasks. The service provider component can represent the services of a business entity or it can just represent the service interface for a reusable subsystem (for example, a legacy COBOL billing subsystem).

The service requestor component in Figure 1 discovers and invokes other software services to provide a business solution, a new and different unit of business functionality, something for which a business can charge money. Because a Web service may be an aggregate of other Web services, the requestor can communicate with provider components that may reside locally within an intranet or remotely over the Internet.

The third SOA component, the service broker; acts as a repository, clearing house or yellow pages for software interfaces that are published by service provider components in this model.

As Scott Ambler points out in his "style guide to UML modelin g", Component diagrams (along with Activity diagrams) are arguably one of the "forgotten" UML diagrams, because most methodologists seem to want to relegate them to low-level design diagrams for specifying software configuration. With the move to Web services and the increasing need to model the logical architecture of a distributed business/domain infrastructure, this once forgotten UML diagram is likely to be rediscovered.

Roger Smith is former technical editor of Software Development* magazine and has been a developer for 15 years. He recently moderated a panel on the status of the UML at UML World* in New York City.