Topic: Web Services Agreement Specification. The presentation contains all the basic details required for Web Services Agreement. The research paper has been quoted in the references. Cheers!

1. Web Services (15XW92)
Assignment Presentation
Done by:
Prashanth Selvam A, 16PW27
M.Sc. Software Systems (5th Yr),
PSG College of Technology,
Coimbatore – 04

2. Topic: Web Services Agreement
Q. What is Web Services Agreement?
 A Web Services protocol for establishing agreement between two parties, such as between a
service provider and consumer.
 Uses an extensible XML language for specifying the nature of the agreement.
 Agreement templates to facilitate discovery of compatible agreement parties.

3. Web Services Agreement Specification
The specification consists of three parts which may be used in a
composable manner:
1. A schema for specifying an agreement.
2. A schema for specifying an agreement template.
3. A set of port types and operations for managing agreement life-cycle, which include
creation, expiration, and monitoring of agreement states.

4. WS Agreement – Objective and Goal
 The objective of the WS-Agreement specification is to define a language and a protocol
for advertising the capabilities of service providers and creating agreements based on
creational offers, and for monitoring agreement compliance at runtime.
 The goal of WS-Agreement is to standardize the terminology, concepts, overall
agreement structure with types of agreement terms, agreement template with creation
constraints and 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.
Note: WS Agreement is also meant to be composable (coexist) with other Web services
specifications.

5. WS Agreement Requirements
In meeting the goals, the specification must address the following specific
requirements:
1. Must allow use of any service term.
2. Must allow creation of agreements for existing and new services.
3. Must allow use of any condition specification language.
4. Must provide symmetry of protocol.
5. Must be composable with various negotiation models.
6. Must be standalone.
7. Must allow independent use of different parts of the specification.

6. WS Agreement - Example Scenarios
WS-Agreement covers a wide range of application scenarios relating to the
establishment of an agreement between a service provider and a service
consumer.
1. Job submission
2. Advance reservation or pre-establishment of resource preferences
3. Service Parameterization
Note: In the examples we will assume that the service provider acts as the
agreement responder, and the service consumer as the agreement initiator.

7. Job submission Scenario
• Submission of a job to a batch processing system.
• The job submission process can be recast as agreement creation, where
each agreement represents the requirements and obligations for completing
one job.
• The job hosting service post an agreement template describing the range of
job offers it may accept.
• Job submitters make offers describing jobs to be run.
• The job hosting service has the opportunity to consider the job offer and
decide whether to accept or reject it.

8. Job submission Scenario – Contd.
The job agreement, agreement offer, and agreement template would all
include service definition terms expressed in an appropriate job description
language.
This language encodes the conventional details of the job such as the nature of
the process to be executed, the resources required for execution, and any
scheduling requirements such as job-start or job-completion deadlines.
Upon acceptance, the resulting agreement service may be used to monitor the
delivery of service required by these terms, e.g. the lifecycle of the actual job.

9. Layered Model
The model for the architecture of WS-Agreement based system interfaces have
two layers:
1. The agreement layer: It 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 layer.
2. The service layer: It represents the application-specific layer of the service being
provided. The class of provided service MAY or MAY NOT be a Web service interface. The
interfaces in this layer are domain-specific, and need not be altered when the agreement
layer is introduced.

10. Layered Model – Contd.

11. Web Services Agreement Structure

12. WS Agreement Template and Creation
Constraints
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.
Creation constraint section is 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.

13. WS Agreement Template Contents

14. Compliance of Offers with Templates
 An agreement offer is compliant with a template advertised by an agreement
responder 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.
 The purpose of templates is to give guidance on what forms of offer an agreement
responder wishes to receive.

15. Runtime States
Agreements and Terms have a runtime state that can be monitored.
The objective of term status monitoring is to observe agreement
compliance at runtime.
There are ultimately three types of Runtime States and they are:
1. Agreement States
2. Service Runtime States
3. Guarantee States

16. Agreement States

17. Service Runtime States
Note: 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.

18. Guarantee States
Note: NotDetermined is the initial state of a guarantee term, until a service is invoked or
fulfilled and assessment is made. Depending on the assessment the terminal state can be
either Fulfilled or Violated.

19. Security in WS Agreement
o The WS-Agreement specification does not explicitly address any security
considerations.
o Security issues can be addressed by blending with other security
implementations in the web services domain.
o Authenticate the participants in a WS Agreement-based interaction to insure
the identity of the initiator and responder of a WS-Agreement creation and
management session.
o Signing or authenticating a document based on the WS-Agreement schema.

20. References and Links
1. Web services agreement specification (WS-Agreement) by Asit Dan, Kate Keahey, Hans J W
M Ludwig and Jim Pruyne.
2. R. Chinnici, J.-J. Moreau, A. Ryman, S. Weerawarana: “Web Services Description Language
(WSDL) Version 2.0 Part 1: Core Language”, W3C Candidate Recommendation, W3C, 6
January, 2006.
3. A. Nadalin, C. Kaler, P. Hallam-Baker, R. Monzillo: "Web Services Security: SOAP Message
Security 1.0 (WS-Security 2004)", OASIS Standard 200401, OASIS, March 2004.
4. Link - https://www.researchgate.net/publication/238681058
5. Link - https://aws.amazon.com/agreement/

21. Thank You!