OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-rx] Minimalist GetMessage proposal: the anon use case


Doug

RM is designed to compose to add reliability. If you can explain how 
your pub/sub model works with an anonymous endpoint I can explain how my 
proposal composes to add reliability.
For the one-way and request-response MEPs that the minimalist proposal 
was designed to address, its completely clear how they work without RM 
and how my proposal composes with the existing model.

Paul

Doug Davis wrote:
>
> Colleen,
> IMO, pub/sub is mentioned as good examine of an out-only MEP. There 
> are plenty of use-cases where out-only MEP applies, its just using the 
> term pub/sub or notifications is just an easy way for people to 
> quickly put their mind into that MEP. :-)
> -Doug
>
>
>
> *"Colleen Evans" <coevans@microsoft.com>*
>
> 05/09/2006 01:57 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
>
>
>
> 	
>
>
>
>
>
> 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
> > > > > >

-- 

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]