Martin Gudgin wrote:
>
>>-----Original Message-----
>>From: Glen Daniels [mailto:gdaniels@sonicsoftware.com]
>>Sent: 02 November 2004 17:45
>>To: David Orchard; Martin Gudgin; Harris Reynolds;
>>public-ws-addressing@w3.org
>>Subject: RE: Issue 011
>>
>>
>>As I see it, here's what we lose by having refp's in their
>>current form:
>>
>>* Simplicity - as a WS-Addressing implementor, if there were no extra
>>processing involved to copy each refp into a first-class SOAP
>>header on
>>the sending side, I would be able to simply copy the "to" EPR into the
>><wsa:To> header and be done with it. On the receiving side, I would
>>simply make the refp's available to the app in the exact same
>>way I make
>>the <wsa:Action> available, again with no extra work to separate out
>>which headers are refp's and which are not. Having <wsa:To> be an EPR
>>would also make it easier to digitally sign without
>>separating out refp
>>headers. Splitting refp's out seems much more complicated to me.
>
>
> I don't understand "make the refp's available to the app". What does
> this mean? The piece of code that processes the body? Something else?
>
>
>>* Consistency - the other "address-like" headers (From, Reply-To, etc)
>>are all EPRs, so it's a little weird to do something different for To.
>
>
> EPRs (can) contain information other than [address] and [ref
> props/params]. But the address a message is sent to consists of ONLY the
> [address] and [ref props/params]
>
Any compelling reason why we should keep it so?
It seems reasonable to include wsa:ServiceQname, wsa:PortType,
extensibility points. This information can very well be used by the
receiver to figure out what to do with the message.
Comments?
>
>>* Clarity - it's not clear to intermediaries/observers which
>>headers are
>>refp's and which are not. And even though the endpoint itself "knows"
>>which are which, headers are typically processed by layers of
>>infrastructure code as Dave and Gudge describe below, so these layers
>>need to have a tight coupling with the rest of the engine in order to
>>correctly process the refp headers.
>
>
> Why? They are JUST headers. A SOAP processor doesn't need to care
> whether a header was inserted as a 'ref prop/param' or for some other
> reason.
>
>
>>* Safety - in the normal SOAP world, you write headers into a message
>>because you understand what they mean, and accept the consequences of
>>inserting them in there. WS-Addressing as it stands mandates that
>>someone using an EPR to send somewhere MUST insert each refp as a
>>first-class SOAP header WITHOUT understanding them. As I've said
>>before, I think this seems somewhat dangerous and counter-intuitive.
>
>
> I don't understand why this is dangerous. If you're worried about EPRs
> you receive, only accept EPRs that have been signed by someone you
> trust.
>
>
>>Now, Gudge has said that the main gain is the use of the SOAP
>>processing
>>model. I have yet to hear a real use-case for WHY this is a
>>good thing.
>>Gudge, can you describe a situation where it's really useful
>>for the EPR
>>supplier to use first-class headers to represent refp's, a situation
>>where it wouldn't be better to use extensibility/policy to tell the
>>other side to use a particular extension?
>
>
> I've found ref props very useful for, for example, implementing
> WS-Eventing. It allows me to give out EPRs containing ref props to event
> sources/subscribers and have software that just knows how to process
> SOAP headers deal with them. This means I process this stuff just the
> same way I process everything else in a SOAP message; look at the top
> level QName and dispatch to the appropriate piece of code. I don't have
> to tell the user of the EPR anything about those ref props. This means I
> can use whatever design I like and the other side doesn't have to
> understand any 'extensions'. Hey, constrained agreement, who'd have
> thought it...
>
> Gudge
>
>
>>Thanks,
>>--Glen
>>
>>
>>>-----Original Message-----
>>>From: public-ws-addressing-request@w3.org
>>>[mailto:public-ws-addressing-request@w3.org] On Behalf Of
>>>David Orchard
>>>Sent: Tuesday, November 02, 2004 1:29 PM
>>>To: Martin Gudgin; Harris Reynolds; public-ws-addressing@w3.org
>>>Subject: RE: Issue 011
>>>
>>>When you say "I'm a SOAP programmer", which context is the
>>>"I"? As a developer for the Indigo/.Net team that has
>>>written software that operates on .Net specific refprops as
>>>headers, or as a hypothetical application developer, or
>>>something else?
>>>
>>>
>>>
>>>When I say "processed b4 the actual service", I'm talking
>>>about layers if the app/infrastructure are built that way. A
>>>common implementation of ws-security and ws-rm will be as
>>>software modules in a pipeline that the app developer never
>>>sees. The bearing on ref properties is that the
>>>infrastructure that will do dispatch will be "b4" the app.
>>>Therefore it's not meant for the application developer but
>>>for a convenience of the infrastructure code. And I haven't
>>>yet heard of dispatch based on ref props that is done in
>>>multiple steps, ie why use more than 1 header block.
>>>
>>>
>>>
>>>Dave
>>>
>>>
>>>
>>>________________________________
>>>
>>>From: Martin Gudgin [mailto:mgudgin@microsoft.com]
>>>Sent: Tuesday, November 02, 2004 1:15 PM
>>>To: David Orchard; Harris Reynolds; public-ws-addressing@w3.org
>>>Subject: RE: Issue 011
>>>
>>>
>>>
>>>I agree that WS-A is a fundamental part of Web Services. And
>>>therefore I agree that there IS software that understands
>>>wsa:To. BUT there is also software 'outside' the WS-A layer,
>>>that understands just the SOAP processing model and the
>>>headers that are present because of RefProps/Params in some
>>>EPR. I'm a SOAP programmer. Not a WS-A programmer. I want to
>>>process things at the SOAP header layer. That's how I want to
>>>route messages to the appropriate piece of code. It's a
>>>general model that applies to ALL headers, not just those
>>>placed in as RefProps/Params.
>>>
>>>
>>>
>>>I don't understand what you mean by 'processed before the
>>>actual service', are you talking about layers of processing?
>>>If so, then sure, some (many?) headers are processed by a
>>>layer in the SOAP stack that gets invoked prior to the body
>>>being processed. I'm not sure how this bears on
>>>RefProps/Params appearing as headers.
>>>
>>>
>>>
>>>Gudge
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>________________________________
>>>
>>>
>>> From: David Orchard [mailto:dorchard@bea.com]
>>> Sent: 02 November 2004 14:26
>>> To: Martin Gudgin; Harris Reynolds; public-ws-addressing@w3.org
>>> Subject: RE: Issue 011
>>>
>>> Can you elaborate a bit on this? I agree that using
>>>SOAP headers for all refs is more general, but I'm not sure I
>>>quite get the use cases and hence the utility
>>>
>>>
>>>
>>> If we take a look at the WS-* specs, almost all the
>>>specs define headers that are processed before the actual
>>>service - like rm, security, etc. In fact, various vendors
>>>have worked very hard to ensure that headers are not
>>>available for the application, as we had to work very hard to
>>>get the Application Data feature in WSDL 2.0
>>>
>>>
>>>
>>> Every use case I've heard of for refs (except the one
>>>that I introduced about statelessness) is for identifying the
>>>actual service. Thus there are separate modes of usage of
>>>the service identifier versus infrastructure headers.
>>>
>>>
>>>
>>> Given that WS-Addressing will hopefully become a
>>>fundamental piece of Web services - and arguably should have
>>>been in SOAP 1.2 - and that the To field is required, is it
>>>really that much a problem to put a dependency on wsa:To in
>>>the service identification bit? Especially when the software
>>>that wraps the ref props implicitly depends upon the ws-a
>>>processing model and explicitly relies upon the soap
>>>processing model.
>>>
>>>
>>>
>>> I believe that I'm poking at the real world use cases
>>>and implementation of soap/ws-a stacks rather than
>>>theoretical "it would be nice to separate". And I think that
>>>talking about just the header structure rather than mU and
>>>role are where we can get some fruitful discussion.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Dave
>>>
>>>
>>>
>>>
>>>________________________________
>>>
>>>
>>> From: public-ws-addressing-request@w3.org
>>>[mailto:public-ws-addressing-request@w3.org] On Behalf Of
>>>Martin Gudgin
>>> Sent: Tuesday, November 02, 2004 6:47 AM
>>> To: Harris Reynolds; public-ws-addressing@w3.org
>>> Subject: RE: Issue 011
>>>
>>>
>>>
>>> I don't believe this characterization is complete. The
>>>reason for taking advantage of the SOAP processing model is
>>>to take advantage of the whole model, not just mustUnderstand
>>>processing. The model of SOAP is that SOAP nodes process
>>>headers. Different pieces of software, possibly at different
>>>nodes, possibly at a single node, can process different
>>>headers. Pushing RefProps(Params) into the wsa:To header
>>>means that I now have to have a piece of software the
>>>processes the wsa:To header ( it needs to understand at least
>>>that much of WS-Addressing ) and then pull out the relevant
>>>descendant elements. To me, this makes the processing model
>>>'the WS-Addressing processing model' and not the 'SOAP
>>>processing model'. I want software to be able to use the
>>>latter without having to know anything about the former.
>>>
>>>
>>>
>>> Gudge
>>>
>>>
>>>
>>>
>>>________________________________
>>>
>>>
>>> From: public-ws-addressing-request@w3.org
>>>[mailto:public-ws-addressing-request@w3.org] On Behalf Of
>>>Harris Reynolds
>>> Sent: 02 November 2004 09:36
>>> To: public-ws-addressing@w3.org
>>> Subject: Issue 011
>>>
>>>
>>>
>>> Here is a brief restatement of the issue: Why
>>>is the To EPR not serialized in the same way that ReplyTo or
>>>FaultTo EPRs are?
>>>
>>> I understand Gudge's comment at the F2F
>>>indicating that there is a difference between using an EPR to
>>>address a message (i.e. the "To" element) and sending an EPR
>>>for subsequent use in the case of ReplyTo/FaultTo etc.
>>>However, there still seems to an opportunity to simplify the
>>>specification by serializing EPRs similarly in both requests
>>>and responses.
>>>
>>> The advantage of the current approach is that
>>>the current SOAP 1.2 processing model can be used for
>>>processing reference properties (parameters); primarily using
>>>the mustUnderstand attribute.
>>>
>>> In my view, the advantage of serializing the To
>>>element directly as an EPR instead of splitting it into
>>>Address and Ref Props is simplicity. Using this approach the
>>>specification is easier to understand for those responsible
>>>for implementing it: if you have an EPR, just stuff it into
>>>the SOAP header and your work is done. As far as processing
>>>the EPR, the same amount of work will be required either way.
>>>
>>> From a practical perspective either method of
>>>serialization would work. The question is which would
>>>produce a better specification?
>>>
>>>
>>>
>>> ~harris
>>>
>>>
>>>
>>> ------------------------------
>>> Harris Reynolds
>>> webMethods, Inc.
>>> http://www.webmethods.com/
>>> ------------------------------
>>>
>>>
>>
>