Tutorial on WS-Agreement
Toshiyuki Nakata, NEC
Heiko Ludwig, IBM
1
Full Copyright Notice
Copyright (C) Open Grid Forum (2005,2006,2007). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all
such copies and derivative works.
The limited permissions granted above are perpetual and will not be
revoked by the OGF or its successors or assignees.
© 2006 Open Grid Forum
2
Outline




Motivation and Overview
Agreement Document Structure
Template and Agreement Composition in Examples
WS-Agreement Establishment, Monitoring Interaction
and State Model
3
WS－Agreement
Motivation and Overview
4
Why Agreements in SOA?
Registry
Performance
Guarantee
RT < 2s
Web Service
WS
WS
Client
WS
Client
WS
Client
WS
Client
Client
Service property depends on its use and its resources.
5
Why Agreements in SOA?
Registry
Performance
Guarantee
Completion
2 hours
Grid Service
Grid
Client
Job completion depends on data, algorithm choices, etc.
6
Why Agreements for SOA?
Registry
Agreement Management
Agreement
Negotiation
Agreement Management
Performance
Guarantee
RT < 2s
Find Service
Provisioning
Provisioning
Web Service
WS
Client
service
Resources can be configured to achieve service property – or reject agreement.
7
Why WS-Agreement

Agreement standard is needed to obtain mutual guarantees between
parties





Capacity
QoS
Pricing, …
Traditionally being established out of band, e.g., SLAs for service
outsourcing.
In a dynamic Web or Grid context, agreements are established


As part of binding process
In band
We Provide
This kind of
service
I would like to use your
service for 5 hours @ 300$.
I would need at least this
much CPU power.
Web/AP servers
Load
Balancer
DBMS
Vendor A
We’ll provide the
service for you
8
Purpose and Status of WS-Agreement

The objective of the WS-Agreement specification:
define a language and a protocol based on WebServices for describing the following capabilities.


Advertising agreement capabilities of parties
Creating agreements based on offers
 Monitoring agreement compliance at runtime.



Enable in-band establishment of actionable and
monitorable agreements.
Is being defined in GRAAP (Grid Resource Allocation
Agreement Protocol )-WG in OGF
Status:Just Before the Final Draft Submission
9
Agreement Layer: Provides
a Web service-based
interface that can be used
to create, represent and
monitor agreements with
respect to provisioning of
services implemented in the
service
A Two Layered Model
create()
Factory
Ops:
terminate(limits)
inspect(query)
...
SDEs:
inspect()
Initiator
Agreement
Terms
Manager
Responder
Status
Agreement
Layer
Related
Agrmts
Factory
Application Instance
foo()
Consumer

Service
Layer
Service Layer provides the
real service. It might be
web-based or non Web
Service based
Provider
Whether an Agreement Initiator is a Service Consumer or Service Provider (i.e.
Agreement Responder becomes a Service Provider or Service Consumer) is
domain and application dependent.
10
Overview of WS-Agreement

Agreement
Scope of WS-Agreement:

Overall agreement document structure
with types of agreement terms,
 Agreement template with creation
constraints
 A set of port types and operations for
creation, expiration and monitoring of
agreements, including WSDL needed
to express the message exchanges
and resources needed to express the
state.
Name
Context
TermsCompositor
Service Description Terms
ServiceReferences
ServiceProperties
Guarantee Terms
Terms Compositor

WS-Agreement itself is a framework.

Initiator
The details of terms to be agreed are
of course domain-specific and is out of
the scope of the WS-Agreement Spec.
 Eg. Job-submission using JSDL is a
candidate to be used within the framework.
Responder
Get Template
Provider
Agreement
Context
Compositor
Service Description Terms
Guarantee Terms
Provider
Creation constraints
Agreement
Context
Compositor
Create Agreement
Service
Descriptio
n Terms
Guarantee Terms
Accept (EPR)

Relation to other specification

Relies on WS-Addressing, WSResourceProperties, WSResourceLifetime and WS-Base
Faults
GetResourceProperties
Provider
Agreement
Cont
Compo
sitor
Servi
e
x
t
ce
Desc
riptio
Guarantee Terms
n
Ter
ms
11
Web Service Example


Agreement Scope: Access to a specific web service at a given
request rate for operations
Parties:

Initiator: Service consumer
 Responder: Service provider

Terms:

Service: Service description (e.g. EPR + WSDL)
 Guarantee: Availability and response time of operations
12
Job Submission Example


Agreement Scope: Execution of a single job
Parties:

Initiator: Individual with Job to be run(= Service Consumer)
 Responder: Provider of job execution service(= Service Provider)

Terms:

Service: Description of job to be run and execution environment (e.g. via
JSDL)
 Guarantee: Deadline by which job will be completed
13
Batch of Jobs Example


Agreement Scope: Rights to execute a sequence of
jobs
Parties:



Initiator: Individual with Job to be run (=Service Consumer)
Responder: Provider of job execution service (=Service Provider)
Terms:

Service: Description of execution environment
 Guarantee: Rate at which jobs may be submitted
14
(Relational) Data Access Example


Agreement Scope: Rights to make future queries
Parties:



Initiator: Individual requiring data access (=Service
Consumer)
Responder: Provider of data-set access(=Service Provider)
Terms:


Service: Query types and allowed tables
Guarantee: Query rate, response time
15
Clear Separation of Agreement Initiator/ Agreement Responder vs.
Service Consumer/Service Provider


