Contracts for Distributed Applications
IST CONTRACT Project
FP6
EU – IST
CONTRACT Project
Talk Outline

IST­Contract

Not a standard presentation

Some Issues:







Contracts and verification ­> Family of contracting languages
Contracts + Behaviour + Verifiability
Contracts and Institutions
Contracts change possible worlds
Gap between human and electronic contracts.
What is in human contracts v's what is in WSLA
Contracts and Ontologies
September 2006
EU IST CONTRACT
2
IST Contract Project

IST FP6 STREP Project starting 1st Sept 2006

Focus: 



Contracts for Distributed Applications Engineering
Contracts as a basis for formal verification
e­business applications
Non­focuses:

Negotiation, capturing human contracts
September 2006
Certicon A. S. Yall B. V.
LostWax Media Ltd.
EU IST CONTRACT
3
CONTRACT in a NUTSHELL?


Engineering applications in Cross Organisational Service Oriented Computing environments
Trying to make progress on three fronts




Build on the idea that formal verification over contracts, obligations etc. rather than over internal code is the way to build sound distributed applications in service oriented environments.
Create concrete methods and tools which enable the use of contracts, obligations and agreements in order to structure the design of such applications (target audience WS­* community)
Build realistic use cases in different industries
Focus on Contracts 
As the explicit, tangible representation of service interdependencies
September 2006
EU IST CONTRACT
4
What do we mean?

The behaviour of a software application depends upon:




In a multi­organisational Web Services application:




Code
Execution Context (environment)
Inputs
No­one has access to all the code
No­one has access to all the execution context
(Possibly) no­one has access to all inputs
Question:

How do you predict the potential run­time behaviour of such applications?
September 2006
EU IST CONTRACT
5
Project Meme

Formal Verification approaches for software will not work without this access

Contract Project Approach:

Exchange Access to Code / Environment for Access to Contracts 
Instead of predicting actions w.r.t code ­ predict actions w.r.t obligations, rights, permissions

Impact:

Public information, (in principle) massively reduced search space, public impact of failure September 2006
EU IST CONTRACT
6
Project Target Outcomes

Major Outcomes:






Timeline:



Theoretical Framework
XML/RDF Based Contracting Language Syntax and Semantics plus associated verification techniques
Contract based e­Business Web Services Application Frameworks
Verification, monitoring and analysis tools
Three case studies
Specifications / Document from Months 9­12...
Software from Months 15­18...
Majority of results open, royalty free, open source
September 2006
EU IST CONTRACT
7
Thoughts on Contracts more generally...
EU – IST
http://www.ist­contract.org
CONTRACT steve@lsi.upc.edu
Project
Contracts and Verification I 
Verification for software system focuses on possible executions of the system:

Contracts provide a way to express agent's attitudes to possible future behaviours 
Verification and monitoring needs to combine:

Possible actions (possible executions of the system)

Contract agreed actions (contract compliant executions of the system)


Actual actions (actual executions of the system)
Verification could for example look at worlds in which:

Nothing is violated, penalties are honoured when violations occur, violations are not rectified
September 2006
EU IST CONTRACT
9
Contracts and Verification II 
Clear problems:

Contracts refer to some “interesting actions” ­ other actions are possible which interfere with contracted actions (is there an assumption of negation as failure?)

Action specifications may not capture all effects: frame problem

Actions may be to modify contracts: creating explosive changes in possible worlds

Action specifications are one clearest challenge areas for contract based systems

Commonality with issues in planning systems
September 2006
EU IST CONTRACT
10
Contracts and Verification II 
Clear problems:

Contracts refer to some “interesting actions” ­ other actions are possible which interfere with contracted actions (is there an assumption of negation as failure?)

Action specifications may not capture all effects: frame problem

Actions may be to modify contracts: creating explosive changes in possible worlds

Action specifications are one clearest challenge areas for contract based systems
Challenge:

Commonality with issues in planning systems
September 2006
EU IST CONTRACT
Action Descriptions 11
Contracts and Verification III 
Important:

Contracts do not just reduce the space of likely executions 
They can increase it: by giving permissions and powers to some agents which they would not have

Current status:

Model checking for Multi­Agent systems is extremely costly and complex

Checking over obligations and promised actions may be easier but...
September 2006
EU IST CONTRACT
12
Contracts and Verification III 
Important:

Contracts do not just reduce the space of likely executions 
They can increase it: by giving permissions and powers to some agents which they would not have

Current status:

Model checking for Multi­Agent systems is extremely costly and complex

Checking over obligations and promised actions may be easier but...
September 2006
Challenge:
EU IST CONTRACT
How to use info on rational actions to reduce search space? 13
Contracts and Context I


Contracts (or SLAs) are essentially meaningless if:

Not set “in context”

They contain terms which cannot be grounded or de­referenced
Contexts could include:

The laws of the country you reside in (“human solution”)

Institutions (in particular e­Institutions)

