Re: Progressive Concreteness of Choreography binding

>
> I am talking about define an "abstract" complex type that fulfill the 
> 2 constraints that I specify here while NOT be able to allow various 
> very different over-the-wire format be able to map to it.


Can you give me a specific example. The one you gave is easily and 
efficiently solvable using XSL/T or even XQuery. Is there something you 
can't solve using existing technologies to require the additional layer?

> The XSL/T here is equivalent to my separated "Implementation 
> Binding".  I agree that the XSL/T can transform ANY message format to 
> our required abstract message.  In this case, the value of the extra 
> level of indirection is to provide more precise mapping information so 
> that you don't need to handcode the XSL/T.

If the XSL/T is used to transform the message from its abstract format 
to the implementation format, that's an implementation issue that is not 
important for anyone to know.

If the XSL/T is used to transform the message from its abstract format 
to the over-the-wire format, that's a protocol binding issue, so it 
belongs in the protocol layer.

Since you want to express the choreography in abstract term, you don't 
want to depend on a particular encoding. So you want to express 
properties in terms of the abstract message. Since you can transform 
from over-the-wire/implementation to abstract you can determine these 
values after transformation. So I don't see what the level of 
indirection would buy you.

If anything, it won't allow you to use the choreography. If I use n 
services all of which support the same abstract format but insist on 
using some other format internally, I have to understand all these 
various implementation schemas. That's not useful. And if it's all about 
understanding these schemas in terms of abstract messages (because 
transformations are given), can't we just express everything in terms of 
abstract message to begin with?


>>> 2) Somewhere in this "PurchaseOrder" message will contain a 
>>> "totalAmount" which is type "float"
>>> - Again, I don't want to constraint the element name of this 
>>> "totalAmount".
>>> - In fact, it doesn't even have to be an element.  It can be an 
>>> attribute.
>>
>>
>> Or something you can calculate e.g. by multiplying quantity by price 
>> and then summing it up.
>
>
> Exactly.  So how can I specify whether the XPATH should be 
> "//totalAmount" or "//*/@totalAmount" or "sum(//LineItem/@subtotal)"

Look at the abstract message definition. Whatever you send over the wire 
or handle in the back-end is an expression of the abstract message. And 
you can transform from one to the other. So instead of looking at all 
the possible n results of the transformation, just look at the abstract 
message that is common to all these representations. And write the 
expression based on that abstract. The abstract will tell you whether to 
use "//totalAmount" or "//*/@totalAmount" and that will work correctly 
in all cases.

> Are you referring to the on-the-wire message inter-operability ?  We 
> don't get this at the choreography level in either my approach or your 
> approach.  In my approach, the on-the-wire message inter-operability 
> is provided at the "implementation binding" layer, while in your 
> approach inter-operability comes from XSL/T transformation.  So the 
> inter-operability issue is addressed anyway, just outside the flow 
> (ie: Abstract Process) itself.

In my approach over-the-write inter-operability comes from the protocol 
binding. They may be very simple, they may be very complex. They may use 
XSL/T, or a more complex language, or a simpler language, or some 
semantic mapping. But the important thing is, it has no effect on the 
choreography, only on the messaging layer that needs to support a 
particular protocol. And it's protocol dependent, not implementation 
dependent.

So, if you have n protocols (a small number, do we agree?) and m 
services (unlimited) and one abstract message, then:

- You need to write all expressions exactly once (one abstract message)
- You need to write only n protocol bindings (exactly n protocols)
- You can use m services

n can be something like four (SOAP, EDI, ebXML, RN), while m can be 
something like a million.

Think of the alternative: trying to handle a million services because 
each service insists on a different way to encode the information.

arkin

>
> I'm not seeing how xsd:anyType express the message need to have a 
> "shippingAddress" and a "totalAmount" data somewhere.  I think my 
> approach is trying to avoid writing an XPATH because an XPATH always 
> assume certain message structure regardless of how "abstract" it is.  
> But I agree that the XSL/T transformation you suggest will work, just 
> pushing the mapping responsibility to the XSL/T layer.
>
> Ricky



-- 
"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 Thursday, 3 April 2003 13:58:38 UTC