Agreement State

The agreement state is the overall state of an agreement. The agreement state implements the following state model:

1. Pending. an agreement offer has been made but it has been neither accepted nor rejected
2. PendingAndTerminating. A pending agreement has been created and the agreement initiator terminates the pending pending agreement before it was accepted by the agreement responder. The agreement remains in this state until the termination process is completed.
3. Rejected. A pending agreement has been rejected.
4. Observed. An agreement offer has been made and accepted.
5. ObservedAndTerminating. An agreement was accepted by the agreement responder and was subsequently terminated. The agreement remains in this state until the termination process is completed.
6. Complete. All services associated with the agreement are finished. An agreement changes its state to completed if all service term states are Completed.
7. Terminated. An agreement has been terminated by the agreement initiator and the termination process is finished.

If an agreement is in state (a) or (b) it is not monitored, i.e. the registered monitoring handler are not invoked and guarantee states are not computed. Agreements in states (c) and (d) are monitored. Agreement in states (e) - (g) are not active anymore and therefore not monitored.

The framework automatically updates the status of an agreement to state Complete if all services related to the agreement are completed, e.g. all service term states of the agreement have reached the state Completed.

Service Term States

Each service description term (SDT) defined in the agreement terms has its own state. Service term states are an abstract, domain-independent representation of SDTs at runtime. They implement the following state model:

1. NotReady. the service cannot be used yet
2. Ready. the service can now start to be used by a client or to be executed by the service provider

   The Processing State and the Idle State are sub states of the Ready state. These predefined sub-states correspond to domain-specific extensions that can be included in a state element.

3. Completed. the service cannot be used any more and any service provider activity, e.g. performing a job, is finished. This state does not express whether an execution of a job or service was successful.

Service term states are only applicable if an agreement is either in the Observed or ObservedAndTerminating state, which means that the agreement is active and monitored.

Besides the abstract, domain independent state, a service term state can also include domain specific state information. This domain specific state information comprises for example monitoring information of a service execution, such as the minimal, maximal, and average response time of a provided service (see Agreement Monitoring Example).

Guarantee Term States

For each guarantee term in an agreement there is one guarantee term state. The guarantee states follow a simple state model:

1. NotDetermined. no activity regarding this guarantee has happened
2. Fulfilled. currently the guarantee is fulfilled
3. Violated. currently the guarantee is violated

The initial state of a guarantee is NotDetermined. A guarantee remains in this state until an assessment on the fulfillment or violation can be made. When a guarantee is evaluated, its state changes either to (b) or (c). Based on these states, a penalty or a reward is issued. See section Guarantee Evaluation for further details on how guarantee terms are evaluated.