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