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