short summary of ws-agreement for BES call

[Karl Czajkowski]

I thought I'd give an extremely compact summary of WS-Agreement for
those not having the time to read the spec in depth.  Hopefully this
will help you skim through and see the important points...

The fundamental conceptual model is that a wsag:agreement document
describes a relationship between two parties about some arbitrary
domain-specific service(s) using an appropriate mixture of
domain-specific and generic content.

  1. Context: who are the parties, etc.

  2. Service Description Terms: what is the nature of the service
     relationship between the parties.

  3. Guarantee Terms: optional statements about performance levels,
     penalties, rewards, etc.

  4. Other specialized terms: open content for futuristic things.

All of the terms are expressed together in a logical composition
language that has the usual suspects like ALL, ONE, etc.  The main
service description term is where a JSDL document would fit.  The
other term types can support reference back to the service description
terms to in effect "annotate" them with additional assertions/metrics.

In addition to the document model, WS-Agreement defines a stateful
protocol for reaching "acceptance" of an agreement and for monitoring
ongoing status of the agreement relationship.  The acceptance process
is the binary decision where both parties agree to be engaged in the
described relationship.  WS-Agreement defines one signaling model
with two concrete renderings: the "initiator" prepares an offer to
which he is pre-committed, and the "responder" considered the offer
and either accepts or rejects.  If the responder accepts, the
initiator must observe the agreement.  If the responder rejects, the
initiator is under no obligations.  Due to lack of specification of
real-time signaling requirements nor reliability, there is an
inherent hazard interval where the initiator does not know what the
responder's decision is (or will be).  If the terms of agreement
include "wall clock" scheduling requirements, the initiator may be at
risk of violating when the acceptance comes too late, or of wasting
resources if he proceeds speculatively.

These protocol roles are orthogonal to the domain-specific service
roles. It is more general than the client-server idiom we probably
want in BES, e.g. you could render an environment where the
WS-Agreement client is the job-executing "host" and the WS-Agreement
service is the job-defining client!  I mention this only to avoid
confusions in later discussions... we want to keep clear the
WS-Agreement roles of "initiator" and "responder" from the OGSA-BES
roles of job-submitter and job-executor.  Ideally, I think a BES model
based on WS-Agreement would support both usage modes, but I understand
if that is considered out of scope of the "basic" service.

As I said, there are two concrete renderings of the acceptance
handshake:

   A. AgreementFactory has wsag:createAgreement operation

      input: agreement offer
      output: agreement resource EPR
      semantics: offer is accepted "synchronously"

      The agreement resource used for monitoring/termination (*) and
      also possibly domain-specific interfaces appropriate to the
      service description of the offer.

   B. PendingAgreementFactory has wsag:createPendingAgreement
      operation

      input: agreement offer
      output: pending agreement resource EPR
      semantics: acceptance yet to be decided

      The pending agreement resource must change to accepted state to
      signal "asynchronous" acceptance by responder (factory), then it
      has same function as in (A).  There is an optional "acceptance
      EPR" included in the offer to require the responder to directly
      communicate his decision as invocation against an initiator-side
      service.

Another minor protocol variation is that both forms of factory call
accept an optional "initiator agreement EPR" within the offer.  This
allows a more pure peer-to-peer arrangement to be established where
each party exposes a "symmetric" agreement resource representing the
same two-party relationship.  As such, the initiator is able to expose
dynamic resource properties or other domain-specific management
interfaces for use by the responder.

(*) Note: the exact semantics of termination have been under
discussion in the GRAAP-WG and the specification is not yet complete
in this regard.  We want WS-Agreement to support useful idioms but
there is a concern that termination is domain-specific in terms of
what it actually means to cut short the lifetime of the agreement
relationship.  It is subtly close to being "renegotiation" which is
out of scope for WS-Agreement v1.


karl

-- 
Karl Czajkowski
karlcz at univa.com