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,

Couple of questions:
A> Do you consider the use case of reliable messaging involving a
non-addressable RMD as within our charter? If not, then you need to
check the minutes of the Raleigh F2F where the TC agreed that this use
case is within our scope.

B> Do you think that Dug's proposal addresses the above use case? If
not, then you should be raising those technical points!

-- Sanjay 

> -----Original Message-----
> From: Doug.Bunting@Sun.COM [mailto:Doug.Bunting@Sun.COM] 
> Sent: Wednesday, May 10, 2006 22:55 PM
> To: Patil, Sanjay
> Cc: Doug Davis; ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] Minimalist GetMessage proposal: the anon use case
> 
> The subject of our Charter is (basically) whether a use case 
> needs to be 
> solved within this TC. I /strongly/ object to ruling 
> discussion of this 
> concern immaterial.
> 
> My basic technical difficulty with Doug's proposal is that 
> most of the 
> use cases it supposedly solves are out of scope. Paul's 
> proposal is much 
> more aligned with the work of this TC. It skates close to the 
> edge but 
> fits in my estimation; Doug's does not fit.
> 
> I could go into lower level details about Doug's proposal but 
> they are 
> irrelevant given the Charter.
> 
> On 10/05/06 22:43, Patil, Sanjay wrote:
> > Hi Doug,
> >
> > No, I am not proposing any charter change. If I were, I 
> would have made
> > it amply clear. 
> >
> > Basically, I am trying to discourage TC members from using spurious
> > charter related arguments to drive core technical issues. Taking the
> > risk of repeating myself -- I think that the TC members 
> should focus on
> > how a proposal solves problems within the scope of the 
> charter and not
> > on how the same proposal may be useful for solving problems 
> outside of
> > the charter!
> >
> > -- Sanjay 
> >
> >   
> >> -----Original Message-----
> >> From: Doug.Bunting@Sun.COM [mailto:Doug.Bunting@Sun.COM] 
> >> Sent: Wednesday, May 10, 2006 19:01 PM
> >> To: Patil, Sanjay
> >> Cc: Doug Davis; ws-rx@lists.oasis-open.org
> >> Subject: Re: [ws-rx] Minimalist GetMessage proposal: the 
> anon use case
> >>
> >> Are you proposing a Charter change?
> >>
> >> On 10/05/06 18:48, Patil, Sanjay wrote:
> >>     
> >>> If a proposal happens to address other use cases (with no added 
> >>> complexity) beyond the current scope of an issue, that may 
> >>>       
> >> actually be 
> >>     
> >>> a better proposal, IMO. For example, it will help implementers in 
> >>> reusing the same underlying technology stack and 
> >>>       
> >> design/communication 
> >>     
> >>> patterns in building different solutions. At least that's what I 
> >>> sense as the general preference of the product teams in 
> my company!
> >>>  
> >>> Can we please focus on the technical aspects of how Dug's 
> >>>       
> >> (or other) 
> >>     
> >>> proposal addresses the stated problem. I don't think that 
> >>> applicability to problems that are not stated in our scope is a 
> >>> sufficient argument to shoot down any proposal. 
> >>>  
> >>> -- Sanjay
> >>>
> >>>     
> >>>       
> >> --------------------------------------------------------------
> >> ----------
> >>     
> >>>     *From:* Doug Davis [mailto:dug@us.ibm.com]
> >>>     *Sent:* Wednesday, May 10, 2006 14:17 PM
> >>>     *To:* ws-rx@lists.oasis-open.org
> >>>     *Subject:* RE: [ws-rx] Minimalist GetMessage 
> proposal: the anon
> >>>     use case
> >>>
> >>>
> >>>     Kill a simple idea because even though it solves our 
> >>>       
> >> problems, and
> >>     
> >>>     does so (IMO) w/o the complexity you fear, simply because it
> >>>     _might_ be used in other situations. wow
> >>>     
> >>>       
> >> <http://www.google.com/search?hl=en&lr=&q=%22cutting+your+nose
> >> +off+despite+your+face%22>.
> >>     
> >>>     -Doug
> >>>
> >>>
> >>>
> >>>     *"Marc Goodner" <mgoodner@microsoft.com>*
> >>>
> >>>     05/10/2006 05:04 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
> >>     
> >>>
> >>>     	
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Yes but it is not tied to RM in any way besides it's 
> namespace.
> >>>     That is going to lead to it being used for non RM 
> applications.
> >>>     There be dragons.
> >>>      
> >>>     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:* Wednesday, May 10, 2006 2:05 PM*
> >>>     To:* ws-rx@lists.oasis-open.org*
> >>>     Subject:* RE: [ws-rx] Minimalist GetMessage proposal: 
> >>>       
> >> the anon use
> >>     
> >>>     case
> >>>      
> >>>
> >>>     Interesting... a generic polling mechanism should 
> >>>       
> >> consider things
> >>     
> >>>     like batching.  I suppose it could also do such other 
> >>>       
> >> basic things
> >>     
> >>>     like examine the wsa:ReplyTo so the polling response 
> >>>       
> >> could be sent
> >>     
> >>>     to someplace else. All these kinds of things could 
> make perfect
> >>>     sense for a general purpose polling mechanism.  I 
> wonder why our
> >>>     proposal doesn't do stuff like that?  Could it be 
> >>>       
> >> because its not
> >>     
> >>>     a general purpose polling mechanism?  Could it be that our
> >>>     proposal focuses on just one thing, the 
> >>>       
> >> re-establishment of a lost
> >>     
> >>>     backchannel? naaa  :-)
> >>>     -Doug
> >>>
> >>>     *"Marc Goodner" <mgoodner@microsoft.com>*
> >>>
> >>>     05/10/2006 03:59 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
> >>     
> >>>      
> >>>
> >>>
> >>>       	 
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Well Dave's mention below is the first I've seen. Why 
> >>>       
> >> is this such
> >>     
> >>>     a bad idea though? Returning multiple messages to a 
> client after
> >>>     it polls a mailbox location certainly seems a 
> reasonable design
> >>>     choice. Such an approach could compose well with 
> something like
> >>>     WS-Enumeration. Considerations like this need to be taken into
> >>>     account in any honest examination of designing a 
> general purpose
> >>>     polling mechanism.
> >>>      
> >>>     Of course this, and the other two proposals (from one person),
> >>>     just further illustrates to me why doing this in this 
> >>>       
> >> TC is a bad
> >>     
> >>>     idea. Polling is a general purpose mechanism that should be
> >>>     designed completely, not partially as it is in the 
> three current
> >>>     proposals that take that approach.
> >>>      
> >>>     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:* Monday, May 08, 2006 1:15 PM*
> >>>     To:* ws-rx@lists.oasis-open.org*
> >>>     Subject:* RE: [ws-rx] Minimalist GetMessage proposal: 
> >>>       
> >> the anon use
> >>     
> >>>     case
> >>>      
> >>>
> >>>     Blimey - who suggested that! :-)
> >>>     -Doug
> >>>
> >>>     *"David Orchard" <dorchard@bea.com>*
> >>>
> >>>     05/08/2006 03:47 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
> >>     
> >>>
> >>>      
> >>>
> >>>
> >>>       	 
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     One thing I do not want to see is boxcarring of 
> >>>       
> >> multiple responses
> >>     
> >>>     for a single "Get*" response.  
> >>>
> >>>     Blimey and crikey, what happens if the connection 
> fails partway
> >>>     through such a boxcarred response.  Argh and yuck.
> >>>
> >>>     Dave
> >>>      
> >>>
> >>>
> >>>
> >>>      
> >>>     
> >>>       
> >> --------------------------------------------------------------
> >> ----------
> >>     
> >>>     *
> >>>
> >>>     From:* Doug Davis [mailto:dug@us.ibm.com] *
> >>>     Sent:* Sunday, May 07, 2006 6:39 PM*
> >>>     To:* ws-rx@lists.oasis-open.org*
> >>>     Subject:* Re: [ws-rx] Minimalist GetMessage proposal: 
> >>>       
> >> the anon use
> >>     
> >>>     case
> >>>
> >>>
> >>>     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
> >>>     >
> >>>
> >>>       
> 


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