It’s not clear what pub-sub model you’re
proposing Doug. Pub-sub wasn’t mentioned in the issue when it was
raised. The arguments to support your proposal are stretching the surface
area of the issue to an extent that’s becoming very confusing and concerning.
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Monday, May 08, 2006 9:58 AM
To: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] Minimalist
GetMessage proposal: the anon use case
Doug.Bunting@Sun.COM
wrote on 05/08/2006 10:43:11 AM:
> Dug,
>
> On 08/05/06 05:19, Doug Davis wrote:
> > DougB,
> > Who said reliable notif w/o
reliable subscription?
> You did, when you pointed to
"problems" with reliable notifications
> which relate only to the case in which the
destination system did not
> offer a sequence. That destination
system would be unknown only in the
> case where it had not subscribed.
Perhaps I
view the reliable notification issue differently. I see
there being
two different interactions, one for the subscribe and
one for the
sending of the notifications - and since the entity
doing the
subscribe may not be the same entity receiving the notifications
I think its
valid to look at it that way. So, whether or not the
Subscribe()
itself was sent reliably isn't really the side of the problem
I've been
focused on - I think that part is easy - its just normal
request/response.
Its the sending of the notifications reliably that is
harder.
So, if the
proposed solution is that the subscriber send the Subscribe()
in some
sequence and the notifications then use the Offered sequence
associated
with that original sequence - I'm not sure how viable that is
when the
subscriber and the event sink may not be the same entities.
If people's
position is that they 'should' be able to share the RM sequence
then did we
not just introduce a case of more than one anon endpoint
using the
same sequence - something Paul's proposal doesn't support.
If they
don't have to use the same sequence, then how did the
notification
sender create new sequences?
> > Its too bad you think things like
reliable notifications,
> > unreliable-in/reliable-out,
> > out-only, allowing an RMS to choose
which sequence a message goes into...
> > are all 'bizarre'.
> > I would point out that most of my
questions on paul's proposal were
> > simply based
> > on trying to understand how someone
would actually implement it. Its
> > interesting
> > in theory to simply say "oh, just
have the client send an Offer and
> > the server can
> > use that" - when in practice I
think I've shown there are lots of open
> > questions around
> > using some of the technique Paul has proposed.
And yes, I agree its
> > confusing
> Most of those questions, especially about
when the client (destination)
> knows to offer a sequence apply equally to
your proposal. When does the
> destination know to poll?
True - to a
degree. Yes, both proposals require the destination to know
when to
poll. I'm not sure that part can ever be avoided. If you can
think of a
way I'd love to hear it and try to change it accordingly.
But, how
much additional knowledge is needed for each proposal? One
just
requires the knowledge that polling is needed, the other requires
quite a bit
more, IMO.
BTW - I'd be
very interested in hearing which of those questions you
think apply
to our proposal. We've been under the impress that they
don't and
I'd like to get the feedback.
> > because this "narrowly scoped"
proposal is claiming to do things its
> > just not possible
> > to do (as currently defined anyway).
The other proposal, in my
> > unbiased opinion :-),
> > is not confusing, it does just one very
simple thing - creates a
> > backchannel which is
> > at the heart of issue 089. It doesn't
try to do anything more than
> > that, which is why
> > all of the types of questions that have
been raised with Paul's
> > proposal do not
> > exist in ours. I think it would
fairly easy to claim that Paul's
> > proposal actually goes
> > well beyond the scope of i089 because
if, in the end, his proposal
> > does things like
> > links two sequences then we're no longer
just dealing with anon EPRs.
> Without section 4.2 of Paul's proposal, I
don't think that's the case.
> Nor do I think the "heart of issue
89" is about a generic back-channel
> for any and all messages one system may have
queued for another.
Our proposal
is scoped to, and focused on, the RM use-cases that
use anon
EPRs - not what you described.
> thanx,
> doug
> > -Doug
> >
> >
> > Doug.Bunting@Sun.COM wrote on 05/08/2006
01:19:20 AM:
> >
> > > This is all very confusing but I
think can be summed up thus: Dug's
> > > proposal does more than WS-RM
protocol or the WS-RX TC charter needs or
> > > allows. Paul's proposal
doesn't do everything Dug wants. Did I miss
> > > something?
> > >
> > > As a number of people on the last
call noted, most of us are listening
> > > to an argument with no clear
movement toward a compromise. I hope Paul
> > > and Dug are having offline
discussions to reach a conclusion the
> > rest of
> > > us can support.
> > >
> > > If we must implement something on
the table now, I prefer the more
> > > narrowly scoped proposal. I
have yet to hear justification for the
> > > bizarre scenarios you're describing
Dug. (Reliable notification
> > without
> > > reliable subscription, why?)
> > >
> > > thanx,
> > > doug
> > >
> > > On 07/05/06 18:38, Doug Davis
wrote:
> > > > So, for every request message
that had a response there would have
> > to be
> > > > a GetMessage? 10
requests == 10 GetMessages? Doesn't seem
> > optimal :-)
> > > > Or if you mean that a
GetMessage+msgID can pull back any response
> > related
> > > > to any request from the
client->server seq, then how long does the
> > > > server need
> > > > to maintain this state info?
It would need to save every request
> > > > msgID since it
> > > > might appear later on in a
GetMessage.
> > > >
> > > > And, even if it did, can it
really make any assumption about that
> > > > message and any
> > > > message flowing in the other
direction? Remember, under normal
> > > > circumstances an
> > > > RMS could decide, for any
variety of reasons, why a message goes into
> > > > a sequence.
> > > > You seem to be implying that
by passing in a msgID that _all_
> > > > responses related to
> > > > any message associated with
the client->server seq (as correlated by
> > > > this msgID)
> > > > MUST then use this Offered
sequence - seems a bit restrictive.
> > Or, if
> > > > not MUST, then
> > > > it at least implies that it
SHOULD, and if not either of those then
> > > > what other sequence
> > > > can the server use since the
client has no way of knowing when to
> > > > Offer any other.
> > > >
> > > > I really don't understand the
point of the Offered sequence as
> > > > currently specified in
> > > > your proposal. Without any
additional correlation info what can the
> > > > server possibly
> > > > assume its used for? It
doesn't know which endpoint sent it. It
> > > > seems like the only
> > > > option available with your
proposal is the Offered sequence of the
> > > > original
> > > > client->server CS msg - and
if either of those sequences
> > > > close/terminate early then
> > > > all bets are off. And I
think it links the two sequences pretty
> > > > tightly - something I thought
> > > > we were trying to avoid.
> > > >
> > > > -Doug
> > > >
> > > >
> > > > Paul Fremantle
<paul@wso2.com> wrote on 05/05/2006 01:14:38 PM:
> > > >
> > > > > Actually that was exactly
the motivation for allowing the
> > GetMessage to
> > > > > include a messageID for
relatesTo matching. However, I am not yet
> > > > > convinced that the use
case of an anon client shared across multiple
> > > > > endpoints is really so
useful. I can't imagine a case in which this
> > > > > would be necessary. The
scenarios for a shared sequence across an
> > > > > endpoint seem to imply
some cluster of machines or corporate
> > gateway
> > > > and
> > > > > these usually have well
defined endpoints. Alternatively, its
> > possible
> > > > > that a gateway could do
its own correlation of responses back to the
> > > > > correct endpoint.
> > > > >
> > > > > If you can persuade me
that this is a highly valuable and very
> > > > important
> > > > > scenario I'd be happy to
add the <wsa:MessageID> back into the
> > proposal
> > > > > which would fix this.
However, at the moment I would lean towards
> > > > adding
> > > > > a warning "here be
dragons", that alerts implementors to this issue.
> > > > > Since the situation is
purely initiated by the "client" then a
> > client
> > > > > RMS should not initiate
an offered anonymous sequence if it is
> > not able
> > > > > to distribute the
messages to the right endpoint.
> > > > >
> > > > > Paul
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Doug Davis wrote:
> > > > > >
> > > > > > Maybe I didn't
follow the thread but I thought the problem
> > related to
> > > > > > how, when a
> > > > > > client sends a
GetMessage, does the server know which client is
> > > > > > sending the
> > > > > > message? It
can't just send any message in the sequence to any
> > > > client
> > > > > > who
> > > > > > happens to be an RMD
for that sequence. If the RMD spans multiple
> > > > > > endpoints
> > > > > > the server needs to
make sure that the messages for clientA go to
> > > > > > clientA and
> > > > > > not clientB.
SequenceID alone isn't enough - so what other
> > > > > > correlation does
> > > > > > Paul's proposal use?
Or is the answer that Paul's solution only
> > > > works
> > > > > > for
> > > > > > one endpoint per
sequence? If so, we have yet another
> > restriction on
> > > > > > the use-cases
> > > > > > that it supports.
> > > > > >
> > > > > > -Doug
> > > > > >
> > > > > >
> > > > > >
> > > > > > *"Marc Goodner" <mgoodner@microsoft.com>*
> > > > > >
> > > > > > 05/04/2006 09:22 PM
> > > > > >
> > > > > >
> > > > > > To
> > > > > > Doug
Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
> > > > > > cc
> > > > > >
> > > > > > Subject
> > > > > > RE:
[ws-rx] Minimalist GetMessage proposal: the anon use case
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > So how does telling
the other side where to send the RM protocol
> > > > > > messages not solve
the problem you perceive Doug?
> > > > > >
> > > > > > Marc Goodner
> > > > > > Technical Diplomat
> > > > > > Microsoft
Corporation
> > > > > > Tel: (425) 703-1903
> > > > > > Blog:
_http://spaces.msn.com/mrgoodner/_
> > > > > >
> > > > > >
> > > >
> >
------------------------------------------------------------------------
> > > > > >
> > > > > > *From:* Doug Davis
[mailto:dug@us.ibm.com] *
> > > > > > Sent:* Thursday, May
04, 2006 6:17 PM*
> > > > > > To:*
ws-rx@lists.oasis-open.org*
> > > > > > Subject:* RE:
[ws-rx] Minimalist GetMessage proposal: the anon
> > use
> > > > case
> > > > > >
> > > > > >
> > > > > > If I remeber
correctly, that part of the spec just tells the other
> > > > > > side where to send
RM protocol messages to for the Offered
> > sequence -
> > > > > > since it otherwise
has no idea where they go.
> > > > > > -Doug
> > > > > >
> > > > > > *"Durand,
Jacques R." <JDurand@us.fujitsu.com>*
> > > > > >
> > > > > > 05/04/2006 07:39 PM
> > > > > >
> > > > > >
> > > > > > To
> > > > > > Doug
Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
> > > > > > cc
> > > > > >
> > > > > > Subject
> > > > > > RE:
[ws-rx] Minimalist GetMessage proposal: the anon use case
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > That crossed my mind
too…
> > > > > > But then the spec
seems to rule that case out in case of offered
> > > > > > sequences, given the
exclusive scoping to one endpoint assumed by:
> > > > > >
wsrm:Offer/wsrm:Endpoint (WD12, Line283)
> > > > > >
> > > > > > Jacques
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> >
------------------------------------------------------------------------
> > > > > >
> > > > > > *
> > > > > > From:* Doug Davis
[mailto:dug@us.ibm.com] *
> > > > > > Sent:* Thursday, May
04, 2006 3:53 PM*
> > > > > > To:*
ws-rx@lists.oasis-open.org*
> > > > > > Subject:* RE:
[ws-rx] Minimalist GetMessage proposal: the anon
> > use
> > > > case
> > > > > >
> > > > > >
> > > > > > I'm a bit lost - too
much email on this today :-) but even if
> > there
> > > > > > as a wsrm:Identifier
> > > > > > in a message that
doesn't tell you which client it is since a
> > > > sequence
> > > > > > can span
> > > > > > multiple endpoints.
> > > > > > -Doug
> > > > > >
> > > > > > *"Durand,
Jacques R." <JDurand@us.fujitsu.com>*
> > > > > >
> > > > > > 05/04/2006 03:17 PM
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > To
> > > > > >
"Paul Fremantle" <paul@wso2.com>
> > > > > > cc
> > > > > >
"wsrx" <ws-rx@lists.oasis-open.org>
> > > > > > Subject
> > > > > > RE:
[ws-rx] Minimalist GetMessage proposal: the anon use case
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > - The case
reliable-in/reliable-out works quite well, provided
> > the RMS
> > > > > > does the correlation
between initial sequence and offered seq, as
> > > > > > recommended in 4.2.
> > > > > > - The case
unreliable-in/reliable-out seems to need the "hint" you
> > > > > > mention in 4.2.,
plus some other way to offer a sequence than
> > the CS
> > > > > > carrier.
> > > > > >
> > > > > > In any case, the
many-anonymous(RMD)clients- to-one-(RMS)server
> > > > appears
> > > > > > to be quite a common
case (many users of the same WS instance), to
> > > > > > justify adding back
4.2 in your proposal...
> > > > > >
> > > > > > Jacques
> > > > > >
> > > > > > -----Original
Message-----
> > > > > > From: Paul Fremantle
[mailto:paul@wso2.com]
> > > > > > Sent: Wednesday, May
03, 2006 11:15 PM
> > > > > > To: Durand, Jacques
R.
> > > > > > Cc: wsrx
> > > > > > Subject: Re: [ws-rx]
Minimalist GetMessage proposal: the anon
> > use case
> > > > > >
> > > > > > Jacques
> > > > > >
> > > > > > You are quite right.
This is an interesting situation. One of the
> > > > > > problems is that we
do not in this spec define how messages are
> > > > > > allocated to
sequences. The IBM proposal simply shifts this
> > problem to
> > > > > > the EPRId as you
point out.
> > > > > >
> > > > > > In one of my own
early drafts of the proposal I had these words in
> > > > > > section 4.2, but I
removed them for simplicity. However, if
> > they are
> > > > > > useful they could be
added back.
> > > > > >
> > > > > > "The WSRM
specification does not define the allocation of
> > messages
> > > > to a
> > > > > > sequence. In the
case of reliable request-response with an
> > anonymous
> > > > > > client, the server
MAY make a correlation between an incoming
> > sequence
> > > > > > and an offered
sequence. In the case where the request message is
> > > > > > unreliable, and the
client is anonymous, there might not be a
> > clear
> > > > > > basis to allocate
messages to a given sequence. In this
> > scenario the
> > > > > > client MAY add the
<wsrm:Identifier> of the offered sequence
> > as a SOAP
> > > > > > Header element or
elsewhere in the message as a hint to the
> > server."
> > > > > >
> > > > > > Paul
> > > > > >
> > > > > > Durand, Jacques R.
wrote:
> > > > > > > Paul:
> > > > > > >
> > > > > > > Are you sure
this works when two different (un-addressable)
> > clients
> > > > > > are
> > > > > > > sending an
anonymous wsrm:Offer/wsrm:Endpoint to the same
> > RMS-to-be
> > > > > > > endpoint, say
for offering sequences S1 and S2?
> > > > > > > The offered
sequences S1 and S2 have to be clearly associated
> > > > from the
> > > > > > > start with the
right client-RMD, by the server-RMS.
> > > > > > > With an in/out
pattern where the in message is not sent
> > > > reliably, how
> > > > > > > would the
server-RMS know if it should use S1 or S2 when
> > sending the
> > > > > > out
> > > > > > > message for an
in message of one of the two initiators?
> > > > > > > Don't we still
face the same issue of distinguishing anonymous
> > > > > > endpoints
> > > > > > > that IBM
proposal tries to address ( with wsrm:EPRid) ?
> > > > > > > (Do I miss
something?)
> > > > > > >
> > > > > > > Jacques
> > > > > > >
> > > > > > > -----Original
Message-----
> > > > > > > From: Paul
Fremantle [mailto:paul@wso2.com]
> > > > > > > Sent:
Wednesday, May 03, 2006 12:05 PM
> > > > > > > To: wsrx
> > > > > > > Subject: [ws-rx]
Minimalist GetMessage proposal
> > > > > > >
> > > > > > > Based on some
of the discussions it seemed to me that it
> > could be
> > > > > > > valuable to
produce a completely "minimalist" GetMessage
> > proposal.
> > > > > > >
> > > > > > > This is a new
proposal that is based on the previous WSO2
> > proposal.
> > > > > > >
> > > > > > > The proposal
removes the MessageID selector in the GetMessage -
> > > > > > relying
> > > > > > > on simply
getting whatever message the server sends back next.
> > > > > > >
> > > > > > > Also it removes
the section 4.2. Effectively section 4.2 is an
> > > > > > > optimisation:
for example to support
> > unreliable-in/reliable-out a
> > > > > > client
> > > > > > >
> > > > > > > could do a
createsequence+offer and never use the outgoing
> > sequence.
> > > > > > In
> > > > > > > this case there
is an overhead, which 4.2 aimed to remove,
> > but this
> > > > > > > simplifies the
proposal by focussing on the bare minimum
> > required to
> > > > > > > support the most
common use cases, but still allowing the
> > other use
> > > > > > case
> > > > > > >
> > > > > > > with a slight
overhead.
> > > > > > >
> > > > > > > I've also
included a sample message flow which I hope helps
> > > > understand
> > > > > >
> > > > > > > the proposal
and show the general usage.
> > > > > > >
> > > > > > > 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
> > > > >