ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] i089 again...
- From: Doug Davis <dug@us.ibm.com>
- To: "Durand, Jacques R." <JDurand@us.fujitsu.com>
- Date: Sun, 21 May 2006 22:19:22 -0400
"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]