W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

RE: Issue 011

From: David Orchard <dorchard@bea.com>
Date: Tue, 2 Nov 2004 13:29:09 -0800
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF0B6CEB48@ussjex01.amer.bea.com>
To: "Martin Gudgin" <mgudgin@microsoft.com>, "Harris Reynolds" <hreynolds@webmethods.com>, <public-ws-addressing@w3.org>
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





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


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.







	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






	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.





		From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Harris
		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

		From a practical perspective either method of
serialization would work.  The question is which would produce a better




		Harris Reynolds 
		webMethods, Inc. 
Received on Tuesday, 2 November 2004 21:29:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:06 UTC