E-Science NorthWest Jon MacLaren Monday 18 th to Friday 22 nd October 2004 GridPrimer Training...

E-S

cie

nce N

ort

hW

est

Jon MacLaren

Monday 18th to Friday 22nd October 2004GridPrimer Training CourseUniversity of Manchester

GridPrimerGridPrimer

An Introduction to the world of Grid Computing

E-S

cie

nce N

ort

hW

est WS-AgreementWS-Agreement

The current “favourite” proposed protocol for negotiation on the Grid

e-Science NorthWest3

What is this WS-Agreement?

Web Services Agreement Specification – WS-Agreement for short.

Abstract from latest version of spec (23rd August 2004):– “This document describes Web Services Agreement Specification

(WS-Agreement), an XML language for specifying an agreement between a resource/service provider and a consumer, and a protocol for creation of an agreement using agreement templates. The specification consists of three parts to be used in a composable manner: a schema for specifying an agreement, a schema for specifying an agreement template, and a set of port types and operations for managing agreement life-cycle, including creation, termination, and monitoring of agreement states.”


But what is an “agreement”? Essentially, this is a contract, a set of terms that the parties entering

into the agreement consent to.

Limited to bi-partite agreements– Typically these are between a service provider and a service consumer– The agreement is normally initiated by the service consumer, but this

doesn’t have to be the case (although some parts of the spec still say it does!)

How are agreements negotiated?– Single trip negotiation only!– No 2-phase commit

So how are these agreements represented?– By a document?


An agreement is representedby a service (!)

To understand this, you have to consider the history of the protocol.

Descendent of “SNAP: A Protocol for Negotiation of Service Level Agreements and Coordinated Resource Management in Distributed Systems” (Czajkowski, Foster, Kesselman, Sander, Tueke), LNCS 2537, 200, pp 153-183.

Was first created as OGSI-Agreement...


So, what is the protocol?

Basic steps are:

1. The Agreement Provider or Factory advertises a number of agreement templates (ResourceProperties)

2. The Agreement initiator discovers these templates

3. The Agreement initiator calls the “createAgreement” operation on the Agreement Factory with a proposed agreement that MUST match one of the templates.

4. If the factory does not agree to the terms, a fault message is thrown. Otherwise, an endpoint reference (EPR) is returned, which refers to an observed Agreement service.


Is it really this simple?

WS-Agreement appears on many architecture pictures, some of which clearly need something more sophisticated.

Many people assume that there is 2-phase commit Many people assume that negotiation is being addressed

In reality:– The group of authors doesn’t believe in 2-phase commit for simple

agreements– The authors have separated all non-trivial aspects of negotiation

into a new specification:WS-AgreementNegotiation

– No work on this new protocol has been done...


How is the specification organised?

The specification is long: 59 pages, although ~20 pages of this is WSDL specifications.– Section 1: Introduction (4 pages)– Section 2: Two example scenarios (1.5 pages)– Section 3: Architecture Diagram (2 pages)– Section 4: What Agreements look like (15 pages)– Section 5: What Agreement templates look like (4 pages)– Section 6: Definition of template compliance (0.5 pages)– Section 7: Runtime States of terms (1 page)– Section 8: The Factory and Agreement PortTypes (3 pages)– Section 9: A use case (another scenario really) (0.5 pages)


State of the Specification

Global Grid Forum Draft Recommendation Should enter “public comment period” real soon now. Part of the Grid Resource Allocation and Agreement

Protocol Working Group (GRAAP-WG), which is working on protocols for Advance Reservation of resources.

The specification is dependent uponWS-ResourceProperties, part of WS-RF

So, how soon will this really be ready?


Section 3Layered Architecture

Consumer Provider

create()

foo()Application Instance

Factory

Manager

create()Factory Agreement

Operations:Terminate()GetResourceProperty()...Resource Properties:

Terms RelatedStatusAgrmts

inspect()

Agreement Layer

Service Layer

Consumer Provider

create()


Factory

Manager




inspect()

Agreement Layer

Service Layer

“Figure 1: WS-Agreement Conceptual Layered Service Model. Note: The names of the different operations and “attributes” are not normative.”


Section 4Form of an agreement

