Re: Issue 011

Marc Hadley wrote:

> 
> On Nov 3, 2004, at 3:46 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...
>>
> My original suggestion was that we could replace the existing EPR 
> properties for WSDL port type and service with standardized ref props. 
> That way we keep the capability to include WSDL info in an EPR in a 
> standard way but also allow a service to mint an EPR that would result 
> in the WSDL info being included in messages addressed to the service.
> 
> Seems to me we have a two logical buckets in an EPR:
> 
> (i) Stuff that is information for a message sender that should be 
> included in a message. E.g. address, action, ref props/params.

Minor nit: action is not part of the EPR.

An indirectly related thought:
Given that action is required and action is derived from the WSDL -- 
either explicitly specified using the wsa:Action attribute or defaulted 
using the default rules defined in section 3.3.2 -- one has to include, 
in the message, information that ties the message to the WSDL.
Wouldn't it then make sense to include such information -- either thru 
the use of service qname or action or something else in the wsa:To 
header block itself? Rather than defining another MIH for this purpose?

> (ii) Stuff that is information for a message sender that need not be 
> (directly) included in a message. E.g. policy info.
> 
> The WSDL information can fall into either bucket depending on usage but 
> currently is tied to bucket (ii). Perhaps we should provide some means 
> to specify whether that information should be included or not.
> 
> Marc.
> 
>>>
>>>>>
>>>>>>> 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.
>>>
>>>
>>
>>
> ---
> Marc Hadley <marc.hadley at sun.com>
> Web Technologies and Standards, Sun Microsystems.
> 
>

Received on Thursday, 4 November 2004 20:10:12 UTC