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.

* 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.

* 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.

* 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.

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?

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 Tuesday, 2 November 2004 22:45:30 UTC