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.
>

Received on Tuesday, 25 March 2003 15:20:06 UTC