Re: Multi-Party Binding Scenario

Jon Dart wrote:

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

+1

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

Not at all unusual. I think that we're going to find a variety of 
protocols being used depending on how you want to get a message from A 
to B, where B may always be the same service type, but different 
services with different capabilties (synch/asynch, local/remote, high 
latency/low latency, reliable/unreliable).

Even if you do everything with SOAP you may use different transport 
mechanisms, like synchronous over HTTP, or asynchronous using a MOM, 
with a WS-TX header or a BTP header, encrypted and signed, just signed, 
in the clear (e.g. in the same network). So you need to not depend on 
any specific header that is particular to one protocol you may use. And 
that requires abstraction.


> 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 am assuming that the information you are operating on can be described 
as XML at some point and manipulated as an info set. But that does not 
include carrying other information as well.

For example, a PO message may contain a billing address and you want to 
express something about that part of the message. But it may also 
contain some binary attachment, and you have no interest in saying 
anything about it in the context of the choreography (though it may be 
interesting for an implementation). This is a case where you can use 
XPath for some part of the message but not for another. But if you don't 
care about using XPath for the other parts, then electing to use XPath 
for the first part is not an issue.

It really boils down to:

1. When would you consider using XPath and on what part of the 
information? Everything? Just specific parts?
2. Can that part of the information be expressed in abstract terms using 
XML Schema and infoset?

If the answer to #1 is "everything", then XPath is not usable. If the 
answer to #2 is "we operate on over-the-wire messages" then XPath is not 
usable as well.

arkin

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


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

Received on Tuesday, 25 March 2003 15:33:26 UTC