Re: Progressive Concreteness of Choreography binding

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?

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.

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.

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

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


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

Comments?

arkin

>
> Best regards,
> Ricky
>
>
>> Conceptually I don't see why this problem would exist. You can define 
>> abstract messages with WSDL, and you can define abstract types with 
>> XSDL and then extend them in various ways (derivation, any content, 
>> substitution, etc).  So my gut instict is that it's going to be a 
>> wild goose chase to work out a solution to a problem that does not 
>> exist. I would be more interested to see a specific use case which 
>> cannot be solved using these technologies and then try to tackle, 
>> rather then spend much time trying to work out a problem that can't 
>> be identified.
>>
>> I'm not saying WSDL and XSDL are perfect. We know there are a lot of 
>> issues with WSDL 1.1 particularly in relation to abstraction (e.g. 
>> inheritence is something that needs to be solved). The question is: 
>> are these issues that cannot possibly solved in the framework of WSDL 
>> and XSDL? Or are these things that can be solved. In the later case, 
>> should every specification that depends on WSDL/XSDL work around 
>> these limitations at the risk of further complication, or can we ask 
>> these working group to tackle specific problems we have identified.
>>
>> My personal opinion is that there is no conceptual issue that 
>> prevents WSDL from solving these problems, and further, that these 
>> problems are not specific to choreography. Abstraction is not 
>> something you care about only because you are doing choreography. 
>> Abstraction is important in a variety of other cases. So that's 
>> something the WSD working group need to address, and if we can 
>> identify a real use case we can give tham that information as an input.
>>
>> Otherwise, we're just spinning a lot of wheels and not getting any 
>> work done.
>>
>> arkin
>>
>>>
>>> Rgds, 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 03:01:34 UTC