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 13:58:04 UTC