Whether Agreement Initiator (AI) becomes a Service Consumer or Service
Provider is domain dependent.
Domain A:


Initiator: Individual with a Job to be
run(=Service Consumer)
Responder: Provider of job execution
service(=Service Provider)
Tell me what kind
of Service You
provide
Please process
my CFD job with
At least
100GFlops
System Power

AI(=SC)
Domain B:


Initiator: Provider of job execution
service(=Service Provider)
Responder: Individual with a Job to be
run(=Service Consumer)
AR=(SP)
Get Template
Templates
A
Computationa
l Job with 432 2GFlops
CPUs …
Create Agreement
Agreement EPR
OK I’ll
do it
Tell me what kind
of Service You
need
I can do the job
for you @ 800$
AI=(SP)
AR(SC)
Get Template
Templates
An engine to
do a CFD
job with 100
Gflops at
less than 1K
dollars
Create Agreement
Agreement EPR
OK I’ll
take it
16
WS－Agreement
Document Structure
17
Agreement Document Structure
Agreement
Information about the Agreement Document
・AgreementInitiator
・AgreementResponder
・ExpirationTime
・・・・
Name
Context
Information about the Service being provided
・Contents are Domain Dependent
・Eg.: Job Description(Program name, Number of nodes etc)
Terms Compositor
Service Terms
Guarantee Terms

Information about Service Levels which should be
Guaranteed
・QualifyingCondition(An optional condition that must be met
(when specified) for a guarantee to be enforced. Eg: Time span
when the requests can be submitted: Weekdays, etc)
・ServiceLevelQbjective: the condition that must be met to satisfy
the guarantee. Eg: Needs 128 MB of memory available ..)
・・・・
The structure of an Agreement Template is the same as that of an agreement, but an Agreement template MAY also
contain a creation constraint section, i.e. a section with constraints on possible values of terms for creating an
agreement. The constraints make it possible to specify the valid ranges or distinct values that the terms may take.
18
Organization of Agreement
Agreement

Name
Context
TermsCompositor

Service Description Terms
ServiceReferences
ServiceProperties

Guarantee Terms
@Agreementid: An identifier Unique
between agreement initiator and
Agreement responder
Name: Optional Name
Context: Describes ‘meta-data’ of the
whole Agreement



Terms Compositor

Parties to Agreement
Agreement Life-time
Template Id/Name
Agreement terms

<wsag:Agreement AgreementId=”xsd:string”>
<wsag:Name>
xs:NCName
</wsag:Name> ?
<wsag:AgreementContext>
wsag:AgreementContextType
</wsag:AgreementContext>
<wsag:Terms>
wsag:TermCompositorType
</wsag:Terms>
</wsag:Agreement>
Term Compositor Structure:A scheme to compose an
AND/OR/XOR relationship of the following two elements
 Service Term: Information needed to instantiate or
identify a service to which this agreement pertains
 Guarantee Term:Service Levels that the parties are
agreeing to.
19
Agreement Context:Meta Info
about the Agreement

AgreementInitiator


Agreement
Name

Context
AgreementResponder


TermsCompositor

Service Description Terms
ServiceReferences
ServiceProperties

Terms Compositor
This element identifies the service provider and is either AgreementInitiator or
AgreementResponder.
ExpirationTime


Provider
Can be an URI or wsa:EndpointReference(ＥＰR) or any other name
ServiceProvider:

Guarantee Terms
Agreement Initiator： （Requestor）
Can be an URI or wsa:EndpointReference(ＥＰR) or any other name
Specifies the time at which this agreement is no longer valid.
TemplateName/Id

Specifies the identification and name of the template from which this agreement is
created.
<wsag:Context xsd:anyAttribute>
<wsag:AgreementInitiator>xs:anyType</wsag:AgreementInitiator> +
<wsag:AgreementResponder>xs:anyType</wsag:AgreementResponder> +
<wsag:ServiceProvider>wsag:AgreementRoleType</wsag:ServiceProvider>
<wsag:ExpirationTime>xsd:DateTime</wsag:ExpirationTime> +
<wsag:TemplateId>xsd:string</wsag:TemplateId>
<wsag:TemplateName>xsd:string</wsag:TemplateName> ?
<xsd:any/> *
</wsag:Context>
20
Term Compositor
Structure
Agreement
Name
Context
TermsCompositor
Service Description Terms
ServiceReferences
ServiceProperties
Guarantee Terms
Terms Compositor

Terms represent the agreements
obligations.

/wsag:Terms/wsag:All (or
wsag:OneOrMore, or
wsag:ExactlyOne)

This is a logical AND (OR,XOR)
operator of type
wsag:TermCompositorType
 Follows the WS-Policy
Compositor model
<wsag:Terms>
<wsag:All>
{
<wsag:All>
wsag:TermCompositorType
</wsag:All>
|
<wsag:OneOrMore>
wsag:TermCompositorType
</wsag:OneOrMore> |
<wsag:ExactlyOne>
wsag:TermCompositorType
</wsag:ExactlyOne> |
<wsag:ServiceDescriptionTerm>
wsag:ServiceDescriptionTermType
</wsag:ServiceDescriptionTerm> |
<wsag:ServiceReference>
wsag:ServiceReferenceType
</wsag:ServiceReference> |
<wsag:ServiceProperties>
wsag:ServicePropertiesType
</wsag:ServiceProperties> |
<wsag:GuaranteeTerm>
wsag:GuaranteeTermType
</wsag:GuaranteeTerm>
}+
</wsag:All>
</wsag:Terms>
21
Individual Types
Agreement

