Design by Contract

Design by Contract was pioneered by Bertrand Meyer, who refined the assertion-based approach into the Design by Contract method and the Eiffel language. The basic idea is that a component and its clients have a contract with each other. The client guarantees certain preconditions before calling a method, the component guarantees certain postconditions after the call. If the pre- and postconditions are included in a form that the compiler can check, then any violation of the contract between caller and component can be detected immediately. The prime focus of the approach is to deliver reliable software.

Design by Contract has wide theoretical acceptance. It is an intrinsic component of the Catalysis Approach, perhaps the most influential of all component methodologies. However its usage has to date been relatively limited, the most prevalent use being in the Eiffel language.

• CBDI Report Eiffel in the .NET Environment October 2002

---

In business terms, the basis for collaboration between autonomous business entities is a service contract. This suggests a design process in which contracts are paramount - such as Design by Contract.

For distributed collaborations, a contract between provider and consumer needs to have three parts: logical, quality and commercial.

 
The logical contract specifies the function of the Service, typically using a series of logical assertions such as preconditions and postconditions. This includes both syntactic elements (signature) and semantic elements (vocabulary, meaning).

The quality contract specifies the quality of service - often given the rather dismissive label of non-functional characteristics.

The commercial contract specifies the commercial arrangements, including charging for normal operation and compensation for abnormal operation.

Design by Contract allows services to be defined and used without knowing anything about the implementation. It therefore seems ideally suited to the design of web collaborations. Design by Contract has traditionally concentrated on the logical contract, but the same principles and related design techniques can be extended to the quality contract and the commercial contract.

---

The term "web service contract" is sometimes used in the very narrow sense of the syntax/signature of the service call, as expressed in WSDL/XML. Much of the recent discussion on Contract-First Development seems to be focused on these aspects of the contract.

• For example, Simon Guest regards Contract-First Development as an alternative to Data-First Development (which he prefers).
• See also Aaron Skonnard blog on Contract-First Development (August 2004) with many comments
• Eric Newcomer (Description First, September 2004) points out that for Web services, the purpose is to share data over the network. Therefore the Schema is more correctly viewed as the contract, not the WSDL.

Design by Contract has a broader concept of contract, which explicitly includes the semantics of the service call in terms of pre/postconditions and invariants, but against a single semantic vocabulary.

Web services will be implemented in a range of formal languages and protocols. These will not only specify the syntax of the service (e.g. using WSDL/XML) but also the semantic vocabulary (e.g. using RDF or DAML-S) and the pragmatics (e.g. using BPEL). However, these languages do not yet cover the full ground of quality contracts and commercial contracts. In the short term, these aspects of the contract are likely to be covered by legal contracts and SLAs between service providers and consumers. Some vendors refer to this broader notion of contract as the Relationship Contract. Some service management tools include such characteristics within the service repository as metadata.

---

• CBDI Newswire 22nd May 2003 and 28th May 2003 (free access).
• CBDI Reports From Web Services to Web Collaborations (Nov 2002) and Modelling for SOA (Feb 2003).
• See my blog entry on BPEL (September 2004)