- From: Steve Ross-Talbot <steve@enigmatec.net>
- Date: Tue, 25 Nov 2003 20:28:10 +0000
- To: public-sws-ig@w3.org
- Cc: Jack Berkowitz <jack.berkowitz@networkinference.com>
- Message-Id: <E2E0A3A0-1F85-11D8-8EC5-000393AD2AA6@enigmatec.net>
Jack, can you read it this time? Cheers Steve T Begin forwarded message: > From: Steve Ross-Talbot <steve@enigmatec.net> > Date: Tue Nov 25, 2003 6:39:51 pm Europe/London > To: public-sws-ig@w3.org > Subject: Semantics and choreography > > These is my own thoughts submitted to the Choreography working group. > > We are interested in feedback, suggestions and the like so that we can: > > 1. Better understand the issues > 2. Capture realistic requirements > 3. Work with other groups to achieve 1 and 2 > > I would appreciate a reply cc'd to > public-ws-chor@w3.org > > > Cheers > > Steve T > co-chair W3C Web Services Choreography > > ----------------------------------------------------------------------- > ----------------------------- > > What can semantics be used for in a choreography description language? > > To explore this question we need to define a few basic concepts and > terms. > > I make the distinction between locating a service and a choreography. > A service is a Web Service > that exhibits a WSDL interface. A choreography is not a Web Service > but a contract between two or more > services. > > In order for a service to be part of a choreography it must agree to > abide by the contract and so exhibit the > required external observable behaviour. > > Choreographies are non-executable descriptions of observable > behaviour. They are loosely bound to the > services that they describe which allows services to join and leave a > choreography dynamically. A description > of a choreography fully elaborates the externally observable message > exchanges between a collection of > services. > > Consider a service P that sends a message to service Q and waits for a > response while Q sends a message > to service R and then continues doing something else but is now able > to receive a response from R asynchronously, > which is required for Q to respond to P. This is exactly the > observable behaviour that a CDL should describe. It includesl > all of the dependencies that are externally visible. In this case the > response from R back to Q is a dependency for > P. So a CDL will describe the visible "interactions" that occur and > their visible dependencies. > > A choreography may include certain system level interaction that are > also externally observable. To a large extent > the external observable behaviour as at the level of a business model > as opposed to a system model [aka MDA]. > System model behaviour that is observable might be said to be > transaction boundaries in either a conventional ACID based > approaches or long running transactions of some flavour. System model > behaviour might include any observable exceptions > that are propagated by the participant services. > > Service location/selection > Semantics in a CDL are most likely to be used in support of a query > that may be used to dynamically locate a choreography by a Web > Service. > This is akin to a conversation (that may be in play already) in which > someone enters a room listens for a while and decides they wish to > participate > or not - in which case they might move to another room and listen in > on another conversation and so on. The sort of thing we do at parties. > > This sort of conversation surfing that we do at parties is a good > analogy for the way in which web services might come together to > accomplish > some user-driven goal. They also surf for conversations that we call > choreography descriptions. They evaluate the conversation, not by > listening, > but by engaging in a short chat to identify if the conversation makes > sense for them (i.e. do they understand it at all), that they are not > going to get into trouble by entering (i.e. It all sounds too > political for me to enter into this conversation) or that they do > understand, feel comfortable with but decide that one of the > individuals they don't like and so move on. > > For a Web Service it might look more like the following: > > I am a Web Service called P. > I would like to participate in a choreography to sell paint? (do I > understand what they are talking about) > I would like to participate in a choreography to sell paint such that > the choreography is lockfree? (am I comfortable) > I would like to participate in a choreography to sell paint such that > the choreography supports a > role called "paint mixer"? (do I have a way into this conversation) > I would like to participate in a choreography to sell paint such that > the choreography supports the an exchange > between a paint broker role and a paint shipper role where the broker > and shipper never directly communicate > to me as a supplier? (I'll only join in if I don't have to talk to > ...) > I would like to participate in a choreography to sell paint such that > the choreography supports a transaction model > that is the same as mine? (can I steer it into my comfort zone) > I would like to participate in a choreography to sell paint such that > the choreography but I need to be sure that it understands > the concept of "deferred payment"? (I understand the overall > conversation but I never heard of that word before) > > The bracketed part at the end of each query tries to re-phrase what is > being asked in party terms. > > To be able to support such queries requires that a choreography makes > visible the semantics of liveness, roles and allows information about > roles and behaviour to be inferred. > > The query about transaction models might require the use of clear > separation into system and conceptual artifacts of a choreography. It > might also require some form of behavioural equivalence such a > bi-simulation over all of part of the choreography description. > > The last query, about deferred payment, might be a combination of > behavioural equivalence and some form of ontology matching. The > ontology matching might be used to find an equivalence relationship > between "deferred payment" and "late payment". > > I am not claiming that we can achieve all of this. What I am trying to > do is put some meat on what semantics might mean to a choreography > description language. I do like the idea of Web Services locating a > choroegraphies with which they can be shown to be compatible and then > joining those choreographies in the right way. > > To do the inferencing example we would be well served if we utilised > RDF or something similar. The use of concept matching, "deferred > payment" vs "late payment", would probably necessitate the use of > ontologies (and so OWL or OWL-light) to express the ontologies and the > choreography would make some reference to the ontology that it uses > which could then enrich the choreography description with the > appropriate concepts. > > Summary > So to summarise I think that there are two areas in which semantics > play a role in choreography. Firstly to locate a choreography and > check it matches the requirements of a requesting Web Service. > Secondly to reuse ontologies and the concepts that they describe as > terms in a choreography description linking the description to the > choreography. > > Phew! That is as much as I can write on this topic without making it > totally unreadable, which it probably is anyway. > > Cheers > > Steve T > > p.s. As a small anecdote on the importance of semantics and how easy > it is to get it wrong: > > My father worked for the GEC in the UK for many years. He was > responsible for QA (both hardware and software). He told me at the > weekend > that he has asked his PA to draft a letter to be sent to some > sub-contracting company that GEC were using at that time. In dictation > he said > something like: > > "I would like to see your QA procedures so that I can assess the > effectiveness of your QA system." > > Alas in production the letter sent turned out to be: > > "I would like to see your QA procedures so that I can assess the > effectivemess of your QA system." > > As you can see even a single letter can change the meaning of things.
Attachments
- text/enriched attachment: stored
- text/ignore attachment: SecurityCheck.txt
Received on Tuesday, 25 November 2003 15:28:38 UTC