Figure 2: Structure of an agreement


Agreement Structure:Context

Identifies the following:– Who the initiator is (optional)– Who the provider is (optional)

• Both of these can be either a URI,• Or an WS-Addressing endpoint,• Or something else...

– Whether the initiator is the service consumer (optional, defaults to “true)

– Expiration time (optional – NOT the same as termination time!)– Template name (optional)– Related agreements (must appear, but can be empty). List of:

• Endpoint references• Relationship type (e.g. wsag:dependency – these are not actually

defined)


Agreement Structure:Summary of Terms

Terms can be composited recursively, i.e. you get a hierarchy of Agreement terms

Composited with “All”, “OneOrMore” or “ExactlyOne” (was AND, OR, XOR – but what is XOR for 3 things?)

You use ServiceDescriptionTerms to express what the service might provide – you are defining ServiceNames– You use ServiceProperties to define which of these terms are

measurable– You use ServiceReference to provide domain-specific references

to the ServiceNames

You use GuaranteeTerms to make assurances about behaviour of the service – the levels of service that the parties are agreeing to.


Agreement Structure:Agreement Terms

Different kinds of terms, all of which have a Name attribute, which names the term and SHOULD be unique, for searching:– ServiceDescriptionTerm – Describes (an aspect of) a service covered by

the agreement• ServiceName (attr) Name of the service the term refers to – the identifier is only

scoped within the agreement• Anything! (elem) Domain-specific description of the aspect of the service

– ServiceReference – Maps ServiceName to a domain-specific ref., e.g. URI or EPR

• ServiceName (attr) + xsd:any (elem)

– ServiceProperties – Describes aspects of a ServiceName which can be measured

• ServiceName (attr) + VariableSet (elem) (More in a moment...)

– GuaranteeTerms – Define assurance on quality of service• More in a moment


Agreement Structure:Service Properties: Variable Set

VariableSet is just a set of Variables, each of which contains: Location (elem) xsd:anyType - refers to part of the service description

terms– “The value of this element is a structural reference to a field of arbitrary

granularity in the service description terms - including fields within the domain-specific service descriptions.

• This reference gives scope to the concept represented by the variable, i.e. the concept applies at the nesting level of the structural item that is referred.

• This reference MAY be an XPATH expression for instance to use with domain-specific service description languages that are based on XML. If this reference is an XPATH, it MAY be relative to the wsag:Terms section of the agreement document.”

Name (attr) – Name of the variable – must be unique within the set Metric (attr) – Optional.

– For when the location doesn’t tell you everything you need to know about the variable.


Agreement Structure:Guarantee Terms

Define assurance on quality of service... Consists of:– ServiceScope (elem, 0 or more) List of ServiceNames.

• The guarantee applies to every one of these ServiceNames

– QualifyingCondition (elem, any type, optional)– ServiceLevelObjective (elem, any type, optional)

• “QualifyingCondition and ServiceLevelObjective are expressed as assertions over service attributes and/or external factors such as date and time. The type of both elements is xsd:anyType as a completely open content that can be extended with assertion languages which MAY be designed independently of the WS-Agreement specification but which MUST address the requirements of the particular domain of application of the agreement.”

– BusinessValueList (elem) List of Business Value Elements...


Agreement Structure:Guarantee Terms: BusinessValueList

Contains:– Importance (elem, optional) – relative important of this

ServiceLevelObjective (or “Guarantee”)

– Penalty (elem, optional) – for missing an objective

– Reward (elem, optional)– for meeting an objective.

– Penalty and reward both contain:• an interval over which the objective is assessed, or• a count which should be met (e.g. number of invocations)• a unit for assessing the penalty/reward in• the penalty/reward itself

– Preference (elem, optional), containing:• a list of ServiceTermReferences and• a corresponding list of Utility values associated with these

– CustomBusinessValue (elem, 0 or more, any type)


Agreement Structure:Summary of Terms

You use ServiceDescriptionTerms to express what the service might provide – you are defining ServiceNames– You use ServiceProperties to define which of these

terms are measurable– You use ServiceReference to provide domain-specific

references to the ServiceNames

