RE: [ws-rx] i089 again...

[Christopher B Ferris <chrisfer@us.ibm.com>]

+1, but s/client/RMS/ below, just for
clarity:

> Actually, the client is the only one who knows
"when" or "if" a sequence
> is needed and also "how many" of them
will be needed.

should be

> Actually, the RMS is the only one who knows "when"
or "if" a sequence
> is needed and also "how many" of them
will be needed.

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 Davis/Raleigh/IBM wrote on 05/21/2006 10:15:23
PM:

> "Durand, Jacques R." <JDurand@us.fujitsu.com> wrote
on 05/18/2006 05:46:36 PM:
> > Chris:
> >  
> > I hear you that you are not aiming at a
general purpose polling 
> > feature, though you have to admit the example in Doug’s draft
can 
> > easily mislead the reader about this !… So maybe we (I) should
not 
> > pay too much attention to the last part of this example.
> > So far my main interest here is to narrow
the use cases that need be
> > considered, and I think that’s what we are doing here - so fine
with me.
> >  
> > > Actually, the GetQuoteResponse could
flow on the CreateSequenceResponse 
> > > HTTP response flow.
> >  
> > That could work for the first message of
the sequence, but certainly
> > more messages are to come over this seq. 
> > But it seems we may narrow the use cases
to only in-out (req-
> > responses) WSDL meps  - out-only is probably not relevant
for an 
> > anon polling situation (one less use case).
> >  
> > >By what magical means does the initiating
party know that it needs a 
> > > new Sequence? 

> > Well, doesn’t the mere existence of the
 “offer” feature assume that
> > this magic happens? when used, the destination is the one who
knows 
> > it is expecting to receive a sequence.
> > The spec makes no assumption on which party
has knowledge of the RM 
> > requirement. In case of in-out with reliable out, it is fair
to 
> > expect the sequence to be created before even the first “in”
message
> > is sent, and only the client knows when it will send the “in”
(may 
> > be awkward to suddenly make a CS available for polling in the
middle
> > of a synchronous in-out).  This client seems to me to have
as much 
> > reason as the server to know it will need a sequence.
> 
> Actually, the client is the only one who knows "when" or
"if" a sequence
> is needed and also "how many" of them
will be needed.  And this determination
> if something that should remain in the anon replyTo
case as well. When
> using just an Offer the server-RMS is limited
to just one sequence and
> nothing else. If that sequence is closed down
then its out of luck - it can
> not use another one without some magically knowledge
on the client-RMS's
> side to send another Offer.  And how the
server-RMS knows that that Offer
> is in any way related to one of possibly many
anon client-RMD's is also
> a mystery.  I believe this is the "magical"
piece that Chris was referring to.
> 
> > Again, a use case discussion here.
> >  
> > Thanks,
> > Jacques
> >            
                     
                     
                   
