RE: Issue 011

 

> -----Original Message-----
> From: Marc.Hadley@Sun.COM [mailto:Marc.Hadley@Sun.COM] 
> Sent: 03 November 2004 15:31
> 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 2:30 PM, Martin Gudgin wrote:
> >>>
> >>> 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 that it might not, but I think its premature to rule out it 
> being required.

Sorry, I didn't mean to imply that no endpoints would ever need such
information. I was trying to point out that there will be endpoints that
don't care. And given how RefProps/Params work I don't really see why
we'd need to standardize a one to carry this info...

> 
> >>
> >>>> 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.
> >
> But section 2.2 (Default Action Pattern) of the WSDL binding goes to 
> some length to do just that.

But it's not required.

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

Received on Wednesday, 3 November 2004 20:47:25 UTC