Re: Issue 0001: Use cases for Reference Properties?

On Nov 22, 2004, at 1:36 PM, paul.downey@bt.com wrote:
>
> 1) message correlation
>
> a message sent to an endpoint asynchronously. later another
> node receives one or more reply messages which need to be
> tied back to the original message for processing.
>
> This is usually resolved by the originating message sending a
> unique message identifier which is returned as one of a number
> of possible 'correlation identifiers' in subsequent messages.
>
> MOM will often provide a mechanism to dispatch correlated
> messages back to the original sender agents which may be one of
> many similar agents hiding behind a single endpoint address, or
> allow an agent to select messages from an endpoint queue
>
Note that WS-Addressing already defines a mechanism outside refps to do  
this: wsa:Messageid, wsa:RelatesTo.

>
> 2) state identification
>
> e.g. a shopping cart id. Rather than sending the whole
> message context repeatedly a state identifier is sent
> in each message which dispatches the message to an
> existing conversation established through the first
> interaction or out of band.
>
> Typically the state id resolves to a thread or process id,
> a database row id, an EJB id, a backed socket id, etc.
>
I'm not sure that this a use case for ref props rather than ref params.  
In HTTP this is often accomplished using cookies which I've heard  
compared to ref params rather than ref props. Reading further I see you  
agree.

Marc.

>
> In each use-case, the additional identification information sent
> in the message is independent of the endpoint address to which
> the message is delivered. The endpoint address often being a
> generic HTTP proxy POST to 'http://www.example.com/soapPort'
> or a message queue such as: mailto:soapMessages@example.com.
>
> I could imagine representing either of the above ids:
>
>  a) inside the endpoint URI, e.g. as query parameters
>  b) as addressing properties
>  c) as addressing parameters
>  d) using some other heavyweight state-management specification
>  e) inside the body of the message
>
> I don't like collapsing this information into the endpoint
> address (a), since i think this identification is orthogonal to
> the delivery address. i don't like (d), because i think this is
> lightweight stuff, akin to cookies, and i certainly don't like
> (e) because i want middleware to handle correlation and state
> maintenance.
>
> Reading our specification, message-correlation would appear to be
> a property and state identification a parameter.
>
> So that just leaves me deciding on the format of the identification
> information itself. TBH i'm probably just being thick, but i'm
> still very unclear of the advantages in reference properties and
> parameters being tree structured XML over a flat list of name value
> pairs, or even just a sequence of URI values.
>
> Paul
>
>
> -----Original Message-----
> From: public-ws-addressing-request@w3.org on behalf of David Booth
> Sent: Wed 17/11/2004 07:31
> To: public-ws-addressing@w3.org
> Cc:
> Subject: Issue 0001: Use cases for Reference Properties?
>
>
>
>
> What are the use cases that require Reference Properties?
>
> If the WG is contemplating a feature that runs counter to the Web
> Architecture, then I would think it would be critical to back it up  
> with
> solid use cases that the WG agrees are important.
>
> On the other hand, if people cannot agree on the use cases that require
> Reference Properties, this may be symptomatic of a different problem
> *masquerading* as the need for Reference Properties.
>
> I would like very much to see the use cases that require Reference
> Properties.  Can anyone supply pointers?
>
> BTW, Tom Rutt also asked for them (though less pointedly):
> http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/ 
> 0373.html
>
> --
>
> David Booth
> W3C Fellow / Hewlett-Packard
>
---
Marc Hadley <marc.hadley at sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Monday, 22 November 2004 19:11:20 UTC