RE: Issue 011

 

> -----Original Message-----
> From: Marc.Hadley@Sun.COM [mailto:Marc.Hadley@Sun.COM] 
> Sent: 03 November 2004 14:11
> To: Martin Gudgin
> Cc: Harris Reynolds; public-ws-addressing@w3.org; Glen 
> Daniels; Anish Karmarkar; David Orchard
> Subject: Re: Issue 011
> 
> On Nov 3, 2004, at 11:01 AM, Martin Gudgin wrote:
> >>
> >> 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.
> >
> What is the advantage in having port type and service as EPR children 
> rather than as standardized reference properties ?

Because the addresser needs them but the addressee does not.

> 
> >> 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.
> >
> Doesn't the action property encode much of that information (in a one 
> way transform kind of a way at any rate) ?

Not in the general case, no.

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

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