[graap-wg] updated draft - symmetry

Jon MacLaren maclaren at cct.lsu.edu
Wed Apr 6 10:26:37 CDT 2005


On Apr 5, 2005, at 8:58 PM, Karl Czajkowski wrote:

> On Apr 05, Jon MacLaren loaded a tape reading:
> ...
>> What kind of obligations can you have on the initiator side if "the
>> obligations in the agreement are not dependent on the initiator being
>> informed of the decision"?
>>
>> I can't reconcile these two ideas.
>>
>> Jon.
>
> The point is that there is a momentary hazard where the initiator is
> _possibly_ obligated and does not know whether the Agreement will
> happen or not.  If he is obligated to pay for service, he doesn't know
> whether he will need to present funds at some point... he might not
> want to spend them elsewhere, etc.
>
> In many cases, this hazard can be dealt with speculatively: by waiting
> for the answer.  Waiting is not a satisfactory speculative behavior if
> and only if the Agreement terms include real-time scheduling
> constraints at the same temporal granularity as the messaging, e.g. if
> waiting causes a violation.
>
> This is a theoretical corner case, and may not be a practical one if
> entities are conservative about the kinds of agreements they will
> negotiate, e.g. not trying to negotiate about services with hard start
> times that are "too close" to the present.

I agree with this statement.  As long as users don't try to agree 
things in too short a space of time, and as long as providers don't 
agree to this behaviour, there is no problem.

All the more reason, surely, not to chop out large pieces of capability 
- e.g. the role-reversal case - just for these marginal scenarios!

>  Another solution might be
> to deploy WS-Agreement in an environment with better messaging
> guarantees.  If messaging itself were trustworthy, it might make sense
> for there to be introspective terms in the Agreement that bound the
> responder's decision time (for example, the responder is in violation
> if he says "yes" too late). For many best effort cases, the waiting
> solution can mask this hazard since delay is not a violation for
> either party.
>
> I really don't know where to go with this discussion.  I've been
> making this point for years too... A phased approach cannot resolve
> this hazard: someone is always the last to know, and the other party
> doesn't know if he knows.  Pure transactions do not work in this kind
> of quasi-realtime problem where they cannot be rolled back, i.e. work
> cannot be undone and resources cannot be unspent.  Other compensation
> actions must be undertaken, e.g. pay a penalty, to offset the costs of
> the system thrashing and not doing real work.

Well, ultimately, it is for the group of authors to decide.  You are 
the ones doing the writing, and the ones doing the work.  I've tried to 
push a number of ideas into the specification from the position of 
being a member of the working group, but ultimately, I don't seem to 
hear anyone else from the group saying "Jon's right about this one."

I started reading the spec again when the public comment period came 
around, because I want whatever the GRAAP working group produces to be 
as good as it can be.  I intended at that time to stick to simple 
mistakes and inconsistencies, plus a couple of big gripes (e.g. the 
fact that everything is in one document).  Over the last couple of 
months though, I seem to have been drawn back into these old arguments 
again.

I think it's time for me to just let you get on with it again.

Good luck.

Jon.





More information about the graap-wg mailing list