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 ?

>> 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) ?

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:10:45 UTC