ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx] i089 and polling
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Thu, 11 May 2006 10:20:18 -0400
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]