[GRAAP-WG] Feedback on "Challenges in EU Grid Contracts"

[Karl Czajkowski]

Michael, I just read "Challenges in EU Grid Contracts" for the first
time after seeing it linked from Toshi's wiki page updates.  I thought
it might be useful to address several topics in the paper regarding
WS-Agreement, though I have a suspicion that some of these issues may
have been addressed long ago by others...

1. There is an assertion that WS-Agreement does not support
   acknowledgement of receipt of an offer independent of the
   acceptance decision.  This is incorrect, as the PendingAgreement
   construct is specifically defined for this purpose: the
   CreatePendingAgreement factory pattern returns an EPR to a
   PendingAgreement which is yet to be accepted or rejected.

   This feature was motivated by a different observation that a
   decision process might be too slow to perform during a
   SOAP-over-HTTP in/out message, but it equally addresses your
   concern of knowing that the offer was received before the decision
   process is complete. (A WS-* purist position could be that message
   acknowledgement is a transport-level problem rather than a SOAP
   problem, but we had to bow to the practical use of
   SOAP-over-HTTP...)

2. There is an allowance for external acceptance notification
   channels, though I admit this is not emphasized in the
   text. Present in the base protocol are the Acceptance port type and
   the agreement state resource property, both of which may be used
   simultaneously on the same agreement. It is the state model which
   allows for transitions to accepted state independent of the other
   protocol operations.  There is nothing to disallow other
   notification paths such as email, facsimile, registered mail, etc.
   (but, see next issue).

3. A significant difference between WS-Agreement and the contract law
   model described in the paper is the moment of acceptance: in
   WS-Agreement, acceptance is defined as the moment the responder
   chooses to accept, and is not dependent on sending an acceptance
   message to the initiator.  This difference becomes clear in unusual
   asynchronous/lossy message environments and/or contested
   agreements.

   This is a crucial technical point in WS-Agreement. In order to
   define the acceptance moment as when the acceptance is delivered to
   the initiator (as in your contract law discussion) would require a
   reliable delivery model where some trustworthy (third-party)
   observer can witness the delivery.

   At risk of confusing the terminology, a way to characterize such a
   variant of our protocol might be:

   1. initiator sends offer to responder.

   2. responder chooses to accept.

   3. responder attempts to send acceptance notice.

   4. reliable message channel observes delivery of (3) and acceptance
      is now true.

   Given our presumption of an Internet-like environment without any
   secure, third-party channel to "serve" notices, this does nothing
   more than "rotate" the participant roles by one unidirectional
   message.  In effect, it is really the "initiator" in step (4) who
   decides acceptance by choosing to receive the acceptance notice or
   not, because it is not possible to prove that he received a message
   unless he acknowledges it!  Thus, his offer is not really
   obligating, as he can shirk his responsibilities by choosing not to
   acknowledge the acceptance.

   Thus, I would say the above "contract law"-style sequence of:

      offer/accept/receipt-as-decision 

   is indistinguishable in practice from:

      invite/offer/accept-as-decision

   As there must be some party in the system that first knows the
   decision before this information is distributed asynchronously to
   all parties, we make the responder be the observer! Finally, as I
   described it in a previous email.  WS-Agreement supports this
   through the slightly more general:

      advertise/offer/accept-as-decision

   where you could restrict or otherwise optimize access to
   advertisements in order to effect a directed invitation.  (It is
   considered somewhat out of scope for WS-Agreement to define how
   advertisements are retrieved, e.g. what sort of publishing or
   information dispersal architecture is used for discovery.)


I hope this helps clarify the technical solution embodied in
WS-Agreement.


karl

-- 
Karl Czajkowski
Software Architect

Univa Corporation
1001 Warrenville Road, Suite 550
Lisle, IL 60532

karlcz at univa.com
www.univa.com
________________________________________________________________
www.univa.com.

The Leaders of Open Source Cluster and Grid Software