OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] Issue 28: MakeConnection preconditions are unclear



Jonathan,
  your observations, in general, sound nice but I think you're a bit mixed up.  None of those claims apply to what's in the spec (at least not to the RManonURI variant of MC) which is why they're not mentioned in the spec.  None of those server-side preconditions are needed beyond how EPRs are shared today no matter what the value of the wsa:Address element.  I think you're not understanding how MC is used because passing around an EPR with the RManonURI in it is no different than passing around an EPR with wsa:Anon in it - and these claims your making about preconditions don't seem to plague the WS-Addressing spec.  However, your observation about how the MSFT proposal doesn't have preconditions is quite interesting.  Extracting some text from the latest version (my comments in parens):

        The RM Source SHOULD include this element in any CreateSequence message it sends when it anticipates
        MakeConnection will be used to retrieve Sequence Traffic and Sequence Lifecycle Messages
        (this appears twice)
        (How does this 'anticipation' logic work? It sounds to me like it MUST always be sent w/o some out-of-band talking)

        When an unreachable client requires a new inbound sequence it MAY send the MakeConnection
        header independently to RM service endpoint
        (How does the client know when a new sequence is needed by the RMS w/o some out-of-band talking?)

        Upon receipt of a MakeConnection header block that the RM Source cannot relate to an existing
        sequence it MUST respond with either a CreateSequence message on the protocol specific back
        channel of the request, or with a MakeConnectionRefused fault
        (How does the RMS know when to fault or create an unneeded Sequence when a late arriving MC arrives?)

        The MakeConnection header MUST NOT be included on a message for which there is a defined response.
        (When the RM logic is not co-located with the application logic how is this determination made?)

        There are many potential mechanisms (e.g. reference parameters in the MakeConnectionTo EPR) that
        allow a server to relate a new sequence to a client to one previously established from the same client.
        Mandating a particular mechanism an implementation must use is out of scope of this specification.
        (As you said, not having a clear understanding of how things will work will lead to interop issues)

These are just some of the 'unknowns' I quickly found in the MSFT proposal.  You said you believe that the MSFT proposal doesn't require out-of-band communications - and yet for just the items listed above I think each one of those requires quite a bit of it.  Since you seem to understand the MSFT proposal perhaps you could explain to me how the above questions can be interoperably answered w/o some out-of-band communications that are not specified in the MSFT's proposal.

thanks
-Doug

__________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6906 | dug@us.ibm.com



"Jonathan Marsh" <jonathan@wso2.com>

11/25/2006 10:40 AM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
"'Gilbert Pilz'" <Gilbert.Pilz@bea.com>, "'Marc Goodner'" <mgoodner@microsoft.com>, "'Paul Fremantle'" <paul@wso2.com>, <ws-rx@lists.oasis-open.org>
Subject
RE: [ws-rx] Issue 28: MakeConnection preconditions are unclear





So I infer that the complete set of preconditions are:
 
Client:
1)      An EPR (self-generated), using the RMAnon URI template.
 
Server:
2)      The client’s EPR.
3)      An indication from the client that it may use MakeConnection in future interactions.
 
The spec does not mandate any particular way that the EPR and the indication get from client to server.
 
I have three observations about this:
1)      When a spec relies on out-of-band communication to operate, at the very least the preconditions should be formally enumerated.  This issue asks for such clarification in the spec.
2)      Because there is a reliance on preconditions, the behavior when they haven’t been met should be described in sufficient detail to have interoperable failures.
3)      In the large, interoperability would be better served by reducing dependence on out-of-band preconditions.  I think the Microsoft proposal has advantages in this regard.
 
Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
 



From: Doug Davis [mailto:dug@us.ibm.com]
Sent:
Friday, November 24, 2006 4:19 PM
To:
Doug Davis
Cc:
'Gilbert Pilz'; Jonathan Marsh; 'Marc Goodner'; 'Paul Fremantle'; ws-rx@lists.oasis-open.org
Subject:
RE: [ws-rx] Issue 28: MakeConnection preconditions are unclear

 

