Re: [ws-rx] i089 and polling

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

Paul,
  Nice note :-)   So, without commenting
on whether your list of use
cases is complete or which ones each of us consider
'core', I'd like 
to examine the one you consider most important, #2
- reliable 
request/response, and a little bit of #3 - unreliabe-req/reliable-res.
  Comparing our two proposals I believe each
one would have the 
following aspects:

WSO2s:
  Client-RMS would be encouraged to include an
Offer in the CS it sends.
  Server-RMS would be encouraged to accept the
Offer.
  I say 'encouraged' in both cases because its
not clear how the 
  Client-RMD would know when an Offered sequence
is needed so to be safe
  one should always be there.
  While the Server-RMS can send RM-protocol msgs,
like Close, for the
  Offered sequence it isn't clear to me how the
Client-RMD knows whether
  or not a subsequence sequence needs to be established
for any remaining
  messages - or whether the Server-RMS is done.
 In this situation my mind
  keeping thinking about the cases of multi-responses,
optional RM-enabled 
  response, and the Faults from one-ways. 
  The optional RM-enabled responses is an interesting
one to me because
  it's part of the entire discussion around RM
processing model, or level
  of control an RMS can have while trying to
do its job.  In that
  category are all of the things we've talked
about on the mailing list:
  whether to use RM or not, which seq a msg goes
into, when to close
  a seq and start up a new one.  I strongly
believe these types of decisions
  should remain part of any RMS's job.  Your
proposal shift this 
  knowledge and/or decisions making, at least
in part, over to the 
  RMD side - and there's no mention of how it
this can happen.
  Also, even if it can determine when a new sequence
is needed, its not
  clear to me how the Server-RMS knows how to
use this sequence.  For example,
  which client machine initiated it? Can the
client always know the QoS
  aspects that are needed - like which security
context its supposed to use?
  Maybe it can since it might be able to infer
those things from the request
  side of things, but when the server-RMS has
optional QoS features available to
  it then its usually the one to decide these
things not the client-RMD.
  Here the use case I'm thinking of is a ping-type
of request and a real
  app message for the response.  The ping
doesn't usually need a lot of QoS
  things, like RM or maybe even a ton of security
(encryption?), but the
  response definitely does - and its usually
the sender of these messages
  that needs to make those decisions.  We
see this a lot in management use
  cases where the managed device can't phone
home so it needs to wait for a
  'ping' to open up the connection.

  So, aside from the sequence management aspects
of things, your proposal
  can then use GetMessage to get poll for the
next message.

  Now, even here there's a bit of an issue w.r.t.
developing a simple
  solution.  Yours would require a different
GetMessage for each active
  sequence. Now, I know you think only one would
ever be needed but I'm 
  not so sure based on the types of decisions,
stated above, we think
  an RMS may need to make.  So, I think
there's a bit of a performance
  and scalability issue here.

IBMs:
  Both of our proposals have similar issues in
that they both need to,
  somehow, know when to poll at all. I think
that decision can probably
  be the same in both implementations. However,
one of the biggest 
  differences is 'what to poll for'.  Ours
solves this issue by leaving
  it up to the sending endpoint to decide what
is appropriate - thus
  avoiding all of the issues stated above and
allowing a Server-RMS's
  sequence management decisions making logic
to remain the same whether
  it is in an async or sync world.  How
important that is may vary, but
  to us we think its very important.

  So, like yours, aside from the sequence management
aspect, our proposal
  can then use MakeConnection to poll for the
next message.

Based on these types of issues, IMO, our proposal
better satisfies
your (well stated) goal of finding the simplest,
clearest technical
proposal for the issue in front of us.

thanks
-Doug

Paul Fremantle <paul@wso2.com>

05/11/2006 07:47 AM

To	wsrx <ws-rx@lists.oasis-open.org>
cc
Subject	[ws-rx] i089 and polling

I started a new note chain, because this isn't a reply
to anyone's email 
in particular, but to the whole bunch of emails we've seen.

The charter is important to this discussion, but I would encourage us to
look at specific use cases and technical details first, and use the 
charter as the consistency check as we move forward. I think the main 
question before us is which use cases do we wish to satisfy.

The use cases we have seen discussed so far are:

1) Reliable in-only or reliable request only - this is already satisfied
by the spec
2) Reliable request-response
3) Unreliable request/reliable response
4) Reliable out-only
5) A sequence with an anonymous client RM Destination to be shared 
across multiple client endpoints
6) A server RMD to be able to initiate sequences with the client - e.g.
to support more than one sequence in the case of SOAP1.1 and SOAP1.2 
messages.

Of course there may be others that I have missed, but I think that is a
fairly comprehensive list.

I believe that Doug's proposal handles all of these scenarios.

My minimalist proposal aimed to support #2 as a primary use case. 
Section 4.2 (Offer on its own) was aimed at making it possible to 
support #3 and #4.

I still have a strong issue around #4 which is that there is currently
no way of supporting unreliable out-only with an anon client using any
of the specs or standards that WS-RM references, and so we cannot be 
said to be composing with an existing model to add reliability, which I
see as the main aim of this TC. I believe strongly that scenario #2 is
what we are aiming for as the primary objective.

The options for supporting scenarios 5 and 6 with my proposal are 
complicated. I have not been motivated by these scenarios as they seem
to be corner-of-corner-cases, and not focused on the core problem of 
enabling simple RM interactions from SMBs (such as WSO2) who do not have
publicly addressable URIs. However that is my opinion as a member of 
this TC on which use cases are important.

I propose that the TC decides which use cases are "must-have"
and which 
are "nice-to-have". I propose that we take the simplest, clearest
technical proposal that supports the must-haves, and treat any 
nice-to-haves that are enabled as a bonus. I agree that having positive
side-effects can be a good thing, but time and again the XP principal of
focussing on core requirements and not adding unnecessary functionality
has been shown to lead to more stable simple and secure systems. I 
actually think that is what Doug and I have done - simply that we have
started from different core requirements. Perhaps the most useful thing
the TC could do to make progress is agree on the core requirements.

Finally, I would like to ask the TC to try and address this issue in as
objective and peaceful manner as possible. I know I am as guilty as 
anyone of getting fired up over this, but I believe that the more we can
address this in a calm and objective manner the smoother our progress to
a standard will be.

Regards,

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