ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx] i089 again...
- From: Christopher B Ferris <chrisfer@us.ibm.com>
- To: "Durand, Jacques R." <JDurand@us.fujitsu.com>
- Date: Thu, 18 May 2006 08:00:09 -0400
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 CreateSequenceResponse
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.
- References:
- i089 again...
- From: "Durand, Jacques R." <JDurand@us.fujitsu.com>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]