Re: Progressive Concreteness of Choreography binding

Assaf, thanks for comment.  My response embedded

At 12:00 AM 4/3/2003 -0800, Assaf Arkin wrote:
>Ricky Ho wrote:
>
>>Assaf,
>>
>>I agree with your principle.  But I just don't see how "abstract" WSDL 
>>can be.  Let me give an example.
>>
>>Lets say I define a choreography to handle PurchaseOrder message.  I 
>>don't want to constraint the message structure of this message as long as 
>>it fulfill the following ...
>>
>>1) Somewhere in this "PurchaseOrder" message will contain a 
>>"shippingAddress" which can be mapped to complex type "Address".
>>- But I don't want to constraint the element name of this 
>>"shippingAddress", (e.g. the element name can be "shipAddr", "shipTo", 
>>"sendTo" ... etc.)
>>- I also don't want to constraint such an "shippingAddress" element to 
>>have the exact complex type "Address".  The type can be anything as long 
>>as it can be transformed (via XSL/T) into type "Address"
>
>Are we talking abstract or over-the-wire?

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.


>If we're talking abstract I don't see what it brings to the table. Find 
>some common name to use, agree on that name and use it. If you're looking 
>for interoperating then you have to agree on using the same name. Whether 
>you call it shipAddress or shipTo, you have to figure out some name to 
>distinguish from billAddress or billTo.

Yes.  In fact, the "message properties" already define the name (e.g. 
PO.shippingAddress)


>If we're talking about over-the-wire, use whatever you want. Because you 
>can always XSLT transform. Let's say the abstract message uses the name 
>shippingAddress. You can XSLT transform to/from an over-the-wire message 
>that uses shipTo, sendTo, etc and places that element anywhere else in the 
>document.

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.


>So you do get:
>
>a) a declaration of what is in the message using some name everyone can 
>reference
>b) abstraction to use any number of different over-the-wire messages
>c) and you can use XSTL to transform from one to the other

I agree.  I think both approach will solve the problem.
The cost of reducing the extra level of indirection is now you shift the 
complexity in XSL/T (which do the equivalent of mapping)



>>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)"



>>Can you show me how the abstract "PurchaseOrder" described above will 
>>look like in WSDL ?
>
>PurchaseOrder of type xsd:anyType
>
>Essentially you want to create a situation where the seller may put some 
>value in shipTo and the buyer may expect to find that value under 
>shipAddr. xsd:anyType gives you that form of abstraction. Of course, it 
>doesn't give you any interoperability because buyers and sellers can't 
>really decide where to put what information. Or alternatively, you have to 
>create too many transformations so you can't just pick a buyer/seller and 
>use their service, you have to first decide on a transformation to use.
>
>So xsd:anyType is a possibilty if you want the ultimate abstraction. You 
>got that. But it also points to the limitation of ultimate abstraction as 
>a means to hinder interoperability or increase integration complexity, 
>whichever way you want to look at it.

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.

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

Received on Thursday, 3 April 2003 10:15:22 UTC