A number of people are championing Contract-First Development within SOA.
For example, Aaron Skonnard of Pluralsight. In a number of recent blog postings on the topic, he reports a sympathetic hearing from Microsoft personnel (Bill Gibson, Simon Guest) and asserts support from Microsoft products (BizTalk Server). [August 27, 2004] [November 11, 2004] [November 11, 2004 (again)] [November 30, 2004]
But I am concerned that some people are basing Contract-First Development on a narrow notion of Service Contract - for example, equivalent to the signature of a service, expressed in WSDL. Sometimes people talk about Schema-First Development, which indicates a concern for semantics as well as syntax. But I don't think this goes far enough.
I previously expressed my preference for the term Design-by-Contract, since this term is strongly associated with a broader notion of Contract including preconditions and postconditions. Even traditional Design-by-Contract doesn't include some of the non-functional obligations expressed in a service contract, such as Service Level Agreements, Security Policy and Commercial Terms, which are essential for distributed computing and SOA. We have used the term Distributed Design-by-Contract to emphasise a broader concern for all these dimensions of a service contract.
Actually, I don't really mind which term we use, provided that we can assume the broadest meaning for the term Service Contract.
Showing posts with label DesignByContract. Show all posts
Showing posts with label DesignByContract. Show all posts
Friday, December 31, 2004
Wednesday, September 01, 2004
BPEL
At CBDI, we are generally supportive of BPEL. However, we do not see it as a complete solution to business collaboration. We have raised a number of issues over the past two years.
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. One of our concerns about the web service stack (including BPEL) is that it lacks proper support for contracts and assertions. We proposed that service contract should be a first-class construct, and we have yet to be convinced otherwise. We look forward to seeing what emerges from WS-Choreography.
Secondly, we think the ideal of distribution or federation remains some way off. For example, while WS-Transaction supports distribution, BPEL assumes that the process management is hosted on a single engine, although there have been hints that a future version of BPEL will support distributed process management. In the meantime, some people are experimenting with alternative approaches to distributed process management, such as OGSA.
Thirdly, there appears to be a widespread assumption that the orchestration or choreography is established at design time, with only minor modifications (such as the introduction of new, interchangeable partners) at run time. In time we should progress to real time orchestration.
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. One of our concerns about the web service stack (including BPEL) is that it lacks proper support for contracts and assertions. We proposed that service contract should be a first-class construct, and we have yet to be convinced otherwise. We look forward to seeing what emerges from WS-Choreography.
Secondly, we think the ideal of distribution or federation remains some way off. For example, while WS-Transaction supports distribution, BPEL assumes that the process management is hosted on a single engine, although there have been hints that a future version of BPEL will support distributed process management. In the meantime, some people are experimenting with alternative approaches to distributed process management, such as OGSA.
See for example Grid Web Services and Application Factories (pdf)
Thirdly, there appears to be a widespread assumption that the orchestration or choreography is established at design time, with only minor modifications (such as the introduction of new, interchangeable partners) at run time. In time we should progress to real time orchestration.
See CBDI Newswire 22nd May 2003 and 28th May 2003 (free access).
See CBDI Reports From Web Services to Web Collaborations (Nov 2002).
See CBDI Reports From Web Services to Web Collaborations (Nov 2002).
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.
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 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.
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.
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).
CBDI materials are currently unavailable.
Related posts BPEL (September 2004), Contract First (December 2004)
Subscribe to:
Posts (Atom)