Re: MAPs and SOAP

Marc Hadley wrote:
> 
> On Mar 16, 2005, at 10:59 AM, David Hull wrote:
> 
>> Would the [reply endpoint] and [fault endpoint] MAPs continue to 
>> exist  as such, and if so, why?
>>
> I think we'd have a [endpoint]: (endpoint reference, URI)  
> (0..unbounded) property that would replace [reply endpoint], [fault  
> endpoint] and [source endpoint]. We'd define the URIs for source, reply  
> and fault (using some of the text from the obsoleted sections) and  
> leave it open for definition of other URIs elsewhere.
> 
> We'd need to make similar changes to the SOAP and WSDL binding docs.
> 

Does that mean then that WSDL MEP mappings would define the cardinality 
of the [endpoint] property as well as the values of the URIs for various 
messages?
If so, I think this would work.

> Marc.
> 
>> Marc Hadley wrote:
>>
>>> On Mar 16, 2005, at 10:42 AM, David Hull wrote:
>>>
>>>> This might be helpful, but I still want to understand the  
>>>> distinction  between having an EPR somewhere in a message with a  
>>>> given designated  use, and having a MAP or SOAP property with an 
>>>> EPR  as a value.
>>>>
>>> Yes, I was assuming we'd make similar tweaks to the abstract part 
>>> of   the spec to talk about generic endpoint references in messages 
>>> and   their use.
>>>
>>> Marc.
>>>
>>>> Marc Hadley wrote:
>>>>
>>>>> I wonder if we can solve this in a way that suits everyone:
>>>>>
>>>>> (i) Add a 'use' attribute to the existing EndpointReferenceType 
>>>>> so   that  a usage (reply, fault, from, custom extension) URI can 
>>>>> be   specified.
>>>>> (ii) Redefine the existing ReplyTo, FaultTo and From elements to  
>>>>> have   types restricted from the EndpointReferenceType with a  
>>>>> defaulted use   attribute.
>>>>>
>>>>> This way we provide the extensibility mechanism that David is    
>>>>> requesting since one can include an EndpointReference element in 
>>>>> a    message with some custom value for the use attribute. We 
>>>>> also   maintain  the existing syntax for the predefined ReplyTo, 
>>>>> FaultTo  and  From  elements.
>>>>>
>>>>> I'm not a schema guru but what I mean is something like;
>>>>>
>>>>>     <xs:element name="EndpointReference"    
>>>>> type="tns:EndpointReferenceType"/>
>>>>>     <xs:complexType name="EndpointReferenceType">
>>>>>         <xs:sequence>
>>>>>             <xs:element name="Address"  type="tns:AttributedURIType"/>
>>>>>             <xs:element name="ReferenceParameters"    
>>>>> type="tns:ReferenceParametersType" minOccurs="0"/>
>>>>>             <xs:element ref="tns:Metadata" minOccurs="0"/>
>>>>>             <xs:any namespace="##other" processContents="lax"    
>>>>> minOccurs="0" maxOccurs="unbounded"/>
>>>>>         </xs:sequence>
>>>>> **      <xs:attribute name="use" type="xs:anyURI"/>
>>>>>         <xs:anyAttribute namespace="##other" processContents="lax"/>
>>>>>     </xs:complexType>
>>>>>
>>>>>     <xs:element name="ReplyTo"  
>>>>> type="tns:ReplyEndpointReferenceType"/>
>>>>>     <xs:complexType name="ReplyEndpointReferenceType">
>>>>>         <xs:complexContent>
>>>>>             <xs:restriction base="tns:EndpointReferenceType">
>>>>>                 <xs:sequence>
>>>>>                     <xs:element name="Address"    
>>>>> type="tns:AttributedURIType"/>
>>>>>                     <xs:element name="ReferenceParameters"    
>>>>> type="tns:ReferenceParametersType" minOccurs="0"/>
>>>>>                     <xs:element ref="tns:Metadata" minOccurs="0"/>
>>>>>                     <xs:any namespace="##other"  
>>>>> processContents="lax"   minOccurs="0" maxOccurs="unbounded"/>
>>>>>                 </xs:sequence>
>>>>> **              <xs:attribute name="use" type="xs:anyURI"    
>>>>> default="http://www.w3.org/2005/02/addressing/reply"/>
>>>>>                 <xs:anyAttribute namespace="##other"    
>>>>> processContents="lax"/>
>>>>>             </xs:restriction>
>>>>>         </xs:complexContent>
>>>>>     </xs:complexType>
>>>>>
>>>>> Marc.
>>>>>
>>>>> On Mar 15, 2005, at 8:17 PM, Anish Karmarkar wrote:
>>>>>
>>>>>>
>>>>>> It seems to me that providing a general mechanism (such as    
>>>>>> wsa:associatedEndpoint) would enable implementors to implement    
>>>>>> patterns beyond simple request-response. Request-response is   
>>>>>> certainly  a very important usecase that must be supported, but 
>>>>>> by   providing a  framework where users plug in URIs for specific  
>>>>>> "roles"  in an  interaction pattern seems like a win-win  
>>>>>> situation. We can  define a  'reply' and 'fault' URI which would  
>>>>>> mean that there is a  built in  support for the oft-used  
>>>>>> req-response pattern. The ability  to reuse an  MAP (btw, this 
>>>>>> set  is *not* extensible) to enable  various interesting  
>>>>>> interactions  lower the bar for supporting  additional 
>>>>>> interactions.  With such  a generic mechanism all that is  
>>>>>> required for new interaction   patterns is to define a new URI 
>>>>>> and  associated semantics as  opposed to  a new SOAP 
>>>>>> header/module/feature  that then has to be  processed by all  SOAP 
>>>>>> stacks. I agree that  providing such  extensibility is a good 
>>>>>> thing  for the same reason  that providing  extensibility for 
>>>>>> [relationship] is  a good thing.  Most people  view ws-addressing 
>>>>>> as a fundamental building  block and  providing  the right 
>>>>>> extensibility hooks in our spec would go  a long  way.
>>>>>>
>>>>>> -Anish
>>>>>> --  David Hull wrote:
>>>>>>
>>>>>>> I've been going back through the core and SOAP specs after  
>>>>>>> today's   discussion, and I'm still concerned about the  
>>>>>>> difference between   reply/fault and any other kind of 
>>>>>>> endpoint.   I also have an at  least  partially worked out 
>>>>>>> example below the  horizontal line,  which I'd  encourage 
>>>>>>> everyone to look through  and comment on even  if the  concerns 
>>>>>>> below hold no interest.
>>>>>>> To take Dave O's example, as I understand it, if I have a MEP   
>>>>>>> that's  basically request/reply but also has an alternate 
>>>>>>> reply,   then two of  the three endpoints are considered MAPs, 
>>>>>>> have   properties defined for  them in the SOAP addressing 
>>>>>>> module, and   appear in the wsa:namespace.   The third is just 
>>>>>>> some random SOAP   header.
>>>>>>> While it is true that one can always put an EPR wherever one  
>>>>>>> wants,   whether as a header or in some distinguished place in  
>>>>>>> the body, or   someplace out of band for that matter, it still  
>>>>>>> seems strange to  have  such an asymmetry instead of somehow  
>>>>>>> allowing for an  extensible set  of endpoints.  It seems  
>>>>>>> particularly strange when  we explicitly make  [relationship]  
>>>>>>> extensible.  We could just as  well have (and maybe  once did  
>>>>>>> have?) an [in-reply-to] property and  depend on SOAP   
>>>>>>> extensibility for anything further.
>>>>>>> I would think that the reasons for making [relationship]  
>>>>>>> extensible   are the usual ones: People are bound to define  
>>>>>>> relationships other   than in-reply-to, and we would like to 
>>>>>>> give  them a standard place  to  put those, in such a way that a  
>>>>>>> processor could generically  gather  "all related messages" from  
>>>>>>> a message without having to  understand  what in-reply-to and  
>>>>>>> whatever other headers mean.  I'm  not precisely  sure what the  
>>>>>>> use case would be for this, but it  seems like a good  thing  
>>>>>>> overall.
>>>>>>> I'm hard-pressed to see why it wouldn't be equally good to do 
>>>>>>> the    same thing with associated endpoints.  As with 
>>>>>>> [relationship],  one   could then generically determine what 
>>>>>>> endpoints might be  expected  to  receive messages due to a given 
>>>>>>> message, without  having to  understand  what my custom 
>>>>>>> "alternate-reply" header  means (or  assume that any  unknown EPR 
>>>>>>> in a header is liable to  carry ongoing  traffic).  This  might 
>>>>>>> make routing easier, or  help predict traffic  volume, or have  
>>>>>>> entirely other uses.  If  anything, this seems like  it might be 
>>>>>>> more  directly useful than  handling [relationship]  generically.
>>>>>>> If nothing binding documents for new interactions might be  
>>>>>>> somewhat   easier to read.  Along those lines, here is a draft 
>>>>>>> of  what an   "in-out-alternateOut" MEP might look like under 
>>>>>>> the  status quo.   I'm  neither endorsing nor disparaging this 
>>>>>>> version  (at this  point).  I'm  more interested in whether this 
>>>>>>> looks  about right so  far as what  would be required.  Any 
>>>>>>> feedback  would be welcome.
>>>>>>> ------------------------------------------------------------------ 
>>>>>>> -- -- --
>>>>>>>         XXX. In-out-alternateOut
>>>>>>> This is a two-way MEP. A reply is expected hence mandating 
>>>>>>> [reply    endpoint] in the request message. The response message 
>>>>>>> might be  a   fault.  */In addition, an alternate reply may 
>>>>>>> occur, hence   mandating  [alternate reply endpoint] in the 
>>>>>>> request message.   The  [alternate  reply endpoint] property is 
>>>>>>> an abstract property  like  the standard  Message Addressing 
>>>>>>> Properties.  If present,  it MUST  be mapped to the  SOAP 
>>>>>>> yatns:AlternateReply header,  analogously to  the mapping of  
>>>>>>> Message Addressing Properties  described in sections  3 and 4 of 
>>>>>>> the  WS-Addressing SOAP  binding.
>>>>>>> /*
>>>>>>> */When formulating an alternate reply, follow the rules in  
>>>>>>> section   3.2 of the WS-Addressing Core Spec (Formulating a 
>>>>>>> Reply  Message),  but  with rule 1 carrying the following 
>>>>>>> additional  clause:
>>>>>>> /*
>>>>>>>     * */If the reply is an alternate reply message, select the  
>>>>>>> EPR   from
>>>>>>>       the incoming message's [alternate reply endpoint] 
>>>>>>> property.  If
>>>>>>>       none is present, the processor MUST fault./*
>>>>>>> */
>>>>>>> /*
>>>>>>> Table xxx-1. Message addressing */and other /*properties for 
>>>>>>> in    message. Property     Mandatory     Description
>>>>>>> [destination]     Y     Provides the address of the intended   
>>>>>>> receiver of  this message
>>>>>>> [action]     Y     Identifies the semantics implied by this  message
>>>>>>> [source endpoint]     N     Message origin. Unused in this MEP,  
>>>>>>> but  may be  included to facilitate longer running message  
>>>>>>> exchanges.
>>>>>>> [reply endpoint]     Y     Intended receiver for the reply to  
>>>>>>> this  message.
>>>>>>> /[alternate reply endpoint]/
>>>>>>>     /Y/
>>>>>>>     /Intended receiver for alternate replies to this message./
>>>>>>> [fault endpoint]     N     Intended receiver for faults related  
>>>>>>> to  this  message. May be included to direct fault messages to 
>>>>>>> a   different  endpoint than [reply endpoint].
>>>>>>> [message id]     Y     Unique identifier for this message. Used  
>>>>>>> in  the  [relationship] property of the out message.
>>>>>>> [relationship]     N     Indicates relationship to a prior  
>>>>>>> message.  Unused  in this MEP, but may be included to facilitate  
>>>>>>> longer  running message  exchanges.
>>>>>>> */
>>>>>>> /*
>>>>>>> Table xxx-2. Message addressing /*and other */properties for 
>>>>>>> out    message. Property     Mandatory     Description
>>>>>>> [destination]     Y     Provides the address of the intended   
>>>>>>> receiver of  this message
>>>>>>> [action]     Y     Identifies the semantics implied by this  message
>>>>>>> [source endpoint]     N     Message origin. Unused in this MEP,  
>>>>>>> but  may be  included to facilitate longer running message  
>>>>>>> exchanges.
>>>>>>> [reply endpoint]     N     Intended receiver for replies to 
>>>>>>> this   message.  Unused in this MEP, but may be included to 
>>>>>>> facilitate   longer running  message exchanges.
>>>>>>> /[alternate reply endpoint]/
>>>>>>>     /N/
>>>>>>>     /Intended receiver for alternate replies to this message.    
>>>>>>> Unused in  this MEP, but may be included to facilitate longer   
>>>>>>> running message  exchanges./
>>>>>>> [fault endpoint]     N     Intended receiver for faults related  
>>>>>>> to  this  message. Unused in this MEP, but may be included to   
>>>>>>> facilitate longer  running message exchanges.
>>>>>>> [message id]     N     Unique identifier for this message. 
>>>>>>> Unused   in this  MEP, but may be included to facilitate longer 
>>>>>>> running   message  exchanges.
>>>>>>> [relationship]     Y     Indicates that this message is a  
>>>>>>> response  to the  in message using the in message [message id]  
>>>>>>> value and the  predefined   
>>>>>>> |http://www.w3.org/@@@@/@@/addressing/reply| IRI.
>>>>>>> */
>>>>>>> /**/
>>>>>>> /*
>>>>>>> Table xxx-3. Message addressing /*and other */properties for    
>>>>>>> alternateOut message. Property     Mandatory     Description
>>>>>>> [destination]     Y     Provides the address of the intended   
>>>>>>> receiver of  this message
>>>>>>> [action]     Y     Identifies the semantics implied by this  message
>>>>>>> [source endpoint]     N     Message origin. Unused in this MEP,  
>>>>>>> but  may be  included to facilitate longer running message  
>>>>>>> exchanges.
>>>>>>> [reply endpoint]     N     Intended receiver for replies to 
>>>>>>> this   message.  Unused in this MEP, but may be included to 
>>>>>>> facilitate   longer running  message exchanges.
>>>>>>> /[alternate reply endpoint]/
>>>>>>>     /N/
>>>>>>>     /Intended receiver for alternate replies to this message.    
>>>>>>> Unused in  this MEP, but may be included to facilitate longer   
>>>>>>> running message  exchanges./
>>>>>>> [fault endpoint]     N     Intended receiver for faults related  
>>>>>>> to  this  message. Unused in this MEP, but may be included to   
>>>>>>> facilitate longer  running message exchanges.
>>>>>>> [message id]     N     Unique identifier for this message. 
>>>>>>> Unused   in this  MEP, but may be included to facilitate longer 
>>>>>>> running   message  exchanges.
>>>>>>> [relationship]     Y     Indicates that this message is a  
>>>>>>> response  to the  in message using the in message [message id]  
>>>>>>> value and the  predefined   
>>>>>>> |http://www.alternate.org/addressing/alternateReply|  IRI.
>>>>>>> */
>>>>>>> /*
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---
>>>>> 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, 17 March 2005 04:00:18 UTC