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