Re: [ws-rx] i089 proposal

[Doug Davis <dug@us.ibm.com>]

Paul Fremantle <paul@wso2.com> wrote on 04/28/2006
04:40:47 AM:
> 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.

Sort of.  While the differences in our GetMessage
messages pertain to the
different contexts (yours bring a seq, ours being
an EPR), I think that one
difference has a very large impact on the available
use-cases each will
support.

> 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.

Yes but that generality is needed in order to support
RM-specific
scenarios too.

> 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?

In general an RMS has the ability to make the following
decisions:
- whether to try to use RM or not for any particular
message
- which sequence to use for any particular RM-enabled
message
- when to create a new sequence
Your proposal doesn't allow for these decisions to
be made without the 
client, somehow, being aware of what the server decided
to do.
As to your specific question, there are several cases
that come to mind:
- use of different sequences based on the soap version
(mentioned at the f2f)
- creation of a new sequence to prevent interference.
For example,
  I've heard of use-cases where people want to
put large messages into
  their own sequences since in some environments
they may have a hard
  time being delivered and that shouldn't hurt
smaller messages
- sequence number rollover
- server-side initiated message flows - meaning not
everything sent from
  the server is a WSA reply.  E.g. Using
the anon EPR in a Subscribe().
  Our proposal would allow for RM-enabled events
to endpoints behind
  firewalls
- rarely connected anon client needing to 'phone home'
from time to time
  to download messages targeted to it.  It
doesn't make a lot of sense
  to have this client always offer a sequence
when it may never be used.
  It doesn't know if there are RM-enabled messages
needing to be sent - all
  it wants to do is say "send me what ya
got" and if one of those happens
  to be a CS because some messages need to be
sent with RM then it works.
I'm sure there are lots more.

> 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.

I agree that it is a change but I think of it more
like an addition instead
of a change to the current processing model.  I
think your proposal is more
of a change to the current processing model because
it limits what choices
are available to the RMS(on the server) under certain
conditions - ie. the
RMS would now need to change its decisions making
process based on the 
anon EPR.  Ours doesn't require that kind of
change rather ours focuses
on simply the means by which the messages are delivered,
not on the types
of messages delivered.

> 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.

I disagree - even the small list above, IMO, shows
a need for them.

> 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 <paul@wso2.com>*
> >
> > 04/27/2006 05:51 PM
> >
> >    
> > To
> >    Marc Goodner <mgoodner@microsoft.com>
> > cc
> >    wsrx <ws-rx@lists.oasis-open.org>
> > 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:paul@wso2.com]
> > > 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:paul@wso2.com]
> > >> 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:paul@wso2.com]
> > >>> 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:paul@wso2.com]
> > >>>> 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
> > paul@wso2.com
> >
> > "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
> paul@wso2.com
> 
> "Oxygenating the Web Service Platform", www.wso2.com
>