You use GuaranteeTerms to make assurances about behaviour of the service – the levels of service that the parties are agreeing to.


Section 5Agreement Template

Figure 3: Structure of an agreement template.


Agreement Template:Agreement Creation Constraints

Optional. Contains:

List of Item elements – constraints referring to a particular term– Name (attr) – Name of the constraint, which should be unique– Location (elem) – Refers to ServiceDescription term(s)– (see VariableSet in ServiceProperties)– Restriction (elem) – xsd:simpleRestrictionModel, as defined in the XML

Schema

List of Constraint elements – more freeform than Item– Can be anything– The specification suggest the constraint language contained within

XQueryX, the XML rendering of XQuery– They use XQueryXConstraint in the text of the spec, but this is not defined

in the WSDL – probably this is meant just as an example?


Section 6Template Compliance

“Definition: An agreement template offer is compliant with a template advertised by an agreement provider if and only if each term of service described in the Terms section of the agreement offer complies with the term constraints expressed in the wsag:CreationConstraints section of the agreement template.

In addition, certain portions of the Context section of the offer have a required relation to corresponding portions of the Context in the template. These are:

– wsag:AgreementProvider:The AgreementProvider value provided in the offer must match the value, if any, specified in the template.

– wsag:ExpirationTime: If the template context contains an ExpirationTime element, the ExpirationTime element of the offer MUST NOT be greater than that of the template.

– wsag:TemplateName: The TemplateName in the offer must exactly match the name provided in the template document against which compliance is being checked. If the TemplateName is not provided, the provider MAY use any policy to determine compliance. These MAY include rejecting all, testing against all templates, or evaluating independently of the templates advertised.”


Section 7.1Runtime States of Guarantees

Each guarantee term has a state, which can be one of:– “Fulfilled – Currently the guarantee is fulfilled.– Violated – Currently the guarantee is violated.– NotDetermined – No activity regarding this guarantee has

happened yet or is currently happening that allows evaluating whether the guarantee is met.”

Possible transitions:


Section 7.2Runtime States of ServiceDescriptionTerm

Each ServiceDescriptionTerm (i.e. ServiceName) also has a runtime state, which can be one of:– Not Ready – The service cannot be used yet.

– Ready – The service can start now to be used by a client or to be executed by the service provider.

– Processing – The service is currently being processed or in use.

– Completed – The service cannot used any more and any service provider activity performing a job is finished. This state does not express whether an execution of a job or service was successful.

Possible transitions:


Section 8PortTypes and Operations

Three PortTypes are definied– AgreementFactory– Agreement– AgreementState – no operations, only resource properties

Consumer Provider

create()


Factory

Manager




inspect()

Agreement Layer

Service Layer

Consumer Provider

create()


Factory

Manager




inspect()

Agreement Layer

Service Layer


Section 8.1AgreementFactory PortType

Operations: createAgreement

– Supply your EPR (optional)– Supply the proposed agreement

Will throw a fault message for “no”, or return the EPR of the Agreement service

ResourceProperties: Template – 0 or more of these


Section 8.2Agreement PortType

Operations: Terminate – “Terminates an agreement, if permissible”

– Will throw a fault message for “no”, or give empty response

ResourceProperties: Context – the context of the agreement Terms – the specified terms of the agreement


Section 8.2AgreementState PortType

ResourceProperties: GuaranteeTermStateList – as explained previously ServiceTermStateList – as explained previously

Each of these contains a Name attribute corresponding to the term name, and a state – basically an enumeration of what was stated earlier.

These are not defined in the text of the spec – only in the WSDL!

Note: The specification says don’t use this as is – it should be composed into a domain-specific port type...


Odd choices?

Agreement as a service, not a document– The service models different views of an agreement (i.e. for the

different parties)

No explicit modelling of relationship between Guarantee Terms and Service Description Terms

BUT Explicit modelling of potentially domain-specific services!

Terminate operation. Dangerous! Repudiation issues! Should be called Expire?

E-Science NorthWest Jon MacLaren Monday 18 th to Friday 22 nd October 2004 GridPrimer Training...

Documents

Transcript of E-Science NorthWest Jon MacLaren Monday 18 th to Friday 22 nd October 2004 GridPrimer Training...