RE: Issue 0001: Use cases for Reference Properties?

David

here are two simple use-cases:


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 


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.


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

Received on Monday, 22 November 2004 18:36:02 UTC