Re: Issue 011

On Nov 3, 2004, at 3:51 AM, Anish Karmarkar wrote:
>
> 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".

Related to this I wonder if port type and service name should be 
standardized reference properties rather than being called out 
separately in the EPR ?

>  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.
>
I agree, I think its undesirable to leave out the WSDL metadata from 
messages sent to an epr.

Marc.

>
>> 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/ 		------------------------------
>>>
>
>
---
Marc Hadley <marc.hadley at sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Wednesday, 3 November 2004 15:21:19 UTC