- From: Graham Klyne <GK@ninebynine.org>
- Date: Mon, 21 Oct 2002 10:12:58 +0100
- To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
- Cc: "XMLP Dist App" <xml-dist-app@w3.org>
Henrik, I think I now see an inkling of where you're coming from here, even if I'm not sure I agree... So, two comments: - This underpinning notion of a "contract" is not one that was apparent to me when I read through the SOAP messaging framework document ... that could be because my reading wasn't particularly thorough, but if it really is fundamental to the design I think it would be worth making sure that's adequately exposed in the specification docs. - I'm not currently clear what the benefits are of this "contract" approach, though I could imagine it results in greater predictability of behaviour when a message passes through several SOAP processors. I could see that the scenario I outlined in my message to Noah (to do with multiple transcoding intermediaries on a message path) might be handled with mustUnderstand and re-emitting the header: maybe that's OK. What I can't tell is if that would result in a deployed framework in which it is harder to deploy new features. E.g., I could imagine a SOAP intermediary at an organizational boundary whose job is to check for threats, etc. -- if a new mustUnderstand feature is to deployed, that gatekeeper system must be upgraded to allow the new feature to pass, even if such understanding is not needed for it to fulfil its role (sic) in life. #g -- At 10:19 AM 10/18/02 -0700, Henrik Frystyk Nielsen wrote: >Jacek, > > >In the text below you are first saying that you agree > >"targeting is about establishing a contract between the sender > >and a receiving role" and then that "the default is that a > >contract is between the sender and the first receiver acting > >in the specified role". > > > >I think the first statement can be interpreted differently > >from the way the second statement interprets it. The flipped > >default would change that interpretation. > >I respectfully disagree with this interpretation. Look for example at >the description of "next" and "ultimateReceiver". The "next" role >doesn't say "anybody who can play next is it". It says the first "next" >is it. We say something similar for the ultimate receiver: it's the >first ultimate receiver, not some other ultimate receiver after that. > >The notion of a contract has been in SOAP for a long time and was very >much behind the introduction of the "role" concept. If we went with the >interpretation above then I think it would not only erode the concept of >a contract but also of the mU flag: If a role is only sometimes the >first recipient, then why should it honor the mU flag if that can be >fulfilled by some other node acting in that role? > > >Anyway, by introducing a single special role for relaying, > >you're saying that a single application will never have two > >conflicting sets of headers that should be relayed if not processed. > >Fundamentally, what we are arguing is where to draw the line between >contracts implied by roles and how this interacts with related >parameters. We have already decided to make mU a standalone attribute, >and I think we are discussing whether making relaying another candidate. > >A reason behind the "relay" role is that given that >"relayIfNotProcessed" does not imply any processing, one cannot >distinguish whether it was forwarded but ignored by one role or another: >the output is exactly the same. Similarly, I personally doubt that we >will see scenarios where two instances of the same header block will be >targeted at two different roles and both have "relayIfNotProcessed". >However, as you point out, it is possible that such scenarios will be >common. > > >In other words, if you can't agree to just flip the default > >(which changes the contract for everybody to something I view as more > >realistic) then an additional attribute is the only way to go > >if we want to add the possibility of relaying unprocessed > >headers into SOAP 1.2. > >The way I would put it that if people think that the sort of scenarios >above will be common then an attribute is the right way to go. If not >then a "relay" role can do the job. I think I have indicated that I >really don't like flipping the default ;) > >Henrik ------------------- Graham Klyne <GK@NineByNine.org>
Received on Monday, 21 October 2002 08:44:02 UTC