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] i089 again...



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


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