BT

Contracts, Expectations, Agreements and Processes

| by Miko Matsumura Follow 0 Followers on Jul 06, 2006. Estimated reading time: 2 minutes |

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.

 

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Problem with WSDL=Contract by miko matsumura

IMHO WSDL != contract;

One problem that arises when thinking of contracts in SOA is the binding of expectations entirely to service interfaces. Contracts in business are between service providers and service consumers. By attaching the meaning of "contract" to the service interface, we create a "one-size-fits-all" world.

More about this on my blog.

www.soacenter.com

Miko

Re: Problem with WSDL=Contract by Joost de Vries

The spec does not say anything about the semantics that are expressed. So one could limit the semantics to essential statements that are tied to the one published service and have a mediator enrich this essential service semantics with consumer specifics and publish this to the consumer in a specific WSDL.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss
BT