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

 

  • 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

 

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]