Service Description Term

Name
Context
TermsCompositor

Service Description Terms
ServiceReferences
ServiceProperties
Guarantee Terms
<wsag:ServiceDescriptionTerm>
wsag:ServiceDescriptionTermType
</wsag:ServiceDescriptionTerm> |
<wsag:ServiceReference>
wsag:ServiceReferenceType
</wsag:ServiceReference> |
<wsag:ServiceProperties>
wsag:ServicePropertiesType
</wsag:ServiceProperties> |
<wsag:GuaranteeTerm>
wsag:GuaranteeTermType
</wsag:GuaranteeTerm>
}*

A Service Reference points to a service, e.g.,
by providing an Endpoint Reference.
Service Property

Terms Compositor
{
Service Reference


Service description terms (SDTs) are a
fundamental component of an agreement: the
agreement is about the service(s) described by
the service description terms.
ServiceProperties are used to define
measurable and exposed properties associated
with a service, such as response time and
throughput.
Guarantee Term

define the assurance on service quality,
associated with the service described by the
service definition terms.
22
Service Description Terms
Agreement
Name
Context

TermsCompositor
Service Description Terms
ServiceReferences
ServiceProperties
Guarantee Terms
Terms Compositor

Service description terms (SDTs) are a fundamental
component of an agreement: the agreement is about
the service(s) - existing or not - described by the
service description terms.
Contains three parts:

The name of the ServiceDescriptionTerm.
 The name of the service being described partially or
fully by the domain-specific part of this service
description term. This allows for semantic grouping of
service description terms that may not be structurally
grouped together in the agreement.
 A domain-specific description of the offered or
required functionality. This element MAY completely
describe the service it is about, or it MAY do so only
partially.
<wsag:ServiceDescriptionTerm
wsag:Name=”xs:NCName” wsag:ServiceName=”xs:NCName”>
<xsd:any> … </xsd:any>
</wsag:ServiceDescriptionTerm>
23
Example of a Service Description Term
<wsag:All>
<wsag:ServiceDescriptionTerm wsag:Name=“executable1“
wsag:ServiceName=“a1>
<job:executable> /usr/local/job1 </job:executable>
</wsag:ServiceDescriptionTerm>
<wsag:ServiceDescriptionTerm wsag:Name="numberOfCPUs1"
wsag:ServiceName=“a1">
<job:numberOfCPUs>32</job:numberOfCPUs>
</wsag:ServiceDescriptionTerm>
<wsag:ServiceDescriptionTerm
wsag:Name="memoryPerCPU1“
wsag:ServiceName=“a1">
<job:realMemorySize>200</job:realMemorySize>
</wsag:ServiceDescriptionTerm>
</wsag:All>
Specifies a job whose executable is /usr/local/job1
with 32 CPUs
and Memory size of 200 (MB?)
Please note the usage of Service Name to aggregate several SDT’s.
24
Service Reference
Agreement
Name
Context
TermsCompositor
Service Description Terms
ServiceReferences
ServiceProperties

Guarantee Terms

Terms Compositor
<wsag:ServiceReference
wsag:Name=”xs:NCName” wsag:ServiceName=”xs:NCName”>
<xsd:any> … </xsd:any>
</wsag:ServiceReference>
Provides means for an agreement to simply
refer to the existing service instance
/wsag:ServiceReference/{xsd:any}


This element is a domain-specific
representation of a reference to a service.
Examples:


An EPR in an agreement on the
performance of an existing Web service
Metadata identifying a class of packet
headers in an agreement on network
Quality of Service).
Example of Service Reference
<wsag:ServiceReference
wsag:Name=“DepositRequest"
wsag:ServiceName="BankingService">
<wsa:EndpointReference>
<wsa:Address>http://www.foobank.com/</wsa:Address>
<wsa:ServiceName>bank:DepositRequest</wsa:ServiceName
</wsa:EndpointReference>
</wsag:ServiceReference>
25
Service Property

Agreement
Name
Context
TermsCompositor
Service Description Terms
ServiceReferences
ServiceProperties
Guarantee Terms
Terms Compositor
<wsag:ServiceProperties
wsag:Name=”xs:NCName” wsag:ServiceName=”xs:NCName”>
<wsag:VariableSet>wsag:VariableSetType</wsag:VariableSet>
</wsag:ServiceProperties>
<wsag:Variable wsag:Name=”xsd:NCName” wsag:Metric=”xsd:QName”>
<wsag:Location>xsd:anyType</wsag:Location>
</wsag:Variable>
Example
<wsag:Variable name=”CPUcount” metric=”job:numberOfCPUs” >
<wsag:Location>
//JobDescription/Resources/IndividualCPUCount/Exact
</wsag:Location>
</wsag:Variable>
ServiceProperties are used to
define measurable and
exposed properties associated
with a service, such as
response time and throughput.
The properties are used in
expressing service level
objectives.

The key element is the “variable
set” composed of variables
shown in the second box.
<jsdl:JobDefinition>
<JobDescription>
<Application>
｡｡｡
</Application>
<Resources ...>
｡｡｡
<IndividualCPUSpeed>
<Exact>1600000</Exact>
</IndividualCPUSpeed>
<IndividualCPUCount>
<Exact>2.0</Exact>
</IndividualCPUCount>
26
Guarantee Term
Agreement

