Re: Issue 011

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

Received on Wednesday, 3 November 2004 08:59:39 UTC