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

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

Received on Thursday, 27 March 2003 14:39:52 UTC