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 advocated by Larman is a variant on the Warmer and Kleppe UML/OCL DbC approach, because Larman thinks OCL might be overkill for most projects because of the added complexity of including textual OCL documents as addenda 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' Design by Contract 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.

Using Component Diagrams to Model Web Services
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.

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

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.