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