Define the assurance on service quality, associated with
the service described by the service definition terms.

Is composed of
Name
Context
TermsCompositor

Service Description Terms
ServiceReferences
ServiceProperties

Guarantee Terms

Terms Compositor


Obligated: The obligated party (ServiceConsumer or ServiceProvider)
ServiceScope: the list of services this guarantee applies to.
QualifyingCondition: an optional condition that must be met (when
specified) for a guarantee to be enforced.
ServiceLevelObjective: an assertion expressed over service
descriptions.
BusinessValueList: one or more business values associated with this
objective.
<wsag:GuaranteeTerm Obligated=”wsag:ServiceRoleType”>
<wsag:ServiceScope ServiceName=”xsd:NCName”>
xsd:any
</wsag:ServiceScope>*
<wsag:QualifyingCondition>…</wsag:QualifyingCondition>?
<wsag:ServiceLevelObjective>…</wsag:ServiceLevelObjective>
<wsag:BusinessValueList>…</wsag:BusinessValueList>
</wsag:GuaranteeTerm>
27
Business Value List
<wsag:BusinessValueList>
<wsag:Importance> xsd:integer </wsag:Importance>?
<wsag:Penalty> </wsag:Penalty>?
<wsag:Reward> </wsag:Reward>?
<wsag:Preference> </wsag:Preference>?
<wsag:CustomBusinessValue> …
</wsag:CustomBusinessValue>*
</wsag:BusinessValueList>

wsag:Importance


wsag:Penalty


expresses reward to be assessed for meeting an objective..
wsag:Preference


Expresses the penalty to be assessed for not meeting an objective.
wsag:Reward


Relative terms, such as high, low, medium, etc. can be used to prioritize across many
guarantees. However, to provide stronger semantics and easier comparison of this
value, this is expressed using an integer.
This element specifies a list of fine-granularity business values for different
alternatives, where each alternative refers to a ServiceDescriptionTerm and its
associated utility.
wsag:CustomBusinessValue:

Can be added and is completely domain specific
28
Agreement Template
Agreement Initiator
Agreement Provider
GetResourceProperty("AgreementFactory",
"wsag:AgreementFactoryProperties")

(templates)
Based on the
Template create
an offer
CreateAgreement(offer)
Decide to agree
To the offer
Create an agreement
(EPR to Agreement1)
At this moment the agreement is
Observed. A-I cannot refuse to the
Created Agreement
Agreement Template
Name
Context
TermsCompositor
Service Description Terms
ServiceReferences
ServiceProperties
Guarantee Terms
Agreement1

To create an agreement, a
client makes an offer to an
agreement factory. An
agreement creation offer has
the same structure as an
agreement. The agreement
factory advertises the types of
offers it is willing to accept by
means of agreement templates.
The structure of an agreement
template is the same as that of
an agreement, but MAY also
contain a creation constraint
section, i.e. a section with
constraints on possible values
of terms for creating an
agreement.
Agreement Creation Constraints
29
Agreement Creation Constraints
Agreement Template
Name

Is composed of a number of offer Item and
Constraint
Context
TermsCompositor
<wsag:template>
…
<wsag:CreationConstraints> ?
<wsag:Item>…</wsag:Item> *
<wsag:Constraint>…</wsag:Constraint> *
</wsag:CreationConstraints>
Service Description Terms
ServiceReferences
ServiceProperties
Guarantee Terms
Agreement Creation Constraints


Item: This element specifies that a particular field of the
agreement must be present with a value in the agreement
offer, and which values are possible.
Constraint：Free-form or XML Schema constraints make it
possible to restrict the possible values of terms.
30
Creation Constraint Item

