Contract First development isnt new. But it's a good starting point for service-oriented architects.
Why? Because SOA creates interdependence along with reuse--so having clear expectations (contracts) that define expectations is essential.
Contracts describes the expectations between a service provider and service consumer. In the case of Web Services, these expectations in part are answered by the WSDL. Obviously there are a great many other expectations such as performance behavior which are not present in the WSDL. But as a starting point for development, a WSDL provides a clear way to set expectations.
In order to enrich the default form of "Contract" for Web Services, the Semantic Annotations for WSDL working group at the W3C recently announced the First Public Working Draft of Semantic Annotations for WSDL. According to the draft document:
Semantic annotations are references from an element within a WSDL or XML Schema document to a concept in an ontology. This specification defines annotation mechanisms for relating WSDL inputs and outputs to concepts defined in an outside ontology. Similarly, it defines how to annotate WSDL operations and how to categorize WSDL interfaces. Further, it defines an annotation mechanism for specifying the structural mapping of XML Schema types to and from an ontology. The annotation mechanism is independent of the ontology expression language and this specification requires no particular ontology language.
This specification is designed to improve the self describing nature of WSDL documents to annotate the description of elements in a WSDL. This is of particular use in data integration scenarios.
Contracts produce a completely orthogonal set of issues when applied to process integration. Steve Jones summarizes some of these thoughts for contract first development tools on his blog.
When focused on existing tooling, Mr. Jones discovers that a problem arises when you take the logical contract first development paradigm into BPEL. The problem is that the tooling currently supports multiple WSDL documents defining a "process". As he suggests "From a design, development, management, publication and versioning perspective it makes it much easier if you can have a single WSDL to describe what the service should be. Implementation languages like BPEL shouldn't be forcing us to break our service architectures because they can't cope with the idea of a service providing access to multiple capabilities."
This is primarily an issue about the level of abstraction which works best for composite service development. The original abstraction holds that one BPEL maps to one WSDL file. The proposed solution is to enable an arbitrary number of BPEL files to be represented by one WSDL. This story develops further with a positive response from the Eclipse team working on BPEL tooling.
As a set of SOA programming best practices evolves into a style, the conversation between implementers and tool builders becomes increasingly important. Tooling for BPEL and BPMN as well as emerging specifications like SCA and JBI could serve as the programming foundation for SOA in the future.
