[graap-wg] asynchronous binding

[Takuya Araki (Biglobe)]

Karl:

Thank you for your comment.

Here is summary of my understandings:

* I agree with that the asynchronous operations should be
  implemented at the binding level if there are proper tools.
  - Here, you think there are such tools
  - My opinion is currently available tools are not enough for this purpose

* Your suggestion is to implement asynchrony by "polling";
  "message ID" of WS-Addressing can be used to know the uniqueness
  of the message (, which corresponds to "correlation ID" of my proposal) 
  The difference from the polling method of my proposal is:
  - It is not visible on WSDL level (so there is no impact on the spec)
  - On the transport level, it uses a normal synchronous operation;
    when it timeouts, the same message is sent using the same massage ID again.

  - Here, your opinion is this suggestion solves the problem.
  - My opinion is this is useful, but might not be enough to handle time consuming 
    agreement creation.

I understand your opinion that this kind of "implementation issue" should not
affect the specification. However, I feel it is in the future that proper tools
solves the problem completely. Therefore, I believe that the WSDL level solution 
is useful to implement practical systems using currently available tools.

My proposal is perfectly optional, and can be safely ignored if you don't like it.

Some other comments are in line:

>...
> First, one camp confuses the WSDL message protocol with an 
> API specification, so they believe that a WSDL "in-out" 
> message must mean a blocking procedure call in their client 
> bindings. They are uncomfortable with the implication that a 
> long delay cannot be processed asynchronously by their 
> application.  We believe this is a mistaken viewpoint to take 
> when designing protocols, because the asynchrony of the 
> client can be addressed simply by using an appropriate 
> tooling strategy.
> 
> They should move to better tooling if their existing client 
> stubs are indeed this limiting. For example, the C language 
> WS tooling in GT 4.0 generates synchronous and asynchronous 
> stubs for each WSDL operation, so our GT 4.0 GRAM client tool 
> is able to perform the creation message exchange using 
> asynchronous "post message" and "response callback"
> programmatic interfaces. The newest JAX RPC revision also is 
> said to have better support for asynchronous invocation.

Are you talking here about API level asynchrony? 
If so, API level asynchrony is also important, but what we are 
discussing is transport level asynchrony, I think.

(I checked the recent version of JAX RPC spec.  
It says it supports "a client level asynchrony", but I couldn't 
figure out if it also supports transport level asynchrony...)

> ...
> This approach does not permit visibility as to WHY the 
> response is taking so long, but merely visibility as to 
> WHETHER the response has been issued yet. There is no 
> lifecycle model in WS-Agreement for the decision making that 
> the Agreement provider performs while considering an 
> Agreement creation request, nor should we take lightly the 
> burden of trying to develop such a model.

Sorry, I couldn't catch the point of these sentences.
Are you saying that the WSDL level asynchronous operations
should manage some kind of lifecycle model in the provider?
If so, well, I admit that there is something which should be done
in the application level...

> > (By the way, it seems that GRAM has "batch mode" as an 
> application level asynchronous operation.
> > That's why the current method is enough for GRAM, I think.)
> 
> No, actually our "globusrun" tool's batch mode is not about 
> asynchronous submission.  It simply turns off the 
> subscription and state monitoring that the tool normally does 
> after submission.  The submission step itself is roughly 
> equivalent to the WS-Agreement createAgreement operation.

Sorry about the misunderstanding.
But my point is that GRAM does not use time consuming 
operations, which seems to be why the current method is enough for GRAM...

My concern about using your suggestion for operations which take a long time
is as follows:
* As I mentioned in the previous mail, a client program can't distinguish timeout
  caused by message layer problems; it just thinks that the operation is 
  taking a long time, and might retry forever.
  
* The server should keep the HTTP connection for the long period, 
  (though the connection is disconnected and reconnected periodically).
  That might be intolerably high overhead for the server, if there are a lot of 
  agreement creation requests. (Usually, there is a limit of number of HTTP 
  connection.)
--
Takuya Araki
Grid System Technology Group
Internet Systems Research Laboratories 
NEC Corporation
<t-araki at dc.jp.nec.com>