An offer item specifies the requirement for the presence in the agreement offer
terms of a field and a value for that field. It contains a label, a pointer to the
position of the field in the terms of the offer and also MAY contain a definition
of its acceptable values in the form of a restriction of its value space.
<wsag:Item>
<wsag:Location>//jsdl:IndividualCPUCount</wsag:Location>
<wsag:Constraint>
<xsd:sequence>
<xsd:element name="Exact" minOccurs="1"
maxOccurs="unbounded">
<xsd:simpleType>
<xsd:restriction base="xsd:double">
<xsd:enumeration value="1"/>
<xsd:enumeration value="2"/>
<xsd:enumeration value="4"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
<wsag:Constraint>
</wsag:Item>
31
Template and Agreement
Composition in Examples
32
Job Submission Example Using prototype JSDL
document as Service terms: Template Example
<wsag:ServiceDescriptionTerm
wsag:Name="Job JSDL" wsag:ServiceName="Job">
<jsdl:JobDefinition>
<JobDescription>
<Application>
<jsdl-posix:POSIXApplication>
<FileSizeLimit>1048576</FileSizeLimit>
<CoreDumpLimit>0</CoreDumpLimit>
<OpenDescriptorsLimit>64</OpenDescriptorsLimit>
</jsdl-posix:POSIXApplication>
</Application>
<Resources ...>
<OperatingSystem>
<OperatingSystemType>
<OperatingSystemName>LINUX</OperatingSystemName>
</OperatingSystemType>
</OperatingSystem>
<CPUArchitecture>
<CPUArchitectureName>x86</CPUArchitectureName>
</CPUArchitecture>
<IndividualCPUSpeed>
<Exact>1600000</Exact>
</IndividualCPUSpeed>
<IndividualCPUCount>
<Exact>2.0</Exact>
</IndividualCPUCount>
<IndividualNetworkBandwidth>
<Exact>100000000</Exact>
</IndividualNetworkBandwidth>
<TotalResourceCount>
<Exact>1</Exact>
</TotalResourceCount>
</Resources>
</JobDescription>
<jsdl:JobDefinition>
</wsag:ServiceDescriptionTerm>
•Default 1 MB file size limit
•Default 0 byte core dump size limit
•Default 64 open file descriptors limit
•Default "LINUX" operating system
•Default "x86" CPU type
•Default 1.6 GHz CPU speed
•Default 2 CPUs per node
•Default 100 Mb/s network connectivity for
nodes
•Default 1 node per job
33
Job Submission Example Using prototype JSDL
document as Service terms contd.
•Maximum 500 MB file size limit (Default 1MB)
•Maximum 500 MB core dump size limit (Default 0MB)
•Maximum 1024 open file descriptors limit(Default 64)
<jsdl:JobDefinition>
<JobDescription>
<Application>
<jsdl-posix:POSIXApplication>
<FileSizeLimit>1048576</FileSizeLimit>
<CoreDumpLimit>0</CoreDumpLimit>
<OpenDescriptorsLimit>64</OpenDescriptorsLimit>
</jsdl-posix:POSIXApplication>
</Application>
Template:Service Description Term
<FileSizeLimit>16777216</FileSizeLimit>
<CoreDumpLimit>0</CoreDumpLimit>
<OpenDescriptorsLimit>1024</OpenDescriptorsLimit>
Offer: Service Description Term
<wsag:Item>
<Location>//jsdl-posix:FileSizeLimit</Location>
<xsd:restriction base="xsd:positiveInteger">
<xsd:maxInclusive value="524288000"/>
</xsd:restriction>
</wsag:Item>
<wsag:Item>
<Location>//jsdl-posix:CoreDumpLimit</Location>
<xsd:restriction base="xsd:positiveInteger">
<xsd:maxInclusive value="524288000"/>
</xsd:restriction>
</wsag:Item>
<wsag:Item>
<Location>//jsdl-posix:OpenDescriptorsLimit</Location>
<xsd:restriction base="xsd:positiveInteger">
<xsd:maxInclusive value="1024"/>
</xsd:restriction>
</wsag:Item>
Template: Creation Constraint
•16MB file size limit
•0 MB core dump size limit
•1024 open file descriptors limit
34
Job Submission Example Using prototype
JSDL document as Service terms contd.
•Choice of "LINUX" or "FreeBSD" (exclusive)
•Choice of "x86", "x86_32", or "x86_64" CPU types (exclusive)
<OperatingSystem>
<OperatingSystemType>
<OperatingSystemName>LINUX</OperatingSystemName>
</OperatingSystemType>
</OperatingSystem>
<CPUArchitecture>
<CPUArchitectureName>x86</CPUArchitectureName>
</CPUArchitecture>
Template:Service Description Term
<wsag:Item>
<Location>//jsdl:CPUArchitecture/CPUArhitecturename</Location>
<xsd:restriction base="jsdl:ProcessorArchitectureEnumeration">
<enumeration value="x86_32"/>
<enumeration value="x86_64"/>
<enumeration value="x86"/>
</xsd:restriction>
</wsag:Item>
<wsag:Item>
<Location>
//jsdl:OperatingSystem/jsdl:OperatingSystemType/jsdl:OperatingSystemName
</Location>
<restriction base="jsdl:OperatingSystemTypeEnumeration">
<enumeration value="LINUX"/>
<enumeration value="FreeBSD"/>
</restriction>
</wsag:Item>
Template: Creation Constraint
<OperatingSystem>
<OperatingSystemType>
<OperatingSystemName>LINUX</OperatingSystemName>
</OperatingSystemType>
</OperatingSystem>
<CPUArchitecture>
<CPUArchitectureName>x86_32</CPUArchitectureName>
</CPUArchitecture>
•"LINUX"
•"x86_32"
Offer: Service Description Term
35
Job Submission Example Using prototype
JSDL document as Service terms contd.
•Choice of 10, 100, or 1000 Mb/s network connectivity for nodes
(inclusive)
Template:
<IndividualNetworkBandwidth>
<Exact>100000000</Exact>
</IndividualNetworkBandwidth>
Template:
Service Description Term
Creation Constraint
<wsag:Item>
<wsag:Location>//jsdl:IndividualNetworkBandwidth</wsag:Location>
<xsd:sequence>
<xsd:element name="Exact" minOccurs="1" maxOccurs="unbounded">
<xsd:simpleType>
<xsd:restriction base="xsd:double">
<xsd:enumeration value="1000000000"/>
<xsd:enumeration value="100000000"/>
<xsd:enumeration value="10000000"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</wsag:Item>
<IndividualNetworkBandwidth>
<jsdl:Exact>1000000000</jsdl:Exact>
<jsdl:Exact>100000000</jsdl:Exact>
</IndividualNetworkBandwidth>
Selects 100/1000 Mb/s network speeds
(the scheduler can choose which)
36
WS－Agreement
Establishment, Monitoring
Interaction and State Model
37
Typical Agreement Lifecycle

Four phases in the lifecycle:




