RE: Issue 011

 

> -----Original Message-----
> From: Marc.Hadley@Sun.COM [mailto:Marc.Hadley@Sun.COM] 
> Sent: 03 November 2004 10:21
> To: Anish Karmarkar
> Cc: Harris Reynolds; Martin Gudgin; 
> public-ws-addressing@w3.org; Glen Daniels; David Orchard
> Subject: 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 ?

Why? The whole point of RefProps/Params is that they are determined by
the service implementation.

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

Why? Personally I never need the porttype/operation/servicename to
appear on the wire in order to dispatch messages. 

Gudge

> 
> 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 16:02:27 UTC