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

+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 14:56:30 UTC