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

["Abbie Barbir" <abbieb@nortel.com>]

With this in mind, this whole TC should not be chartered (Since it just re-use what out there). I think we are a sitting Trout Fish for a law suit.

 

Abbie

 

---

From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, May 11, 2006 9:44 AM
To: Doug Bunting
Cc: Doug Davis; Doug.Bunting@Sun.COM; Patil, Sanjay; ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] Minimalist GetMessage proposal: the anon use case

If there was a TC chartered to solve 
the problem of allowing a man to lift a rock that weighed 
more than he, and a member of the TC proposed a new 
device (s)he called the "lever", that coincidently 
could also be used as an entertainment device for small 
children, should the proposed solution 
be ruled out? 

I would 
think/hope not. 

That said, I did not 
read anything in the thread below that even remotely suggested a charter change 
until 
DougB's note. Did I miss 
something? 

Cheers, 

Christopher Ferris
STSM, Software Group 
Standards Strategy
email: chrisfer@us.ibm.com
blog: 
http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 
377 9295 

Doug.Bunting@Sun.COM wrote on 
05/10/2006 10:01:16 PM:

> 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
> >     
>
> >