Hit send too soon....


The use of the RManonURI indicates that the client will poll for messages targeted to that EPR - so in terms of preconditions, the use of the RManonURI is the clients way of signaling its intention of using MC.  From the spec, line 811:

       This URI template in an EPR indicates a protocol-specific back-channel will be established through a mechanism such as MakeConnection,


thanks
-Doug

__________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6906 | dug@us.ibm.com


Doug Davis/Raleigh/IBM@IBMUS

11/24/2006 06:31 PM


To
"Jonathan Marsh" <jonathan@wso2.com>
cc
"'Gilbert Pilz'" <Gilbert.Pilz@bea.com>, "'Marc Goodner'" <mgoodner@microsoft.com>, "'Paul Fremantle'" <paul@wso2.com>, ws-rx@lists.oasis-open.org
Subject
RE: [ws-rx] Issue 28: MakeConnection preconditions are unclear

 


   






Per some conversations that have gone on I believe the only thing missing from the current spec would be a new Policy assertions allowing the server the ability to tell the client that it will support MakeConnection.

As to what information is known to each side - nothing aside from what's in the EPR - and this is consistent with how other specs (e.g. WS-Addr) work.  The EPR is opaque until someone tries to open a connection to the wsa:Address value.  When the implementation chooses to notice that its the RManonURI, or wsa:None or wsa:Anon or an addressable URI is an impl choice.  I see no reason why RM would need to have any more preconditions than, say, WS-Addressing.


thanks
-Doug

__________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6906 | dug@us.ibm.com

"Jonathan Marsh" <jonathan@wso2.com>

11/24/2006 12:16 PM

 


To
"'Gilbert Pilz'" <Gilbert.Pilz@bea.com>, Doug Davis/Raleigh/IBM@IBMUS, "'Paul Fremantle'" <paul@wso2.com>
cc
"'Marc Goodner'" <mgoodner@microsoft.com>, <ws-rx@lists.oasis-open.org>
Subject
RE: [ws-rx] Issue 28: MakeConnection preconditions are unclear

 


   






Can you point me to where in the spec it details exactly what information is known by each side before a MC is used?  


Jonathan Marsh
- http://www.wso2.com - http://auburnmarshes.spaces.live.com
 


 




From:
Gilbert Pilz [mailto:Gilbert.Pilz@bea.com]
Sent:
Wednesday, November 15, 2006 12:08 PM
To:
Doug Davis; Paul Fremantle
Cc:
Jonathan Marsh; Marc Goodner; ws-rx@lists.oasis-open.org
Subject:
RE: [ws-rx] Issue 28: MakeConnection preconditions are unclear


Doug,


Agree that MC+RManonURI is clearer than MC+SeqID and MSFT proposals in signaling the clients intention to use MC. Not certain I agree that it is clear enough . . .


- gp

 

 




From:
Doug Davis [mailto:dug@us.ibm.com]
Sent:
Wednesday, November 15, 2006 4:13 AM
To:
Paul Fremantle
Cc:
Gilbert Pilz; Jonathan Marsh; Marc Goodner; ws-rx@lists.oasis-open.org
Subject:
Re: [ws-rx] Issue 28: MakeConnection preconditions are unclear


The only ambiguity is in the MC+SeqID and MSFT proposals - those make some

undocumented assumptions about when MC will or will not be used based on the
presence of the WSA Anon URI.  Which are all valid uses even when MC will not be

used - hence the ambiguity.  MC+RManonURI is the only proposal that very clearly

allows the client to signal to the server that if the messages destined for that EPR are

not sent on the current backchannel then the client will poll for it.  If the client had no
intention of using MC then it wouldn't have used the RManonURI.  Very clear IMO.


thanks
-Doug

__________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6906 | dug@us.ibm.com

Paul Fremantle <paul@wso2.com>

11/15/2006 03:02 AM

 