Exploration: a service provides
templates describing possible
agreement parameters
Creation: Consumer fills in
parameters, and makes an
offer
Operation: Agreement state
available as a
ResourceProperty
Termination: Agreement
destroyed explicitly or via soft
state (termination time)
Initiator
Responder
Get Template
Provider
Agreement
Context
Compositor
Service
Description
Terms
Guarantee Terms
Creation constraints
Provider
Agreement
Context
Create Agreement
Compositor
Service
Description
Terms
Guarantee Terms
Accept (EPR)
GetResourceProperties
Provider
Agreement
Context
We will describe the Porttypes
and the State models for Exploration,
Creation and Operation
Compositor
Service
Description
Terms
Guarantee Terms
38
Port Types - Overview
Agreement Provider
AgreementFactory
> createAgreement
Agreement Initiator
AgreementAcceptance
Template
PendingAgreementFactory
> createPendingAgreement
> Accept
> Reject
Template
Agreement
Name
Id
Context
Terms
> Operation
AgreementState
ResourceProperty
AgreementState
ServiceTermStateList
GuaranteeTermStateList
39
Porttypes (Overview)

AgreementFactory:PortType

Operation


Resource Properties


Operation


Template: Conditions for PendingAgreement Creation
AgreementAcceptance:PortType(This is on the Agreement Initiator side)

Operation


Accept: Change Agreement with state Pending to Observed
Reject: Change Agreement with state Pending to Rejected
Agreement: PortType

Resource Properties





createPendingAgreement: Asynchronous AgreementCreation
Resource Properties


Template: Conditions for Agreement Creation
PendingAgreementFactory:PortType


createAgreement: Agreement Creation
Name: Agreement Document’s Name
Id: Agreement Document’s ID
Context: Agreement Document’s Context
Terms: Agreement Document’s Terms Compositor
AgreementState: Porttype

ResourceProperties



AgreementState: Agreement’s state
ServiceTermStateList: ＳＤＴ’s State
GuaranteeTermStateList ：Guarantee Term’s State
40
Exploration

Scenario:

Agreement Responder provides templates describing possible
agreement parameters.
 Agreement Initiator uses the GetResoureProperty operation to examine
what kind of templates are offered
 Agreement Initiator can examine the templates of various Responders
in order to determine which Responder has the best Agreement that
meets the Agreement Initiator’s needs
Tell me what kind
of Service You
provide
Tell me what kind
of Service You
provide
Hmm A
seems to be
better
Please process
my CFD job with
At least
100GFlops
System Power
AI
AR-A
Get Template
Templates
AR-B
A
Computationa
l Job with 432 2GFlops
CPUs …
Get Template
Templates
A
Computationa
l Job with 216 2GFlops
CPUs …
Create Agreement
Agreement EPR
OK I’ll
do it
41
Exploration：Port Types
Only the Resource
Propeties:Template
In Agreement Factory and
PendingAgreementFactory are
used
Agreement Initiator
AgreementAcceptance
> Accept
> Reject
Agreement Provider
AgreementFactory
> createAgreement
Template
PendingAgreementFactory
> createPendingAgreement
Template
Agreement
Name
Id
Context
Terms
AgreementState
> Operation
ResourceProperty
AgreementState
ServiceTermStateList
GuaranteeTermStateList
42
Exploration：Portypes (contd.)

AgreementFactory:PortType

Operation


Resource Properties


createAgreement: Agreement Creation
Template: Conditions for Agreement Creation
PendingAgreementFactory:PortType

Operation


createPendingAgreement: Asynchronous AgreementCreation
Resource Properties

Template: Conditions for PendingAgreement Creation
Agreement Responder
Agreement Initiator
GetTemplate()
(templates)
43
Creation

Scenario:



Based on the Templates received, the Agreement Initiator
creates an Agreement Offer and sends it to the Agreement
Responder.
Agreement Responder examines the offer and decides to accept
or not accept
Two kinds of Agreement Factories

Synchronous mode: CreateAgreement:



Agreement Initiator waits for the Agreement Responder to decide on.
Agreement Responder returns with either Agreement (Acceptance)
or Fault
Asynchronous mode: CreatePendingAgreement:



Agreement Responder Immediately returns an EPR but might not
have committed to accept or not.
At a later stage, The Agreement Responder decides to Accept or
Reject.
Agreement Initiator gets to know the result either by polling on the
Agreement State or by having Accept/Reject Operation invoked by
the Agreement Responder
44
Creation Contd.
So why have two modes ( or rather why have the asynchronous mode
CreatePending Agreement as well?)
It might take a long time for the Agreement Responder to decide on whether
it can accept or not (A typical usecase will be described later.)
Web-Services Typically timeout, and the Agreement Initiator cannot know
whether it is due to NW congestion or packet loss or just Agreement
Responder taking a long time to decide..



AI
Please
process my
CFD job with
At least
100GFlops
System
Power
AR
AI
Create Agreement
Timeout
We don’t have enough
resources, let’s try to
see if we can offload
some of our current
load. Perhaps we might
be able to see if we can
borrow some resources
from another site..
Agreement EPR
OK I’ll
do it
Please
process my
CFD job with
At least
100GFlops
System
Power
AR-A
CreatePendingAgreement
Agreement EPR
Uh. This
Responder
is taking a
long time to
decide 
We don’t have enough
resources, let’s try to
see if we can offload
some of our current
load. Perhaps we might
be able to see if we can
borrow some resources
from another site..
OK I’ll
do it
45
Creation ： Runtime States



