I think that in your proposal, renaming GetMessage to
anything that conveys the technical intent of establishing a backchannel makes
sense. Perhaps this will also help in comparing the two current polling based
proposals!
-- Sanjay
From: Doug Davis [mailto:]
Sent: Friday, Apr 28, 2006 20:16 PM
To:
Subject: RE: [ws-rx] i089
proposal
+1 - well stated. Its the
special cases and changes to the RM processing model we're trying to
minimize.
Gil - was thinking about
your questions on the call yesterday regarding whether GetMessage should be
modeled as a one-way or request/response. While its a superficial
change, I was wondering if we renamed GetMessage to something else, like
EstablishConnection, if that would make it more palatable? This would
make it clearer that we're not performing some kind of query but rather we're
just trying to reconnect the two endpoints.
thanks,
-Doug
"Gilbert Pilz"
<>
04/28/2006 12:55 PM
To
"Paul Fremantle"
<>
cc
<>
Subject
RE: [ws-rx] i089
proposal
Paul,
To be fair, I don't think its primary intent of Doug's
proposal is to be
more "wide ranging". It appears that the goal of this
proposal is to
minimize the amount of special case code that needs to be
added to the
RMD to support non-reachable clients. Pushing the polling
correlator
"down" into the EPR allows the server-side RMS to operate just
like any
other RMS without having to be aware of the fact that the RMD is
on an
unreachable client.
I think we need to come to a consensus
about the motivations behind
Doug's proposal. How many special cases does
your proposal call for? How
important is it to avoid having to make those
special cases?
- gp
> -----Original Message-----
>
From: Paul Fremantle [mailto:]
> Sent: Friday, April 28,
2006 4:41 AM
> Cc:
> Subject: Re:
[ws-rx] i089 proposal
>
> Doug
>
> I still haven't
quite worked through the changes in your
> latest proposal, but the
model of opening up a back channel
> with a one-way call certainly
sounds interesting and worth
> further pursuit.
>
> I
think the fundamental difference between our proposals is
> the context
under which a "client" can retrieve messages from
> a server.
>
> In my proposal that context is always a sequence, and
>
therefore - logically - the sequence must exist. For the
> sequence to
exist it either has to be created by the "server"
> using some other
back-channel - or the "client" has to offer
> it. The Offer model seems
much more likely though I don't
> want to rule out other
mechanisms.
>
> In your proposal the "context" under which the
client
> retrieves messages (and also the server buffers them) is an
> EPR. While I quite like the IBM proposal I believe it is a
>
much more general proposal than the proposal that WSO2 has offered.
>
> You wish to maintain the ability for an RMS - even a server
>
RMS - to create a sequence with an anonymous client's RMD.
> Can you
give some real world scenarios in which this is
> required: where a
server needs to initiate a Sequence with an
> anonymous client?
>
> Because the main scenario that is driving WSO2 is very
>
simple. The anon client creates and offers a sequence and
> interacts
under those two sequences.
>
> In contrast I consider it an
important aspect of the
> specification that all buffering of messages
takes place
> under a sequence and corresponding sequence identifier.
So
> while I don't rule out the server using some existing back
> channel to create a sequence, I think the simplest model is
>
for the client to offer a sequence and the server to buffer
> messages
under the context of that sequence as it does today.
> I personally see
that requiring the server to buffer messages
> associated with EPRs but
not with sequences to be a major
> change to the protocol and
processing model.
>
> In summary, the IBM proposal is a very neat
proposal for a
> reasonably generic solution to the anonymous client
problem.
> It seems much more wide ranging than the proposal we have
> offered and has much greater implications for an
>
implementation of WSRM. However, it also provides more
> flexibility
and supports a more wide ranging set of potential
> models. It's simply
that we have not yet seen any demand for
> those models in the RM
scenarios we have seen.
>
> Paul
>
>
> Doug
Davis wrote:
> >
> > I do believe that the scenario
you're talking about is a required
> > one but I would phrase it a
bit differently. An RMS
> (whether its the
> >
client-side RMS or the server-side RMS) needs to be able to
> follow
the
> > same RM processing model. And part of the processing
model is the
> > ability to decide "if", "when" and "how" to use RM.
As we
> talk about
> > in the Q&A section of our
proposal, an RMS having the option of
> > choosing to decide which
RM sequence to use, when to create
> new ones,
> > or even
when to use RM at all are all part of the RM
> processing model
> > and those aspects need to be maintained even in these anon
cases.
> > In your proposal you put the burden on the RMD to
make a lot
> > decisions on behalf of the RMS, that's quite a change
to the RM
> > processing model and I have no idea how the RMD could
ever
> know all it
> > would need to know to make those
decisions.
> > For example, how
> > would it know when
a new sequence is needed by the RMS?
> That is why I
>
> believe our proposal is a better fit for RM - it allows the RMS to
> > retain all of the same logic and choices that it has in the
async
> > world. Our proposal simply re-establishes the
backchannel that the
> > RMS (on the server side) is looking for -
nothing more.
> Once that is
> > there, it is then back
to "standard operating procedures" - the RMS
> > can do whatever it
would normally do.
> > thanks,
> > -Doug
>
>
> >
> >
> > *Paul Fremantle
<>*
> >
> > 04/27/2006 05:51 PM
>
>
> >
> > To
> >
Marc Goodner <> cc
>
> wsrx
<>
> > Subject
> >
Re: [ws-rx] i089
proposal
> >
> >
> >
> >
> >
>
>
> >
> >
> >
> > If the TC isn't
attached to this scenario then this section can be
> > deleted. The
scenario is simply when you want to send unreliably but
> > receive
reliable responses. I've heard this stated as a
> requirement
in
> > some scenarios, but WSO2 doesn't have any pressing
>
scenarios of this ilk
> > so we would be happy either way.
>
>
> > Paul
> >
> > Marc Goodner wrote:
>
> > So is an RMS engaged at the client side or not? This is
>
weird, why would
> > > the infrastructure on the client side
decide to do this?
> > >
> > > Marc Goodner
>
> > Technical Diplomat
> > > Microsoft Corporation
>
> > Tel: (425) 703-1903
> > > Blog:
http://spaces.msn.com/mrgoodner/
> > >
> > >
>
> > -----Original Message-----
> > > From: Paul Fremantle
[mailto:]
> > > Sent: Thursday, April 27, 2006 12:57
PM
> > > To: Marc Goodner
> > > Cc: wsrx
> >
> Subject: Re: [ws-rx] i089 proposal
> > >
> > >
Marc
> > >
> > > This is the case where the client is
making an offer but
> not creating an
> > >
> >
> outbound sequence - thats all. A client offers a
> sequence, and
then
> > > reliably gets messages from the server that are
buffered
> under that
> > > sequenceID.
> >
>
> > > Paul
> > >
> > > Marc Goodner
wrote:
> > >
> > >> I still don't understand
why offered sequence is being
> used in the
> > >>
explanation. If this is going to usually be used with an offered
> >
>> sequence I'd like to understand how, that isn't
> explained in
my mind.
> > >>
> > > If
> >
>
> > >> it is applicable for any sequence, offered
or not, I'd like to
> > >> understand that as well. The current
text only confuses
> me in its use
> > >>
> > > of
> > >
> > >> the
term and I'm afraid your explanation below isn't
> helping me
get
> > >>
> > > past
> >
>
> > >> it. Perhaps comparing the two modes would be
a better approach.
> > >>
> > >> On 4.2, "Offer
a sequence without the overhead of
> requesting one"? I
> >
>> don't understand. The text refers to the RMD requesting
> a
sequence
> > >>
> > > from
>
> >
> > >> the RMS, but it sounds like this is an
unreliable
> request so doesn't
> > >> that mean there
is no RMS at the client? Isn't this
> about the service
> >
>> acting as an RMS and the client acting as an RMD? So the
>
pattern would
> > >> be client sends one way message to service
> (GetMessage?), response is
> > >> Offer, then client
sends a response to the response of
> Accept? What
> >
>>
> > > does
> > >
>
> >> the service return to that? Why wouldn't the service
> send a CS in the
> > >> body of the GetMessage
response to the client?
> > >>
> > >> Marc
Goodner
> > >> Technical Diplomat
> > >>
Microsoft Corporation
> > >> Tel: (425) 703-1903
> >
>> Blog: http://spaces.msn.com/mrgoodner/
> > >>
>
> >>
> > >> -----Original Message-----
> >
>> From: Paul Fremantle [mailto:]
> > >>
Sent: Monday, April 24, 2006 1:11 AM
> > >> To: Marc
Goodner
> > >> Cc: wsrx
> > >> Subject: Re:
[ws-rx] i089 proposal
> > >>
> > >> Marc
>
> >>
> > >> I use the words "Offered Sequence"
informatively and
> non-normatively.
> > >> This is most
likely to be used with an offered sequence,
> but isn't
> >
>>
> > > tied
> > >
>
> >> to that.
> > >>
> > >> As regards
4.2, this is there to satisfy the scenario
> where you only
>
> >> want reliable responses. I added this in for discussion
>
because I know
> > >>
> > >
>
> >
> > >> that some members find this an
important scenario. In
> that case you
> > >>
> > > need
> > >
> > >>
to be able to Offer a sequence without the overhead of
> requesting
one.
> > >>
> > >
> > >
> > >> It is related to the anonymous client because
without a
> real endpoint
> > >> the server cannot send
a CS to the client so it relies
> on an offer.
> >
>>
> > >> Paul
> > >>
> >
>> Marc Goodner wrote:
> > >>
> >
>>
> > >>> Given 1 and 2, yes some text
that clarified that not
> only is this
> > >>>
specific to RM but that a general solution would be
> preferable
would
> > >>>
> > >>>
> > >> be
> > >>
>
> >>
> > >>> best.
> >
>>>
> > >>> On 3 I suppose, I don't like seeing
WS-A headers in the
> body of a
> > >>> message
though. Do you really even need the response
> for a specific
>
> >>> message? Why not return any responses or messages for
> that sequence
> > >>>
> >
>>>
> > >> that
> >
>>
> > >>
> > >>>
have not been acknowledged? And what are you talking
> about when
you
> > >>>
> > >>>
> > >> say
> > >>
>
> >>
> > >>> this is tied to the
offered sequence? What offered
> sequence? I don't
> >
>>>
> > >>>
> > >> see
> > >>
> >
>>
> > >>> anything here that ties the
use of your GetMessage
> proposal to an
> > >>>
offered sequence.
> > >>>
> > >>> I don't
understand section 4.2 in your proposal at all.
> What does
>
> >>>
> > > this
> >
>
> > >>> have to do with the rest of this
proposal?
> > >>>
> > >>> Marc
Goodner
> > >>> Technical Diplomat
> > >>>
Microsoft Corporation
> > >>> Tel: (425) 703-1903
>
> >>> Blog: http://spaces.msn.com/mrgoodner/
> >
>>>
> > >>>
> > >>> -----Original
Message-----
> > >>> From: Paul Fremantle
[mailto:]
> > >>> Sent: Thursday, April 20,
2006 1:57 AM
> > >>> To: Marc Goodner
> >
>>> Cc: wsrx
> > >>> Subject: Re: [ws-rx] i089
proposal
> > >>>
> > >>> Marc
> >
>>>
> > >>> 1) Yes - I completely aimed this to be
a specific model
> for RM. I
> > >>>
> > >>>
> > >>
would
> > >>
> > >>
>
> >>> be happy to include language that indicates that if a
> more general
> > >>> purpose firewall crossing
mechanism was in place this
> should not be
> > >>>
used.
> > >>> 2) The wsrm:Identifier is a required part of
my proposal, and
> > >>>
> >
>>>
> > >> therefore
> >
>>
> > >>
> > >>>
this proposal is completely tied to the use of RM.
> > >>>
3) The suggestion of using messageNumber is interesting. The
> >
>>>
> > >>>
> > >> motivation
> > >>
>
> >>
> > >>> for using a message ID
was that there may be situations where I
> > >>>
> > > really
> > >
> >
>>>
> > >>>
> > >>
> > >>
> > >>> want the response to a given message. We do
not - so
> far - have any
> > >>> concept of a
response to a given RM messageID, so that
> seemed like a
> >
>>>
> > >>>
> > >> new
> > >>
> >
>>
> > >>> concept to me, whereas WS-A
systems do keep track of
> responses to
> > >>>
> > >>>
> >
>> given
> > >>
> > >>
> > >>> messageIDs. But I'm not averse to your
suggestion.
> However I wish to
> > >>> make clear
that in my proposal you MUST have both the
> Identifier and
>
> >>>
> > >>>
> > >> the
> > >>
> >
>>
> > >>> messageID - so it is still
very closely tied to the
> offered sequence.
> >
>>>
> > >>> Paul
> > >>>
>
> >>> Marc Goodner wrote:
> > >>>
>
> >>>
> > >>>
> > >>>> I hope that this is scoped to RM and not
a general
> purpose polling
> > >>>> mechanism. I
assume that is your intent in that you use the
> > >>>>
wsrm:Identifier and indicate that you see this being
> part of
the
> > >>>>
> >
> core
> > >
> > >>>> spec. Still
it seems like including language that
> indicates that
> >
>>>>
> > >>>>
> > >> would
> > >>
> > >>
> > >>>> be
advised, particularly noting that if there were a
> general
purpose
> > >>>> polling mechanism that it might be
preferred over this one.
> > >>>>
> >
>>>> So following from that why is MessageID in the
>
GetMessage? Isn't the
> > >>>> identifier enough? If it
isn't wouldn't the addition of
> > >>>>
wsrm:MessageNumber do the trick?
> > >>>>
> >
>>>> Marc Goodner
> > >>>> Technical
Diplomat
> > >>>> Microsoft Corporation
> >
>>>> Tel: (425) 703-1903
> > >>>> Blog:
http://spaces.msn.com/mrgoodner/
> > >>>>
> >
>>>>
> > >>>> -----Original
Message-----
> > >>>> From: Paul Fremantle
[mailto:]
> > >>>> Sent: Thursday, April 06,
2006 12:40 PM
> > >>>> To: wsrx
> >
>>>> Subject: [ws-rx] i089 proposal
> >
>>>>
> > >>>> Folks
> >
>>>>
> > >>>> At the F2F I took away an
action to come up with a
> proposal for i089
> >
>>>>
> > >
> >
>
> > >>>> before the call. I'm sorry its so
close to the call.
> > >>>>
> > >>>>
I've attached a proposal for review. This is a work in
> progress,
but
> > >>>>
> >
>>>>
> > >> I
>
> >>
> > >>
> >
>>>>
> > >>>>
> > >>>>
> >
>>>
> > >>>
> >
>>>
> > >>>> think it helps
call out some of the issues involved
> around i089.
> >
>>>>
> > >>>> I think the most important
questions for the TC are:
> > >>>>
> >
>>>> (1) How does a customer/user use WSRM in a two-way
>
scenario if one
> > >>>>
> >
>>>>
> > >>>>
> > >>> side
> > >>>
> > >>>
> > >>>
> > >>>> is anonymous?
> >
>>>> (2) Adding a "GetMessage" makes the protocol more
>
symmetric, but
> > >>>>
> > > also
> > >
> >
>>>>
> > >>>>
> > >>
> > >>
> > >>>> might overlap with a wider non-reliable
solution to
> this problem. Is
> > >>>>
> > >>>>
> >
>>>>
> > >>>
it
> > >>>
> > >>>
> > >>>
> >
>>>> in the scope of this TC to add this?
> >
>>>> (3) In the case we do add it, what criteria do we use to
select
> > >>>>
> >
> which
> > >
> > >>>>
> > >>>>
> > >>
> > >>
> > >>>> message to request.
> >
>>>> (4) Is this a generic solution (i.e. can the RMD
>
request messages
> > >>>>
>
> >>>>
> > >>
from
> > >>
> > >>
>
> >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> >
>>>> the RMS in all cases) or special cased to anonURI
scenarios?
> > >>>>
> > >>>>
Paul
> > >>>>
> > >>>>
> > >>>>
> >
>>>>
> > >>>>
> > >>>
> >
>>>
> > >>>
> > >>
> > >>
> > >
> > >
> >
> > --
> >
> > Paul Fremantle
> > VP/Technology, WSO2 and
OASIS WS-RX TC Co-chair
> >
> >
http://feeds.feedburner.com/bloglines/pzf
> >
>
>
> > "Oxygenating the Web Service Platform", www.wso2.com
>
>
> >
>
> --
>
> Paul Fremantle
>
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
>
http://feeds.feedburner.com/bloglines/pzf
>
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
>
