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.

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

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:30:49 UTC