To
Gilbert Pilz <Gilbert.Pilz@bea.com>
cc
Doug Davis/Raleigh/IBM@IBMUS, Marc Goodner <mgoodner@microsoft.com>, Jonathan Marsh <jonathan@wso2.com>, ws-rx@lists.oasis-open.org
Subject
Re: [ws-rx] Issue 28: MakeConnection preconditions are unclear



 

 


   






Gil

I also share your unease. I also am uneasy about saying that MC is
always on. There is a different security model implicit in supporting
MC. I don't want some random person polling for messages and reading
them. Therefore I believe that the server ought to be able to clearly
know if a client is going to use MC or not, and potentially refuse an
offer or not send a CS based on that. I still think that your last case
is a pretty clear indication but as the spec doesn't state this I think
we have a problem.

Paul

Gilbert Pilz wrote:
> Paul,
>
> Here's a CreateSequence with a non-Anon AcksTo and an Anon Offer/Endpoint.
>
>     <wsrm:CreateSequence>
>       <wsrm:AcksTo>
>  
> <wsa:Address>http://192.168.0.102:9090/axis/services/RMService</wsa:Address>
>       </wsrm:AcksTo>
>       <wsrm:Offer>
>  
> <wsrm:Identifier>uuid:2901b650-5952-11db-b92b-881536e8c557</wsrm:Identifier>
>         <wsrm:Endpoint>
>  
> <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>
>         <wsrm:Endpoint>
>       </wsrm:Offer>
>     </wsrm:CreateSequence>
>
> If I'm an RMD and I receive one of these (and I accept the Offer) should I
> assume that MC(SequenceID) is going to be used? I would think so, but the
> spec doesn't say one way or another.
>
> Here's a CreateSequence with an Anon AcksTo and a non-Anon Offer/Endpoint.
>
>     <wsrm:CreateSequence>
>       <wsrm:AcksTo>
>  
> <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>
>       </wsrm:AcksTo>
>       <wsrm:Offer>
>  
> <wsrm:Identifier>uuid:2901b650-5952-11db-b92b-881536e8c557</wsrm:Identifier>
>         <wsrm:Endpoint>
>  
> <wsa:Address>http://192.168.0.102:9090/axis/services/RMService</wsa:Address>
>         <wsrm:Endpoint>
>       </wsrm:Offer>
>     </wsrm:CreateSequence>
>
> Sould an RMD assume that MC(SequenceID) is going to be used? I would think
> not, since you should be able to piggy-back Acks on the HTTP response
> channel but, again, the spec isn't clear.
>
> Here's a CreateSequence with both an Anon AcksTo and an Anon Offer/Endpoint
>
>     (... you get the point ...)
>
> It seems pretty clear that, if an RMD gets one of these (and accepts the
> Offer), that MC(SequenceID) will need to be used but . . .
>
> In any case I'm pretty uncomfortable with the idea of deriving the RMS and
> RMD's expected behavior from the combination of values of various elements
> of the CreateSequence element. Even the MakeConnection(RM-Anon) rule of "if
> you see a .../ws-rx/wsrm/200608/anonymous?id={uuid} as the value of any
> wsa:Address element in CS you should expect that MC will be used" makes me a
> little uneasy.
>
> - gp
>
>  
>> -----Original Message-----
>> From: Paul Fremantle [mailto:paul@wso2.com]
>> Sent: Tuesday, November 14, 2006 9:27 AM
>> To: Paul Fremantle
>> Cc: Doug Davis; Marc Goodner; Jonathan Marsh;
>> ws-rx@lists.oasis-open.org
>> Subject: Re: [ws-rx] Issue 28: MakeConnection preconditions
>> are unclear
>>
>> Actually I think in addition the CS/Offer/Endpoint should be
>> anonymous for the precondition.
>>
>> Paul
>>
>> Paul Fremantle wrote:
>>    
>>> I believe that with MC(SequenceID) I think there is a clear
>>> preconditiion, which is CS+Offer+Anonymous-Acks-To.
>>>
>>> Paul
>>>
>>> Doug Davis wrote:
>>>      
>>>> Sorry, not true. MSFT's proposal does not address any
>>>>        
>> preconditions
>>    
>>>> since the ability to support MC should be known before the CS is
>>>> sent, not after. Sending a MCRefued in response to a MC is
>>>>        
>> too late
>>    
>>>> in the game. No matter which version of MC lives on I think some
>>>> policy assertion will be needed so the server-side can
>>>>        
>> advertise that
>>    
>>>> it will support MC, or not. I was assuming we could use
>>>>        
>> this issue to
>>    
>>>> add that.
>>>>
>>>> As for Jonathan's text about either side needing to be in
>>>>        
>> possession
>>    
>>>> of the RManonURI - short answer is 'no' - only the minter (client)
>>>> needs to know what the value is.
>>>>
>>>> thanks
>>>> -Doug
>>>> __________________________________________________
>>>> STSM | Web Services Architect | IBM Software Group
>>>> (919) 254-6905 | IBM T/L 444-6906 | dug@us.ibm.com
>>>>
>>>>
>>>>
>>>> *Marc Goodner <mgoodner@microsoft.com>*
>>>>
>>>> 11/14/2006 11:34 AM
>>>>
>>>>    
>>>> To
>>>>     Marc Goodner <mgoodner@microsoft.com>, Jonathan Marsh
>>>> <jonathan@wso2.com>, "ws-rx@lists.oasis-open.org"
>>>> <ws-rx@lists.oasis-open.org>
>>>> cc
>>>>    
>>>> Subject
>>>>     RE: [ws-rx] Issue 28: MakeConnection preconditions are unclear
>>>>
>>>>
>>>>
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> In the proposal we made for PR001 I don't believe the below is an
>>>> issue. The expected setup for MakeConection is defined.
>>>>
>>>> I agree that if we close PR001 with no action that the
>>>>        
>> current spec
>>    
>>>> will need to be changed to address this problem.
>>>>
>>>>
>>>> *From:* Jonathan Marsh [mailto:jonathan@wso2.com] *
>>>> Sent:* Monday, November 06, 2006 9:46 AM*
>>>> To:* ws-rx@lists.oasis-open.org*
>>>> Subject:* [ws-rx] New issue: MakeConnection preconditions
>>>>        
>> are unclear
>>    
>>>> MakeConnection as defined today relies on the RM Anonymous URI
>>>> template. The spec does not adequately specify the preconditions
>>>> necessary for the exchange to be successful.
>>>>
>>>> Prior to a MakeConnection message, do both the client and
>>>>        
>> the server
>>    
>>>> have to be in possession of a correctly constructed
>>>>        
>> instance of the
>>    
>>>> RM anon URI template? Of an EPR using this template? The example
>>>> messages invent a subscription operation in step 1, which
>>>>        
>> indicates
>>    
>>>> that the precise URI and the intent to enable
>>>>        
>> MakeConnection must be
>>    
>>>> negotiated between the RMD and RMS out of band, yet
>>>>        
>> nowhere are these
>>    
>>>> preconditions enumerated. The RM protocol preconditions
>>>>        
>> only list an
>>    
>>>> EPR as a precondition, not the precise form of that EPR, and any
>>>> intention that buffering of messages should be engaged.
>>>>        
>> What happens
>>    
>>>> if a client does a MakeConnection without all preconditions being
>>>> satisfied also appears to be underspecified.
>>>>
>>>> *Jonathan Marsh* - _http://www.wso2.com_ <http://www.wso2.com/> -
>>>> _http://auburnmarshes.spaces.live.com_
>>>> <http://auburnmarshes.spaces.live.com/>
>>>>
>>>>        
>> --
>> Paul Fremantle
>> VP/Technology and Partnerships, WSO2
>> OASIS WS-RX TC Co-chair
>>
>> http://bloglines.com/blog/paulfremantle
>> paul@wso2.com
>> (646) 290 8050
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>>
>>
>>    

--
Paul Fremantle
VP/Technology and Partnerships, WSO2
OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul@wso2.com
(646) 290 8050

"Oxygenating the Web Service Platform", www.wso2.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]