Agreement States:
This had been resurrected in order to make it possible for the Agreement Initiator to monitor whether the
Agreement Responder has decided or not.
Also, the states reflect whether a terminate request has been sent from the Agreement Initiator







Pending - The Pending state means that an Agreement offer has been made but it has been neither accepted nor
rejected.
PendingAndTerminating - The PendingAndTerminating state means that an Agreement offer has been made and it
has not been accepted or rejected and furthermore a Terminate operation has been issued by the Agreement Initiator
and is being processed. This state MAY follow Pending. This state MAY be followed by the Pending state in a case
where a termination request is made but not accepted by the responder.
Observed - The Observed state means that an Agreement offer has been made and accepted. This state MAY follow
Pending.
ObservedAndTerminating – The ObservedAndTerminating state means that that an Agreement offer has been
made and accepted. Furthermore, a Terminate operation has been issued from the Agreement Initiator and is being
processed by the Agreement Responder. This state MAY follow Observed or PendingAndTerminating. This state
MAY be followed by the Observed state in a case where a termination request is made but not accepted by the
responder.
Rejected - The Rejected state means that an Agreement offer has been made and rejected. This state MAY follow
Pending.
Complete - The Complete state means that an Agreement offer has been received and accepted, and that all activities
pertaining to the Agreement are finished This state MAY follow Observed.
Terminated - The terminated state means that an Agreement offer has been terminated by the Agreement Initiator and
that the obligation no longer exists. This state MAY follow Pending, PendingAndTerminating, Observed or
ObservedAndTerminating when the termination decision is made. The fact that the Agreement is in this state MAY
imply that a domain specific penalty is imposed.
OfferReceived
Agreement states
exposed to
an Initiator
Rejected
Pending
Observed
PendingAnd
Terminating
ObservedAnd
Terminating
Complete
Terminated
46
Creation：Port Types
Agreement Provider
AgreementFactory
> createAgreement
Agreement Initiator
AgreementAcceptance
Template
PendingAgreementFactory
> createPendingAgreement
> Accept
> Reject
Template
Agreement
Name
Id
Context
Terms
> Operation
AgreementState
ResourceProperty
AgreementState
ServiceTermState
GuaranteeTermState
47
Creation：PortTypes

AgreementFactory:PortType

Operation


Resource Properties


Operation


createPendingAgreement: Asynchronous AgreementCreation
Resource Properties

Template: Conditions for PendingAgreement Creation
AgreementAcceptance:PortType(This is on the Agreement Initiator side)

Operation



Template: Conditions for Agreement Creation
PendingAgreementFactory:PortType


createAgreement: Agreement Creation
Accept: Change Agreement with state Pending to Observed
Reject: Change Agreement with state Pending to Rejected
AgreementState: Porttype

ResourceProperties



AgreementState: Agreement’s state
ServiceTermState: ＳＤＴ’s State
GuaranteeTermState ：Guarantee Term’s State
48
Creation ： Sequence Example
Agreement Initiator
AgreementResponder
GetResourceProperty("AgreementFactory",
"wsag:AgreementFactoryProperties")
(templates)
Based on the
Template create
an offer
CreateAgreement(offer)
Decide to agree
To the offer
Create an agreement
(EPR to Agreement1)
At this moment the agreement is
Observed. A-I cannot refuse to the
Created Agreement
Agreement1
Asynchronous versions also available
49
Creation ： Sequnce Example-2
Agreement Initiator
Agreement Responder
GetResourceProperty("AgreementFactory",
"wsag:AgreementFactoryProperties")
(templates)
Based on the
Template create
an offer
CreateAgreement(offer)
Decide to refuse
(Return a Fault)
50
Creation：
Asynchronous Sequence Image for Polling
Agreement Responder
Agreement Initiator
GetTemplate()
(templates)
create an offer
createPendingAgreement()
AgreementEPR
create an agreement
Agreement
State
Pending
Poll the status of the agreement
Pending
…
Pending
Decide to
accept/reject offer
Poll the status of the agreement
Observed/Rejected
Observed/
Rejected
51
Creation： Asynchronous Sequence Image for
Accept/Reject
Agreement Responder
Agreement Initiator
GetTemplate()
(templates)
create an offer
createPendingAgreement(AcceptanceEPR)
AgreementEPR
create an agreement
Agreement
State
Pending
Pending
Decide to
accept/reject offer
Invoke Accept / Reject
Accept Response / Reject Response
Observed/
Rejected
52
Operation


In Operation, Agreement Initiator is really more
interested in the Service Layer Operations (After all that
is why the Agreement Initiator asked for the Agreement
in the first place)!!
However, Agreement Initiator can also monitor how the
status of the Service for each Service Description Term
and also the Guarantee Terms as these states are
available as Resource Properties
53
Operation : Port Types (Summary)
Agreement Provider
AgreementFactory
> createAgreement
Agreement Initiator
AgreementAcceptance
Template
PendingAgreementFactory
> createPendingAgreement
> Accept
> Reject
Template
Agreement
Name
Id
Context
Terms
> Operation
AgreementState
ResourceProperty
AgreementState
ServiceTermState
GuaranteeTermState
54
Operation : Port Types

Agreement: PortType
 Resource Properties
 Name: Agreement Document’s Name
 Id: Agreement Document’s ID
 Context: Agreement Document’s Context
 Terms: Agreement Document’s Terms Compositor

