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@univa.com