1. E-Science NorthWest Jon MacLaren Monday 18 th to Friday 22 nd October 2004 GridPrimer Training Course University of Manchester GridPrimer An Introduction to the world of Grid Computing

2. E-Science NorthWest WS-Agreement The current “favourite” proposed protocol for negotiation on the Grid

3. e-Science NorthWest3 What is this WS-Agreement?  Web Services Agreement Specification – WS-Agreement for short.  Abstract from latest version of spec (23 rd 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.”

4. e-Science NorthWest4 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?

5. e-Science NorthWest5 An agreement is represented by 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...

6. e-Science NorthWest6 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.

7. e-Science NorthWest7 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...

8. e-Science NorthWest8 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)

9. e-Science NorthWest9 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 upon WS-ResourceProperties, part of WS-RF  So, how soon will this really be ready?

10. e-Science NorthWest10 Section 3 Layered Architecture “Figure 1: WS-Agreement Conceptual Layered Service Model. Note: The names of the different operations and “attributes” are not normative.”

11. e-Science NorthWest11 Section 4 Form of an agreement Figure 2: Structure of an agreement

12. e-Science NorthWest12 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)

13. e-Science NorthWest13 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.

14. e-Science NorthWest14 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

15. e-Science NorthWest15 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.

16. e-Science NorthWest16 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...

17. e-Science NorthWest17 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)

18. e-Science NorthWest18 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.

19. e-Science NorthWest19 Section 5 Agreement Template Figure 3: Structure of an agreement template.

20. e-Science NorthWest20 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?

21. e-Science NorthWest21 Section 6 Template 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.”

22. e-Science NorthWest22 Section 7.1 Runtime 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:

23. e-Science NorthWest23 Section 7.2 Runtime 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:

24. e-Science NorthWest24 Section 8 PortTypes and Operations  Three PortTypes are definied –AgreementFactory –Agreement –AgreementState – no operations, only resource properties

25. e-Science NorthWest25 Section 8.1 AgreementFactory 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

26. e-Science NorthWest26 Section 8.2 Agreement 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

27. e-Science NorthWest27 Section 8.2 AgreementState 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...

28. e-Science NorthWest28 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?