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: Re: [ws-caf] addressing as opaque context (was RE: [ws-caf] Mt Everestand WS-CF)


Yes, perhaps. And admittedly, this is a theoretical problem: but since 
the referenceproperties have no constraints on what types may be 
present, there's of course the possibility that the header mapping 
*could* cause a conflict. Whether or not this might actually occur in 
the real world, we could manufacture a (bad) example. I'm not convinced 
that it's a good design decision, since it's easily resolved with a 
container.

Furniss, Peter wrote:

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