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@dc.jp.nec.com>