OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: addressing as opaque context (was RE: [ws-caf] Mt Everest and WS-CF)


Title: Message
Greg,
 
This one may really be a bit off our proper track.
 
Interleaved
-----Original Message-----
From: Greg Pavlik [mailto:greg.pavlik@oracle.com]
Sent: 27 May 2004 15:56
To: Furniss, Peter
Cc: Green, Alastair J.; Mark Little; ws-caf
Subject: Re: [ws-caf] Mt Everest and WS-CF



Furniss, Peter wrote:
Greg,

<snip the earlier part of the alastair .. thread>

  
A further comment on the IBM/MS product specs: there are in 
fact three 
contextualization mechanisms: one in WS-Coordination, one in 
WS-ReliableMessaging, and one in WS-Addressing. Putting aside 
WS-Addressing for a moment since it introduces a new model to the web 
services environment that I don't want to argue about here, let me 
observe that there is no fundamental distinction between the 
lifecycle 
control interface in WS-Coordination and WS-ReliableMessaging. Why 
shouldn't these be based on a common model? Wouldn't that in fact be 
simpler and less error prone? From there, it seems a small step to 
imagine the reliability and coordination/transaction contexts 
having a 
common root. I submit that this is in fact a flaw, not a strength, of 
the specification set; they they are unnecessarily complex due to the 
failure to deal with common constructs, idioms and patterns as, well, 
things-in-common.

    

Well the WS-Coordination and WS-RM both have equivalent of "begin".
WS-RM doesn't always use it, 
and when it is used, it is asked of the eventual receiver. The
termination sequences are different, since WS-RM is just stopping, and
WS-Coordination will have delegated to a transaction protocol. 

As contextualization, it is true that a message carrying the relevant
headers is "in the context" of those headers, and subject to their
implications. But the same is true of more or less any header - that's
what they're for. WS-Addressing is particularly interesting because it
is essentially "opaque context" - the reference properties don't need to
contain any kind of identifier in the ws-context sense at all (it might
tell the receiver which database to look in, but since only the receiver
knows what they meant, that's fine - it's just a piece of syntactic
partitioning of the address)
Is it fine? What if it happens to conflict with another header since there are no restrictions? I'd like to suggest that WS-Addressing would benefit from a container and that this is generally a problem for contextualization based solely on headers.
 
PRF: I thought ws-addressing needed a container at first but then realised the trick.  The reference properties only emerge from their WS-Address EnpointReference wrapper when the message is sent to the originator of the EPR. So all a generator of EPR's is saying is "when you send to me, put these in the headers; never mind why, or what you think they mean, just do it". It could only conflict with another header if the destination supported that header - (I suppose a sender might put in headers that it hoped the destination would understand (mustUnderstand=0, presumably) that in fact weren't wanted, but that's kind of wierd)
It does admittedly lead to some possibly odd things - one could have a joker reference property, that was something like:
 <wsa:ReferenceProperties>
     <ns1:statement>If this appears in a SOAP header it is an admission by the sender that he is a nitwit</ns1:statement>
 </wsa:ReferenceProperties>
 
I've been trying to work out if that could actually be used in a damaging way - it might be possible, but it would depend on more apparatus around web services than we have at present. 
 
But generally I don't see why a container for contextualization helps. ALL soap headers are the contextualization of the body. This works because they can be discriminated by their namespace identifiers. But that's the main contention I have, which the thread this sprang from can deal with.
 
Peter
 
. The other two would have an identifier but
that's the only thing they share, I think.

Peter
  


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]