Re: Issue 011

Martin Gudgin wrote:

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

There may be cases (perhaps a lot) where the addressee does not need the 
information. But there are certainly cases where the addressee does need 
the information.

For example, there could be multiple services fronted by a URL or there 
is a common intermediary for multiple SOAP paths. Each service may 
generate EPRs independent of any other service and may not be aware of 
other services. Given this, it is possible that the values of 
wsa:Address and refps in two EPRs are the same, but are generated by 
different services. The only disambiguator in that case is the service 
qname or other information available in the EPR.

Neither the sender nor the receiver may be aware of such a scenario. 
Having this information available in the wsa:To would disambiguate the 
destinations.

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

But Action MIH is required.
Are u saying that -- it is not required that the default be used. I.e., 
one can have a wsa:Action attr specified in WSDL?

> 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 Thursday, 4 November 2004 20:00:13 UTC