RE: Multi-Party Binding Scenario

Jon

What you think is unusual is actually very common and here's the use case
...

The content of an order document, say, will vary depending on such things
as: the industry in which the choreography is being used and country in
which the order is being placed. For example in the shoe industry you might
want sex, shoe size and color as elements in a line item. On the other hand,
in the travel industry you would not and might want flight segment
information instead. In Europe you need to include VAT tax information (e.g.
registered VAT number) but in the US you would not.

If you then work out the number of *necessary* permutations, there will
eventually be 1000s of *different* order definitions each with their own
namespace. Note however that the UBL initiative [1] has got this problem
taped and is developing a practical solution to solving it.

Now, if each Choreography definition is tied, through an XPATH to a specific
element in a document with a specific document definition (i.e. namespace),
you will end up defining 1000s of choreographies which, from the perspective
of message sequence, are identical. This approach simply will not scale.

This is why separating the abstract choreography from its binding to a
specific implmentation is *very* important.

David


[1] See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl, or
for an article on UBL that covers this problem see
http://www.eaijournal.com/Article.asp?ArticleID=633


-----Original Message-----
From: Jon Dart [mailto:jdart@tibco.com]
Sent: Tuesday, March 25, 2003 12:19 PM
To: Assaf Arkin
Cc: Burdett David; 'Ricky Ho'; public-ws-chor@w3.org
Subject: Re: Multi-Party Binding Scenario



I can't really see splitting out all the Xpath expressions into a 
separate binding - if I define a flow that's intended for order 
processing, then I probably care what the format of an order is, and IMO 
it is ok for me to rely on that format even in the "external" view of 
the choreography.

I guess one case where you'd want to do something like this would be a 
system that wanted to be able to say something like "I take purchase 
orders, and you can use ebXML format or SOAP format". So you could use 
the same flow with multiple data formats. I think this is a possible use 
case but IMO it is a bit unusual.

OTOH, Assaf's point is interesting - if you do have expressions based on 
message contents, they shouldn't really operate on "raw" message data, 
but data that has been normalized -- otherwise you tie your choreography 
definition too closely a particular protocol. This might make sense, but 
there are limits to this approach. E.g. what about EDI? Or even SOAP 
with Attachments? If you want to able to handle truly arbitrary message 
content, then you can't rely on XML, or XPath.

(I don't have an answer to this. I think assuming XML data is fine in a 
lot of cases. If it's not fine then you might have to define a "black 
box" for content-based routing, so that the external process knows you 
might take one or another path, but the logic isn't specified publicly. 
I think there was some discussion of this kind of model at the F2F).

-Jon


Assaf Arkin wrote:
> 
>>
>>
>>
>> If you include a specific XPATH expression in a choreography, then the
>> choreography definition is no longer abstract and therefore cannot be 
>> reused
>> which means it does not scale. I think the binding implied by the XPATH
>> expression should be recorded in a Choreography Binding document that 
>> binds
>> an abstract Choreography Definition to the specific, services, messages,
>> documents, used by a specific implementation.
>>
> 
> I disagree. The choreography should talk about an abstract message. 
> Content without specific headers. No protocol binings. Not a "SOAP 
> message" but an abstract message without enveloping.
>