[graap-wg] asynchronous binding

[Karl Czajkowski]

On Feb 17, Takuya Araki (Biglobe) loaded a tape reading:
> 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.
> 

I agree with your summary.  I have a question: would the binding-level
method I propose be satisfactory for the asymmetric (no initiator-side
endpoints) case?  What I propose is that we leave the current model
more or less untouched and focus on reintroducing/repairing the
symmetric peer-to-peer creation mechanism to address asynchrony at the
WSDL level.

I went through the public draft very carefully on a long flight the
other day and realize there are a number of problems relating to the
underspecification and inconsistency of the symmetric case.  The
creation input's optional "initiator EPR" is useless as the spec
stands!  I think some related state information was removed in the
effort to get rid of negotiation, and this part was overlooked.

I am not 100% sure how much overlap there is between this and your
proposal, so let me phrase it in terms of adjustments to the public
draft that I have been reading:

   1) Remove the optional "initiator EPR" from the createAgreement()
      input.  The simple createAgreement() is always asymmetric.

   2) Introduce a new FOO() operation which has a mandatory
      "acceptance EPR" field along with the offer and which outputs an
      empty message (ACK) or fault.  A fault indicates that the offer
      cannot be considered, e.g. the initiator should not expect any
      further messages regarding this offer.

   3) The acceptance EPR must address an endpoint providing two new
      operations:

         -- acceptAgreement() which takes as input the EPR to the
            newly formed Agreement provided by responder, e.g. the
            same EPR that would have appeared in the simple
            createAgreement output

         -- rejectAgreement() operation which takes a fault as input,
            e.g. the same fault that would have appeared in the
	    simple createAgreement output

   4) the responder MUST drive the acceptAgreement() operation on the
      acceptance EPR to accept, or the rejectAgreement() operation to
      reject, once he has made his decision.

I think this is in the spirit of the original spec drafts and the
whole idea of symmetric parties.  To make it completely symmetric:

   5) the acceptAgreement() operation outputs the EPR of an Agreement
      provided by the initiator, allowing both parties to know an
      Agreement EPR hosted by the other party to which further
      Agreement-related operations can be directed.  This becomes an
      underpinning for future extensions where the parties can signal
      more interesting Agreement conditions/changes to one another.

I called it "Foo()" above because the naming depends on what is
decided for this last feature.  I would call it
createSymmetricAgreement if we included (5).  I would call it
something like requestAgreement if we do (1)-(4) only.

I continue to be uncomfortable using the words "synchronous" or
"asynchronous" to name message patters because they are always
asynchronous in the WS architecture.  I think synchrony only makes
sense when talking about APIs where control is passed from one piece
of code to another.


> Are you talking here about API level asynchrony? 

I am stating that some recurring discussions come from people trying
to address API-level concerns in the WSDL instead of in the tooling
where they belong.  I was not sure if you were stating any of these
arguments or not.


> If so, API level asynchrony is also important, but what we are 
> discussing is transport level asynchrony, I think.
> 

Good, I think we are on the same page then.


> (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...)
> 

It's an API concern, which is why I brought it up as a response to
those trying to address API asynchrony.  Of course, transport
asynchrony depends on binding protocol rather than a WSDL->API
translation scheme.


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

No, I was merely trying to state that we would have to consider what
we are doing if we introduced some two-level factory scheme, e.g.  an
initial "lightweight" factory create call that returns the EPR of a
new "pending request" resource which the client can poll to find the
eventual "accepted agreement" EPR.  I don't think this would be that
much more powerful than the binding-level solution I have promoted,
and it opens the can of worms as to what is the lifecycle of a
"pending request".

Another way of rendering this two-level scheme would be to just return
the Agreement EPR in a new enhanced lifecycle where it has not been
accepted yet. An asynchronous state-change can indicate whether it is
accepted or rejected once the provider knows. This is pretty much what
our original state machine model looked like before we factored out
negotiation. :-)  It also happens to be what GRAM does today. :-(


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

I suppose you may be right.  We have not done much testing with long
creation delays, because our current GRAM submission semantics are not
exactly analogous to Agreement.


> 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.)

I had not really considered that holding HTTP connections open would
be a scalability problem... I know most browsers do it by default
these days and I assume binding-level technology will be improved as
needed as the WS methodology matures.  But I will accept that it could
be a practical limit today.

Would a corrected version of the symmetric agreement mechanism satisfy
your needs here, or do you also still feel that a two-phase creation
mechanism must be available for asymmetric initiators who will not
host any WS-Agreement related endpoints?


karl

-- 
Karl Czajkowski
karlcz at univa.com