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