RE: Semantics and choreographies

Steve

Although I can see the benefit of your ideas on semantics, I also think
there is a much more prosaic requriement. Where:
1. Businesses want to integrate with their partners by building links so
that they can exchange business documents
2. The links will only be set up if there is some pre-existing business
arrangement between them that decides, in principle that they will "do
business"
3. The analysts at each business who are going to do the integration need to
understand exactly how they should respond to each message building a
"private" business process to support it, or alternatively, identifying a
business process that already exists that works.
4. They want a common or global definition (i.e. the choreography) of how
they will interact with each other so that they can independently build
their own business processes with the confidence that they will then be able
to interoperate.
5. The Choreography definition they use, must have sufficient explanation in
a form (e.g. english) that the analysts involved can understand so that they
can do the work successfully.

Thoughts?

Also see comment in line about Ps and Qs and Rs ...

David

-----Original Message-----
From: Steve Ross-Talbot [mailto:steve@enigmatec.net]
Sent: Tuesday, November 25, 2003 6:06 AM
To: public-ws-chor@w3.org
Subject: Semantics and choreographies



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.

<DB>
I'm just wondering. Does this *need* to be one choreography. In a diagram,
what you are saying is the following (I think) ...

P            Q             R
msg1 ------> 
(waits)
             msg 2 ------>
             (does something)
             ...
                  <------ msg 3
    <------ msg 4
(continues)

My question is why does P need to know anything that goes on between Q and
R? More specifically, would P's behavior or processing change in any way if
the messages between Q and R were done differently, e.g. with Q waiting for
R to respond.

Although these can be defined in one Choreography, would it be a "better
design" if they were defined as two as then if Q and R wanted to change
their choreography, then the choreography between P and Q would not need to
change. Thoughts?

On the other hand, the following would have to be defined in one
choreography ...

P            Q             R
msg1 ------> 
(waits)
             msg 2 ------>
             (does something)
             ...
                  <------ msg 3
    <-------------------- msg 4
(continues)
... as P needs to be aware of R, unless, of course R was pretending to be Q
;)
</DB>

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.

This email is confidential and may be protected by legal privilege. If you
are not the intended recipient,  please do not copy or disclose its content
but  delete the email and contact the sender immediately. Whilst we run
antivirus software on all internet emails we are not liable for any loss or
damage. The recipient is advised to run their own antivirus software.