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)