RE: Issue 011

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

> 
> * 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 04:03:34 UTC