AgreementState: Porttype
 ResourceProperties
 AgreementState: Agreement’s state
 ServiceTermState: ＳＤＴ’s State
 GuaranteeTermState：Guarantee Term’s State
55
Operation : Service Runtime States

Service Runtime States






Not Ready, Ready and Completed are the normative primary states of a
service description term. Each state can be extended with one or more
sub-states in a specific usage domain. Processing and Idle are two
normative sub-states of the primary state Ready.
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 ready and currently processing a request or
is otherwise active.
Idle – The service is ready, however currently not being used.
Completed – The service cannot be 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.
Not Ready
Ready
Processing
Completed
Idle
56
Example of Extending the Substates

An NQS batch queuing systems job has the following
states
Not Ready
Waiting
(A new substate of Ready)
Queued
(A new substate of Ready)
Ready
Processing
Completed
Idle
Hold=Idle
Running
=Processing
Exit
=Completed
57
Operation : Guarantee RuntimeStates

Guarantee States



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.
Fulfilled
Not Determined
Violated
58
Backup
59
End-to-End Bandwidth Example


Agreement Scope: Reserved bandwidth
Parties:



Initiator: Entity which will claim bandwidth (=Service Consumer)
Responder: TelCo with WAN infrastructure or Broker (=Service
Provider)
Terms:


Service: End-Points, time-of-day for usage
Guarantee: bandwidth, jitter, etc. with measurement parameters
60
Service Scopes, QualifyingCondition and
ServiceLevelObjective

Service Scopes
 a list of service names referring to the respective wsag:ServiceName
attributes of one or more of the service description terms in this
agreement.
<wsag:ServiceScope>
<wsag:ServiceName>ComputeJob1</wsag:ServiceName>
</wsag:ServiceScope>

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.
61
Penalty and Rewards

AssesmentInterval

<wsag:Penalty>
<wsag:AssesmentInterval>
This element defines the interval over
which a penalty is assessed.

TimeInterval

<wsag:TimeInterval>xsd:duration</wsag:TimeInterval> |
<wsag:Count>xsd:positiveInteger</wsag:Count>
</wsag:AssesmentInterval>
<wsag:ValueUnit>xsd:string</wsag:ValueUnit>?
<wsag:ValueExpr>xsd:any</wsag:ValueExpr>
</wsag:Penalty>

wsag:Count


This element when present defines the
assessment interval as a service specific
count, such as number of invocation.
ValueUnit


This element when present defines the
assessment interval as a duration.
This element defines the unit for assessing
penalty, such as USD. This is an optional
element since in some cases a default unit
MAY be assumed.
ValueExpr

This element defines the assessment
amount, which can be an integer, a float or
an arbitrary domain-specific expression.
Alternatively, meeting each objective generates a
reward for a service provider. The value expression
for reward is similar to that of penalty.
62
Preference
<wsag:Preference>
<wsag:ServiceTermReference>xsd:string
</wsag:ServiceTermReference>*
<wsag:Utility>xsd:float</wsag:Utility>*
</wsag:Preference>


<wsag:GuaranteeTerm
wsag:Name="ConfigurationPreference">
<wsag:ServiceScope>
“Preference” is used to describe a list of
fine-granularity business values for
different alternatives, where satisfying
each alternative results in a different
business value.
ServiceTermReference

This element can appear multiple times each
ServiceTermReference references a ServiceTerm
representing an alternative for meeting service
level objective. Corresponding, utility (specified
below) specifies utility in meeting this objective.
<wsag:ServiceName>ComputeJob1</wsag:ServiceName>
</wsag:ServiceScope>

Utility
<wsag:ServiceLevelObjective xsi:type="sdtc:OpType">
 This element can appear multiple times, one
<Or>
corresponding to each ServiceTermReference.
<SDT>numberOfCPUsHigh</SDT>
<SDT>numberOfCPUsLow</SDT>
</Or>
</wsag:ServiceLevelObjective>
<wsag:BusinessValueList>
<wsag:Preference>
<wsag:ServiceTermReference>numberOfCPUsHigh
</wsag:ServiceTermReference>
<wsag:Utility>0.8</wsag:Utility>
<wsag:ServiceTermReference>numberOfCPUsLow
</wsag:ServiceTermReference>
In the example, a high number of CPUs is associated with a utility of 0.8
<wsag:Utility>0.5</wsag:Utility>
</wsag:Preference>
while a low number of CPUs has a utility of 0.5, expressing the preference of
</wsag:BusinessValueList>
a high number of CPUs available for the job to a low number.
63
</wsag:GuaranteeTerm>
Choices in creation constraints



In GGF14, there had been requests for Creation constraints to be able to
offer Either serviceA or serviceB or serviceC. (And have the Agreement
Initiator specify which service it needs.)
One candidate had been the term compositors but that might make the
implementation too complex
=> Allow the use of xsd:typeDefParticle
<wsag:Item Name=”xsd:NCName”>
<wsag:Location>
xsd:anyType
</wsag:Location>
<wsag:ItemConstraint>
<xsd:restriction>
xsd:simpleRestrictionModel
<xsd:restriction> ?
<xsd:group>xs:groupRef</xsd:group> ?
<xsd:all>xs:all</xsd:all> ?
<xsd:choice>xs:explicitGroup</xsd:choice> ?
<xsd:sequence>xs:explicitGroup</xsd:sequence>?
</wsag:ItemConstraint>
64