Frank Michael Kraft's Blog

When Web Service Components interact with each other, it is important to establish a reliable contract between them. Often the Contract is only defined on a syntactical level, i.e. the signature of the web services that each component offers. The paper (1) discusses, that additionally a behavioral contract is needed. It proposes even more contract levels: the synchronization level and the Quality-of-service level. But let us first discuss the behavioral contract. Some citations from the paper.

When using a third-party component, contracts offer a specification against which you can validate that component. (1)

This is in line with my earlier proposal that this could be covered by what I call a Composite Integrated Development Environment.

Now for web service signatures, this is state of the art.

Unfortunately, because the BankAccount specification does not define precisely the effect of operation executions, the user can only guess at their outcomes. (1)

That is the problem. How is the behavioral contract specified?

The client should only call a contractor routine in a state where the class invariant and the precondition of the routine are respected. In return, the contractor promises that when the routine returns, the work specified in the postcondition will be done, and the class invariant will be respected. (1)

This means, that a behavioral contract should be specified in terms of preconditions of a web service and postconditions of it. In this case a composite IDE can validate models of services consumption against models of service provisioning.

In BPMN 2.0 the abstract process is a possible way to achieve this goal. It defines which behavioral contract the participant offers and under which preconditions (process state) a service can be called. In the same way in (2) the desynchronized choreographies can be seen as such. However in (2) the modeling process is top-down. In practice it could also be bottom-up. Especially if there are existing components with an implemented behavior which is modeled after the fact to allow for contract awareness.

Bibliography

1. Beugnard, Antoine, et al. Making Components Contract Aware. Computer. 1999, Vol. 32, 7, pp. 38 – 45. http://portal.acm.org/citation.cfm?id=621275.
2. Lecture Notes in Computer Science: Non-desynchronizable Service Choreographies. Decker, Gero and Alistair Barros, Frank Michael Kraft and Niels Lohmann. Berlin / Heidelberg : Springer, 2008. Service-Oriented Computing – ICSOC 2008. Vol. 5364/2008, pp. 331-346. http://www.springerlink.com/content/9055736715131767/. ISSN 0302-9743 (Print) 1611-3349 (Online).

[ad]

First, what is a Choreography Model? Spoken in general terms it does model the participants of a message exchange, the messages exchanged (not necessarily the structure of the message), which interactions (message exchanges) are desiged betreen the participants, who is the initiator of an interaction, and which interactions follow on which other interactions.

The benefits of modeling a Choreography are the general benefits of doing a design for anything. It gives transparency. It results in quality, because of clear-cut statements of the boundary conditions, if fosters collaboration by forcing to discuss the message exchange contract. It can be simulated and thereby problems can be found before implementation and the consistency can be checked with other models – especially process models of the participants.

Sending messages at unspecified points in time between participants and hoping, that they will somehow be processed may seem easier in the beginning, but experience shows, that this does not pay back. Error handling is especially difficult in distributed SOA landscapes. Therefore giving the interaction a backbond and skeleton by modeling it in the first place, is key to success.

This model could even be used in the runtime by letting systems validate messages that arrive or are being sent against the model. By this two things happen: (1) The quality of the model is forced to be on the highest level (in contrast to “just a drawing”) and (2) messages sent or received at the wrong time can be identified as contract violations (instead of clumsy debugging of the application coding).

[ad]
A SOA consists of Process Components, each of which fulfil a certain business functionality, that interact with each other. One possibility is that a Composite Application does call Services of an underlying Business Process Platform – be it synchronously or asynchronously. Another possibility is, that Process Components of an unterlying Business Process Platform communicate with each other by mainly asynchronous web services. Examples for the first were mentioned above while examples for the second could be a Process Component for Supplier Relationship Management including Purchasing and a Process Component for handling the Delivery, that exchange asynconous XML messages with each other. Another example is the message exchange between a seller and a buyer.
The modeling of a choreography can adress both purposes. It does focus on the exchange of the messages alone – i.e. internal details of the process components are not modeled in such a model.
However it can server as a Top-Down Design methodology – if new Process Components will need to be designed, or – it can serve as a contract between two communication participants, that are adapted to the message exchange.