Virtual Organisations (c.f. Trustcom)

Choreographies – e.g. WS­CDL (Participants, Roles, Choreographies, Channels, Work Units, Activities, Ordering, ...)

All of these may provide elements of what is needed
September 2006
EU IST CONTRACT
14
Contracts and Context II

Questions:

What if parties are a­priori not collaborative – does some more general context apply?

What is the difference (in structure) between an invidual contract/SLA and a “framework agreement” (e.g. a collaboration definition)

Electronic Institutions and organisational approaches have a more formal theoretical basis – but are they concrete enough to be of use? September 2006
EU IST CONTRACT
15
Contracts and Context II

Questions:

What if parties are a­priori not collaborative – does some more general context apply?

What is the difference (in structure) between an invidual contract/SLA and a “framework agreement” (e.g. a collaboration definition)

Electronic Institutions and organisational approaches have a more formal theoretical basis – but are they concrete enough to be of use? September 2006
EU IST CONTRACT
Challenge:
How to model & use Context16 What's in a Contract I (Sergot 2003 iTrust)

Current languages focus on:


However also very important (and mostly missing!) is:



Obligation, Permission, Prohibition Power
especially power to create institutional facts
Also important are 


“counts­as” (fulfilment conditions)
procedure / protocol (by which one establishes claims)
entitlement (of X to something owned by Y)
September 2006
EU IST CONTRACT
17
What's in a Contract II

WSLA focuses broadly on:




Parties, Service Level Parameters, Metrics, Measurement Mechanisms,
Obligations, Action Guarantees, Penalties
However, looking at human contracts can yield another view:

International Association for Contract and Commercial 
Management
Annual survey of 500 organisations
Addressing their negotiation priorities

September 2006
EU IST CONTRACT
18
Negotiation Priorities Top 10
September 2006
EU IST CONTRACT
19
Issues 20­30

Interesting Issues:

Many issues not covered in approaches such as WSLA / WS­
Agreement

List is considered “very negative” ­ focusing on “value reducing” factors.
September 2006
EU IST CONTRACT
20
What's in a Contract III

Not clear that current languages capture everything that is needed:

Some types of statements are not explicitly supported (power, counts­as)

The focus of software contracts is clearly different from human contracts:
• Is this good or bad?
• Are there things we can transfer between the two?
September 2006
EU IST CONTRACT
21
What's in a Contract III

Not clear that current languages capture everything that is needed:

Some types of statements are not explicitly supported (power, counts­as)

The focus of software contracts is clearly different from human contracts:
• Is this good or bad?
• Are there things we can transfer between the two?
Challenge:
Modelling the Contract itself September 2006
EU IST CONTRACT
22
Contracts and Ontologies I

A large %age of any contract has to do with ­ 


DEFINING TERMS
WSLA supports the definition of terms directly related with the service and its performance:

Generic language / expressions for performance

Service definition ­> WSDL defined service
However there is a big gap between this and extensively defining:

Objects

Actions

Relationships between the above
September 2006
EU IST CONTRACT
23
Contracts and Ontologies II

Questions:

To what extent do the SLA parameters actually overlap / form part of a service description?

There is work on QoS/SLA ontologies (OWL­S, WSDL­S) ­> but this is only part of the problem. How do we define the objects/actions precisely enough for a contract to be meaningful?

Issues 
Related to the more general issues for services – how to integrate ontologies with Web Services / Grid Services Descriptions and communication

There is a lot of domain engineering underneath a contract
September 2006
EU IST CONTRACT
24
Contracts and Ontologies II

Some of these problems can be circumvented by:

Hoping that many domains have similar quality metrics, structures for quality secification

Using external definitions of semantics (such as product ID which can be de­referenced in the real world)

However, particularly hard are:

Pre­, Post­ conditions of actions

Relationships between Objects­Actions, Actions­Actions, Objects­
Objects
September 2006
EU IST CONTRACT
25
Contracts and Ontologies II

Some of these problems can be circumvented by:

Hoping that many domains have similar quality metrics, structures for quality secification

Using external definitions of semantics (such as product ID which can be de­referenced in the real world)

However, particularly hard are:

Pre­, Post­ conditions of actions

Relationships between Objects­Actions, Actions­Actions, Objects­
Objects
September 2006
EU IST CONTRACT
Challenge:
Contracts + Ontologies26
Conclusions
EU – IST
CONTRACT Project
Conclusions: Research Agenda Items

Contracts (or SLAs) are promises about behaviour (action, no­action under certain circumstances)

How do we match “contracted” behaviour with “arbitrary possible behaviour”?


How do we adequately model various parts of the problem? Five suggested challenges:

Modelling and using action descriptions

Modelling and using information on possible behaviour to predict execution

Modelling and using context

Extensions to modelling the contract itself (power, counts­as,..)
 Integrating contracts and ontologies
September 2006
EU IST CONTRACT
28