Re: Issue 011

Glen Daniels wrote:
> 
> 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.
> 

+1 to all the points above. Well put.

I would like to add that the 'safety' issue is related to another issue 
which is -- requiring consumers to blindly include something as a SOAP 
header block, without knowing the semantics of the header block, goes 
very much against the design center of SOAP, IMHO. In SOAP, the sender 
is responsible for including the header blocks, which typically are 
understood by the sender. The sender makes the decision whether to 
include them or not, stick a MU/role/actor/reinsert/relay attribute etc.

Another issue is 'composibility' -- what happens if there is a policy in 
place at the consumer which says "thou must use 
WS-Reliability/WS-ReliableMessaging" and the refp contains a well known 
  WS-Reliability/WS-ReliableMessaging header block -- can the consumer 
look at the refp and understand it and make a decision?

What about the rest of the stuff that is in the EPR -- i.e. why are 
refps special -- what about wsa:PortType, wsa:ServiceName, extensibility 
elements? The EPR identifies the service endpoints. I would image that 
we would allow all the information in an EPR to be bound to SOAP so as 
to provide the receiving SOAP node all the information that it *may* 
need to target the message to the right "thing". Granted that we could 
invent new mechanisms/soap header blocks to bind this information and/or 
leave it to the extensibility points to figure it out. But it seems like 
a much more easier and convenient thing to do, would be to make wsa:To 
an EPR.

Thoughts?

> 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 Wednesday, 3 November 2004 08:51:58 UTC