Scope of Choreography [was Uses of the WS Choreography Spec]

I believe the concerns about variation in message content and meaning can
be addressed by a clear definition of scope of the choreography
specification.
The mechanisms of transport and reliable delivery should be abstracted out
of the choreography, as should the message envelope/packaging.  Furthermore,
the determinination of the validity and meaning of a message should be 
performed by the participant's internal business logic/process that is also 
abstracted out of the choreography specification.  Let me explain.
 
Each participant has a public state where possible states and state
transitions
are defined in the choreography.  The public state only changes as a result
of
the receipt or sending of a message.
 
When a participant sends a message, it's public state is changed to a state 
that reflects the possible responses expected.  When a response is received,
the message content is not determined within the scope of the choreography
specification, but is delegated to the internal process/application to which
the response is directed.  The only immediate change to the public state
may be to reflect that the internal process is busy processing the input.
When
the internal process determines the validity and meaning of the input, it 
formulates an appropriate response (as constrained by the valid state
transitions
from the current public state), it sends the response and it causes the
public
state to change accordingly.
 
Consequently, while the public states and state transitions, and message 
semantics are referenced by the choreography, the interpretation of the
message
content and the determination of the corresponding public state transition
are accomplised within the internal process/application, and need not be
specified in the choreography.
 
It may be useful to indicate the "normal" state transitions expected for
each
message input or output in order to focus on the performance of the
exchange,
but the choreography should express all valid exchanges where the messages
are expected to be meaningful, whether or not they represent a successful
business transaction.
 
Where faults occur in the communication, these must be communicated to
the internal applications for subsequent action. The choreography should be
able to express possible continuation (e.g., retry, re-connect) of the
exchange
in spite of faults or delays.  A time-out would be similar to the receipt of
a bad
message.  It is probably useful to specify the time-out period in the 
choreography so there is an understanding of how long a participant will
wait
for a response.  A time-out might be treated differently from a bad message,
but the determination of the resulting public state transition should
probably still be
delegated to the internal process/application.
 
So it doesn't matter to the choreography how the message is communicated
nor how it is packaged or formatted.  The choreography only deals with the
semantics of the message (i.e., the business intent of the message, such 
as new order, acknowledgement, rejection, counter-offer) and the possible 
state transitions that will be selected by the internal process/application.
 
Fred Cummins
EDS

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Thursday, March 20, 2003 1:48 PM
To: 'Yoko SEKI '; 'public-ws-chor@w3.org '
Subject: RE: Uses of the WS Choreography Spec



Yoko 

You raise a good point. But it is a problem that can be solved by defining,
in an abstract way: a condition, its semantic meaning and what to do when
the condition is satisfied; and then binding the abstract definition to a
specific instance.

Here's a very simple use case. In this choreography a company that is
generating an inovice needs to examine the country codes in the invoice and,
depending on whether the countries are in the US or a country in Europe send
the Invoice to a "US tax calculation service" or a "EU tax calculation
service".

Note that this is just an example of the principles of how to separate the
abstract from the concrete would work rather than a definitive suggestion of
what is requried.

ABSTRACT DEFINITION 
The first step would be to define the condition, messsage and roles
abstractly (the words between asterisks), for example ...

If Condition is *USInvoice* then 
  Send *Invoice* message from "Invoice generating role" to *US Tax
Calculation Role* 
If Condition is *EUInvoice* then 
  Send *Invoice* message from "Invoice generating role" to *EU Tax
Calculation Role* 

Note, I am deliberatly not proposing a specific syntax. 

SEMANTIC DEFINITIONS 
As each of the items inside asterisks are abstract definitions they need to
have a semantic definition associated with them, for example:

1. The semantic definition for a *USInvoice* could be "An Invoice where the
services provided by and the normal place of business of the business that
is generating the Invoice, and the normal place of business that is to pay
the Invoice are both within the United States".

2. The semantic definition for an *Invoice* is "A document that requests
payment by one business for services provided by another".

3. The semantic definition for a *US Tax Calculation Role* is "The role that
provides a service to calculate the tax dues on US Invoices".

I'm (slightly) laboring the point that abstract definitions are in English
(or French, or ...) rather than any technical definition and that they must
be clear and umambiguous. This is necessary so that the someone who has
never seen the choreorgraphy definition before can take it and bind it to an
instance with confidence.

CHOREOGRAPHY BINDING 
The next step is to bind the semantic definitions to technology that
implements them, for example: 
1. *USInvoice* could be mapped to an xPath expression that returns whether
or not an Invoice is a US Invoice 
2. *US Tax Calculation Role* could be mapped to a specific service instance
defined in WSDL somewhere that is to be called by the implementation.

3. *Invoice* could be mapped to a message structure, for example, a UBL
Invoice with a specific namespace wrapped in DIME with optional attachments
that is part of a WSDL Service definition.

Now this particular choreography is perhaps a bit simple and could be
implemented in a different way, but there are many choreographies that need
to be standardized, especially for B2B, where this type of approach is
really necessary, if there are to be a finite number of choreography
definitions.

Hope this helps. 

David 


-----Original Message----- 
From: Yoko SEKI 
To: public-ws-chor@w3.org 
Sent: 3/20/2003 1:16 AM 
Subject: Re: Uses of the WS Choreography Spec 



Hi, 

> "Burdett, David" wrote: 

> 1. Detailed message format independence. Business documents 
> necessarily vary in their structure, for eaxmple: a) Invoices in the 
> US include sales tax whereas in Europe they contain VAT, or b) line 
> items on travel related invoice could contain flight segment 
> information. This means that the choreography defintion should be 
> independent of any specific document format. 

As you says, message format can vary. 
I hit on another problem. 
I wonder what to do if we need to use the value of the tax variable to 
contorol the flow in orchestration. 
We may have to refer the VAT value as tax value... 

I think we need a concept of semantics to correspond these variables. 
--- 
Yoko Seki 
Hitachi, Ltd. 
mail-to:y-seki@sdl.hitachi.co.jp 
tel:+81-44-966-9111(ext:3219)