> >  
> > 
> > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
> > Sent: Thursday, May 18, 2006 5:00 AM
> > To: Durand, Jacques R.
> > Cc: ws-rx@lists.oasis-open.org
> > Subject: Re: [ws-rx] i089 again...
> >  
> > 
> > Jacques, 
> > 
> > Please see my inlined comments below. 
> > 
> > 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 
> > 
> > "Durand, Jacques R." <JDurand@us.fujitsu.com>
wrote on 05/17/2006 
> 10:43:06 PM:
> > 
> > > Doug: 
> > >   
> > > (stirring a thread that was just cooling down…) 
> > >   
> > > Although a general (soap-level) polling mechanism appears
a useful 
> > > thing, I tend to think that it is just too big a bite to
try to 
> > > squeeze in this TC deliverable, that late. 
> > 
> > Let's be perfectly clear, we are NOT proposing a general purpose
> > polling mechanism. We are proposing a mechanism that satisfies
the 
> > RM requirements; one that is scoped to use only in the context
of 
> > RM. 
> > 
> > >   
> > > Your example below (of which I reproduce a snippet) is making
use of the 
> > > MakeConnection signal for getting either an RM protocol
message, or 
> > > an application response GetQuoteResponse : 
> > >   
> > > Client sends MakeConnection+correlationEPR to server[I1]
> > > Server responds on http response with CreateSequence 
> > > Client sends a CreateSequenceResponse to server 
> > > Client sends a MakeConnection+correlationEPR to server 
> > > Server responds on http response with GetQuoteResponse 
> > 
> > Actually, the GetQuoteResponse could flow on the Cre ateSequenceResponse
> > HTTP response flow. 
> > 
> > >   
> > > I would think that a WS that has been designed with such
an out-only
> > > operation for late (async) responses, will be deployed with
an 
> > 
> > What makes you think that this is an out-only "response"?
IMO, it would 
> > be a WSDL request/response that is handled asynchronously. It
just happens 
> > that the address of the response message is the polling URI.
> > 
> > > appropriate SOAP binding to handle this, even in case of
anon 
> > > receiver (e.g. using something like a SOAP Response MEP
binding to 
> > > an HTTP GET, or a reverse HTTP binding like in PAOS, etc.).
> > > If not, given that MakeConnection signal is here positioned
to poll 
> > > any kind of message even out of RM scope, it is unclear
how a WS 
> > > instance is supposed to “get it”  (if it is not described
in WSDL, 
> > > are we assuming that another component will take care of
queuing 
> > > these out messages generated by the instance and that it
will 
> “understand” 
> > > MakeConnection?) . 
> > 
> > The server is supposed to "get it" because it is secified
in the RM spec, 
> > and because the URI of the address of the wsa:ReplyTo contains
the polling 
> > URI, which triggers the behavior. It need not be described in
WSDL. 
> > 
> > >   
> > > What I am getting at, is that we do not know yet if that
is a 
> > > suitable or desirable general mechanism for pulling any
message, and 
> > 
> > As I indicated above, we are NOT, I repeat, NOT aiming to design
a 
> > general purpose, solve world hunger, polling solution. We are
proposing 
> > one that satisfies the needs of RM, that allows for new Sequences
to 
> > be created as needed by the entity that is responsible for creating
> > Sequences; the RMS (at the server end of an HTTP connection).
> > 
> > > that unless we have a clear picture of how your example
will work, I
> > > would only limit polling requirements for the messages generated
by 
> > > the RMS-server (either RM protocol msg or cached “reliable”
app msg) . 
> > 
> > Which is exactly what has been proposed. 
> > 
> > >   
> > > So the proposal still has merits I think, but I would not
claim that
> > > it is a more general polling solution. 
> > 
> > See above; that is not our intent, and never has been. 
> > 
> > >   
> > > I also believe the argument that it let the RMS-server free
to 
> > > behave in the same way as an RMS-client is a bit weak: when
a 
> > 
> > How so? 
> > 
> > > message subject to reliability is pulled vs pushed, a good
deal of 
> > > RMS behavior will need be different anyway (even if out
of scope of 
> > 
> > How so? I suppose that if you conflate the act of generating
messages 
> > that need to be transferred with the act of establishing the
connection 
> > over which they will be transferred that there are differences.
However, 
> > if you consider only that the RMS is responsible for 
> >         - generating the CS 
> >         - (re)-transmiting messages within
a Sequence 
> >         - generating the other Sequence lifecycle
messages 
> > 
> > and that the binding is responsible for the actual act of transferring
> > the messages between the two endpoints, then I don't see how
you can claim 
> > that the RMS behavior needs to be different. 
> > 
> > > WS-RM) e.g. resending mechanism and policy. So the ability
to 
> > > generate a CS in both cases is only an apparent benefit.
In 
> > 
> > I would think that this is a significant benefit, because otherwise,
> > there is most certainly a change in what the RMS and RMD have
to do. 
> > 
> > > practice, there seems to be as much rationale for the party
> > > initiating an exchange to offer a sequence for the response,
as for 
> > 
> > By what magical means does the initiating party know that it
needs a 
> > new Sequence? 
> > 
> > > the responding party doing so. In particular, for rel-in/rel-out,
it
> > > would be risky to send the in message without knowing in
advance if 
> > > a sequence can be obtained for the out. The offer is best
for that. 
> > 
> > We have not suggested that Offer cannot be used. However, in
the event 
> > that the offered Sequence is prematurely terminated, there will
be a need 
> > to establish a replacement Sequence to convey the responses.
I believe that 
> > Doug has made the case that the RMD might not always be aware
of the 
> > need to create a replacement offered Sequence (e.g. if the RMS
at the 
> > server end is the one that terminates the previously offered
Sequence 
> > and has not yet been able to convey the fault to the RMD, etc.
Furthermore, 
> > there is also the possibility that the offered Sequence could
become 
> > unknown to the RMS at the server end (and this does not necessarily
mean 
> > that the corresponding Sequence would have become unknown...
it could 
> > be that an idiot came along and administratively deleted the
> offered Sequence
> > by mistake). 
> > 
> > > Now for nonrel-in/rel-out your proposal is best so far –
though I 
> > 
> > Exactly. 
> > 
> > > think the offer could be decoupled from CS. (can someone
remind me 
> > > why CS was not designed as a SOAP header-only in the first
place so 
> > > that it can be piggybacked??) 
> > >   
> > >   
> > > Jacques 
> > > 
> > >  [I1]Note: same correlationEPR as before.