Re: Abstract messages [Was: Multi-Party Binding Scenario]

Assaf, I think (1) is sufficient if we push PortType inheritance in WSDL.

Rgds, Ricky

At 11:55 AM 3/27/2003 -0800, Assaf Arkin wrote:
>+1
>
>In my experience only a subset of what is contained in the message is 
>important to the choreography. So there's no need to know everything that 
>is in the message, which is helpful in terms of abstraction.
>
>And yes, being able to define the choreography in terms of properties, not 
>message parts is a better approach for a variety of reasons (including 
>anticipating same properties in different abstract messages). In fact, 
>that's the only way you can do it in WSCI, and you can do it the same way 
>in BPEL (selectors and property aliases respectively).
>
>So my preferred choice would be to express the choreography in terms of 
>properties. The express how properties map to abstract (never concrete) 
>messages using something like selectors. You only need a selector for the 
>message format you intend to support, and different systems/contexts can 
>use different message formats with different selectors, while still 
>talking about the same properties as part of the same choreography.
>
>But, there's a lot of utility in being able to express a choreography in 
>terms of WSDL abstract operations (not concrete services). It's the 
>benefit of being able to utilize not just WSDL itself, but all the other 
>specifications around it.
>
>There are two ways to do it:
>
>1.1 Write the choreography by referencing the abstract WSDL operations 
>performed by each activity. (Abstract but requires WSDL as normative spec)
>
>1.2 At run-time bind it to specific WSDL services (end-points and protocols).
>
>2.1 Write the choreography without referencing any abstract WSDL 
>operation. (More abstract, can support other languages than WSDL)
>
>2.2 At run-time bind it to specific WSDL services (end-points and 
>protocols). Cross your finger and hopes everyone would use the same 
>abstract operations as intended by the activities being performed since 
>you can't predict that up front.
>
>3.1 Write the choreography without referencing any abstract WSDL 
>operation. (More abstract, can support other languages than WSDL)
>
>3.2 Write a mapping from the choreography to WSDL operations. (Only if you 
>elect to use WSDL, you can have different mappings for other languages)
>
>3.3 At run-time bind it to specific WSDL services (end-points and protocols).
>
>I don't see 2 (2.1+2.2) as even being able to work. If I send message X 
>using operation Y, and you receive message X using operation Z, there's no 
>way we can work with each other. By just looking at the choreography I can 
>imagine that we could work together, only to be surprised it doesn't pan 
>out at run-time. So I consider that only 1 and 3 are valid options.
>
>The question is, is there any technical justification for doing 3 instead 
>of 1 because at the end of the day inspite the additional layer introduced 
>by 3 it makes our job easier?
>
>arkin
>
>
>Patil, Sanjaykumar wrote:
>
>>Shall we first identify the dependency of choreography definition on 
>>message definitions?
>>
>>Yes, messages are essential as they are the vehicles of delivering 
>>information.
>>
>>However, how much of the information embedded in a message is controlled 
>>by the choreography? I guess only a small subset and the rest of the 
>>parts of the message would be controlled by the end services producing 
>>and consuming the messages.
>>
>>Would it be fair to say that a choreography definition includes 
>>specification of a set of properties (ex. billing address, shipping 
>>address) as part of its logic. Some of the properties have relationship 
>>(direct or derived) with parts of the messages, that are defined by the 
>>end services.  And perhaps the entire task of associating the properties 
>>with the message definitions falls out of the scope for the choreography 
>>specification.
>>Of course, in order to define the association of properties with message 
>>definitions, there has to be a semantic association between the two. But 
>>wouldn't it be sufficient for the choreography to (some how?) define the 
>>semantics of the properties alone and leave the mapping of the properties 
>>to the messages out of scope. And therefore whether messages definitions 
>>are abstract or specific would not matter at all.
>>
>>Sanjay Patil
>>Distinguished Engineer
>>sanjay.patil@iona.com
>>-------------------------------------------------------
>>IONA Technologies
>>2350 Mission College Blvd. Suite 650
>>Santa Clara, CA 95054
>>Tel: (408) 350 9619
>>Fax: (408) 350 9501
>>-------------------------------------------------------
>>Making Software Work Together TM
>>
>>
>>-----Original Message-----
>>From: Assaf Arkin [mailto:arkin@intalio.com]
>>Sent: Thursday, March 27, 2003 10:57 AM
>>To: Burdett, David
>>Cc: 'jdart@tibco.com'; 'Ricky Ho'; public-ws-chor@w3.org
>>Subject: Abstract messages [Was: Multi-Party Binding Scenario]
>>
>>
>>
>>David,
>>
>>I changed the title of this threadThe issue we're discussing does have an 
>>affect on the usability of choreography, but is not specific to 
>>choreography but deal with abstract and extension of messages. It's a 
>>problem for any interface definition, stateful or stateless, that has to 
>>be reused in a large number of contexts. Obviously it becomes more of an 
>>issue for choreography which contains more building blocks than say a 
>>WSDL operation.
>>
>>There are two points I assume we agree upon:
>>
>>1. Messages need to be abstract and not specific to a given protocol.
>>
>>Specific message formats that are protocol dependent (e.g. SOAP vs EDI) 
>>are also important but should be address by the protocol binding so we 
>>can have one choreography independent of the protocol we use.
>>
>>2. Messages need to be generalized and adapted to different contexts.
>>
>>Specific message formats that are context dependent (e.g. US or Europe) 
>>are also important and there must be a way to construct such messages, 
>>but at the choreography level we get more utility if we can express it in 
>>terms of generalized messages.
>>
>>The question is, do we have a framework for achieving #1 and #2 within 
>>Web services which we can utilize when writing choreographies, or do we 
>>need to create such a framework? And if we need to create such a 
>>framework, would it be useful to use it outside the context of 
>>choreography as well (e.g. for WSDL)?
>>
>>I want to show that such a framework does exist, and how it can easily be 
>>used with the choreography to identify message parts that are generic 
>>(context independent) while allowing more specific (context dependent) 
>>formats to be used in the actual message. For this particular example I 
>>only use addresses for billing and shipping with two formats for US and UK.
>>
>>1. I define a generic type called Address which signifies an address. I 
>>know that I can forward messages to an address. It only contains the very 
>>basic information that is common to all addresses, e.g. a country name. 
>>It may even be empty, but I want to show that it can contain some minimum 
>>information. It does not anticipate all the things that an address may 
>>possibly contain.
>>
>>2. I can create any number of variants of Address. I can have USAddress 
>>as a variant that includes the state. I can have a UKAddress variant that 
>>includes the county. All of these variants extend Address, so at the 
>>abstract level I could treat them all as addressed. They both have zip 
>>codes, but different type of zip codes (digits only in US, alphanumeric 
>>in UK). The variant is typed, so I can determine what the variant 
>>contains when I actually get a message with that variant.
>>
>>3. In the abstract message I have an element called BillingAddress of 
>>type Address (US, UK, or other) and an element called ShippingAddess of 
>>type Address. For the same of this example I assume all POs always 
>>contain both billing and shipping, but not specific formats of either 
>>addresses.
>>
>>4. All invoices are sent to address form the element BillingAddress. An 
>>expression of the form 'send invoice to po/BillingAddress' says that 
>>without forcing me to determine which specific address format will be 
>>used (it works equally well for US and UK addresses), but it 
>>distinguished the billing address from the shipping address (the later 
>>would be 'po/ShippingAddress').
>>
>>5. One thing that will not work because it's context dependent is an 
>>expression of the form: ''po/BillingAddress/state", since the state 
>>element if specific to USAddress while BillingAddress is defined of type 
>>Address which does not include 'state'. Similarly 
>>"po/BillingAddress/county" will not work since 'county' is only used in 
>>UKAddress.
>>
>>Does that look like a reasonable way to achieve abstract message 
>>definitions that support different formats depending on the actual 
>>context, while allowing some things to be expressed in terms of the 
>>abstract message?
>>
>>arkin
>>
>>
>>Burdett, David wrote:
>>
>>
>>
>>>Assaf
>>>
>>>I think we are both agreeind and disagreeing ;)
>>>
>>>I agree with you about the idea of having optional information in a business
>>>document. The only reason I was pointing out the futility of relying on this
>>>is that tying ANY *widely usable* choreography *definition* to a specific
>>>document format will result in multiple choreography definitions that are
>>>*identical* apart from the fact that they use different documents. I don't
>>>think that defining the same thing multiple times is ever a good idea.
>>>
>>>The only way around this, as far as I know, is to make choreographies
>>>reference an *abstract* message definitions which, in an implementation can
>>>be bound to a specific message format or formats. For example you could have
>>>the abstract idea of an order "message family" that can represent any order,
>>>in any format. You could then express the choreography using message
>>>families instead of specific message formats.
>>>
>>>I also recognize that you need, as part of a choreography, to interrogate
>>>information in a message in order to control the flow of the choreography.
>>>However, if the message definition in the choreography is abstract, this is
>>>hard to do.
>>>
>>>One way around this is make decision in a choreography dependent on the
>>>state of the role, where the state is affected by: the sending of a message,
>>>the receiving of a message or the processing of a message. For example you
>>>could have a state value of "USInvoice" in the choreography. This could then
>>>be mapped to an XPath expression, for example, when the abstract message was
>>>bound to the specific message format.
>>>
>>>Thoughts?
>>>
>>>Additional comments inline ...
>>>
>>>David
>>>
>>>
>>>
>
>
>--
>"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, 27 March 2003 15:29:37 UTC