[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: i089 again...
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. 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 :
Server responds on http response with GetQuoteResponse 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 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?) . 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 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) . So the proposal still has merits I think, but I would not
claim that it is a more general polling solution. 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 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 WS-RM) e.g. resending mechanism and policy.
So the ability to generate a CS in both cases is only an apparent benefit. In
practice, there seems to be as much rationale for the party initiating an
exchange to offer a sequence for the response, as for 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. Now for nonrel-in/rel-out your proposal is best so far –
though I 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]