giovanna di marzo serugendo university of geneva, switzerland

SIC’05, 14/04/05 Giovanna Di Marzo Serugendo 1

A Social Semantic Infrastructure for Decentralised Systems Based on

Specification-Carrying Code and Trust

Giovanna Di Marzo SerugendoUniversity of Geneva, Switzerland


Outline

• Semantic Infrastructure– « Specification-Carrying Code » (SCC)– Service-oriented architecture

• Social Infrastructure– Trust-Based Systems

• Social Semantic Infrastructure– SCC + Trust


Applications• Wireless / Ad hoc Networks

– Bluetooth / WiFi / Ad hoc networks of PDAs– Sensor Networks

• Grid• Agent-Based Systems• Ambient Intelligence

– End-user services based on an invisible intelligent techonology• Virtual shopping, visa detection, traffic management

• Autonomic Computing– Self-management systems

• Large Scale Security Systems


Applications

• Characteristics– Based on autonomous entities

• Ex: PDAs, Agents

– Uncertain environment– Decentralised– Large number of components– Dynamic environment – Need for adaptability– Social dimension

• Interactions, discovery, negociations, transactions


Issues• Interactions with unknown entities (semantics)

– Understanding– Interoperability

• Management of uncertainty (social)– Malicious entities

• Exhibit desirable characteristics, but …– Good faith entities

• Fail because: software error, lack of toner, paper jam, …

• Adaptability to changing environment

• Control / Design of decentralised behaviour – Good properties have to emerge– Bad properties to be avoided!


Specification-Carrying Code

• Interaction with unknown entities– No common design / No common API

• Idea: communication is based on a formal specification of the behaviour of a peer entity– Software « carries » a formal description of its own

functional behaviour – Communication occurs without API– Formal specification defines the semantics of the

behaviour


SCC - Principle

• Scenario– Publication of specifications

• Services requested / Services proposed

– Specification matching• Proposed service matches requested service

– Service realised in an anonymous / asynchronous / non-deterministic manner

• Interest– Minimum basis for communication

• Specification language (for expressing concepts)

– Interaction with new software / with unknown software – No central control (self-assembly)


SCC - Principle

Cod

e Ax

Ax1

Ax2

…..

Register

Thm Checker

{i | i }

Ax

Request


SCC - Architecture

CodeWR/SpecS

Service

Code

Register (SpecS,IP,Port) SpecS,(IP,Port)SpecSSpecS

Service Manager

RegEx Prolog HOL

Register

Entity

Code

CodeWR/SpecE

Execute (SpecS)

Search (SpecS)

Execute (ArrayList)

(IP,Port)

ArrayList’


SCC – Keywords

• Registration(Functionality: ``FileSystem´´: ``Read´´, Behaviour: String : ``return´´ : String, QoS: ``local´´, [3,2,1])

• Request(Functionality: ``FileSystem´´: ``Read´´, Behaviour: ``myFile.html´´ : ``return´´ : String, QoS: ``local´´, [3,2,1])


SCC – RegEx

• Registration

<specs> <description active="true"> <content> Sorting service </content> </description> <regex active="true"> <name>(?i)\w*sort\w*</name> <params>String\*</params> <result>String*</result> </regex> </specs>

• Request

<specs> <description active="true"> <content>Sorting request </content> </description> <regex active="true"> <name>sort</name> <params>String*</params> <result>String\*</result> </regex></specs>


SCC – Prolog• Registration

<specs> <description active="true"> <content> Sorting service </content> </description> <prolog active="true"> <content> append([],L,L). append([H|T],L2,[H|L3]):-

append(T,L2,L3).

rev([],[]). rev([H|T],R) :- rev(T,RevT),

append(RevT,[H],R). </content> </prolog></specs>

• Request

<specs> <description active="true"> <content> Sorting Request </content> </description> <prolog active="true"> <content> rev([],[]), rev([A|B],R), rev(B,RevB),

append(RevB,[A],R), rev(R,[A|B]). </content> </prolog> </specs>


SCC – Alternatives• Specification

Keywords Regular Expressions (syntactic) Prolog (SWIProlog)– HOL (Isabelle Thm Prover – meta-ontology) – Jena (Logic + ontology)– Common Simple Logic

• Architecture Publication of specifications (asynchronous / anonymous / non-

deterministic)– Direct exchange of specifications (interaction decisions)

• Service Discovery– JXTA protocols– Géo-positioning

• Information contained in the specification– Functional– Non-functional, security, reputation, positioning, etc,


SCC - Advantages

• Interaction/Interoperability with unknown peers

• Integration with new entities

• Ontology+Semantics

• Service Combination

• Robustness

• Resilience


SCC for Unanticipated Run-time Code Evolution

• Code changes during its execution (without stopping the application)

• Non anticipated evolution – Non anticipated by the programmer

• Distribution on the fly

• Experiments– Web Server

• 160 different versions of the server, with only 4 stops – Tic-Tac-toe for Open Days

• Changes done to the application during the play


SCC for Autonomic Computing• Self-configuration (installation, configuration, integration)

– SCC expresses high-level configuration policies• Installation needs • Seamless integration of new entities

• Self-repair (error detection, diagnostic, repair)– Generation of correct code from SCC – Replace error code with code having matching

specification– Checking of code against specification


SCC for Autonomic Computing

• Self-optimisation (parameters)– SCC expresses optimisation policies

• Parameters description • Permanent optimisation of parameters depending on

the context

• Self-protection (detection and response to attacks)– SCC expresses security policies

• Conditions regulating services delivery• Signatures of attacks / Response schema


SCC vs PCC vs Trust• SCC

– Code is decoupled from specification – No guarantee that the code satisfies the specification– It is the same with APIs!

• Proof Carrying Code (PCC) [Necula00]– Code « carries » the proof that it is correct

• Low level (no infinite loop, no division by zero)• Not at the functional level• No specification

– What happens if the code/proof are malicious? – What happens if the code/proof are in good faith, but the code fails?

• Trust– Adaptation mechanism based on experience and observation


Trust-based Systems

• Human notion of trust– Uncertainty and partial knowledge– Human beings make choices, take decisions, learn by experience,

adapt their behavior– Decisions implicitly rely on trust:

• Peers• Legal institutions• Business companies

• Idea– Human-like trust-based access control– To learn about peer behavior– To dynamically adapt access control policies


Trust-based Systems

• Software entities– Part of decentralised and distributed systems

– Autonomous, roaming

– Highly changing environment• Information changes and is not permanently valid

– Interactions occur locally

– Partial knowledge about the entities, and the environment

– Take decisions with local and incomplete knowledge

– Trust-based schema helps evaluating:• Good faith, correct functioning


Trust-based Model (1)

• Principals: – interacting set of entities (human/computers, trusted or untrusted)

• Local trust values: – Principals maintain local trust values about other principals

• Evidence– Direct observations: evaluated outcome of an interaction– Recommendations: asked or received (indirect observation)


Trust-based Model (2)

• Scenario– Request of interaction– Decision making process

• Recognise principal• Evaluate trust value, evidence, risk implied by requested

interaction• Application of Control Policy

– After interaction: trust value updated on the basis of evaluated outcome of the interaction

• Trust evolves with time– allows to adapt behaviour of principal

SECURE – IST Funded Project(2002-2004)


Issues

• Autonomous Systems• Needs

– Interaction with unknown entities– Exchange of capabilities:

• To learn about peer behavior

• Issues– Malicious entities

• Exhibit desirable characteristics, but …– Good Faith entities

• Fail because: software error, lack of toner, paper jam, …

• Idea– Combination of specifications and trust


SCC and Trust-based model

• Human behavior– Communication through semantic information

• Autonomous software: Entities carry specification describing their functional and non-functional behavior

– Decisions despite uncertainty• Autonomous software:

Trust formation and evolution


SCC and Trust-based model

• Request for collaboration and exchange of Specification– Principals learn services provided by other principals

• Decision to interact– Evaluation of specifications, past direct observations,

received recommendations, local trust value, risk implied by interaction

• Trust update– Evaluation (positive or negative) of outcome of interaction – Spreading of recommendations


Example: Printers and PDAs

• Set of printers (not predefined)• Set of computers (using printers, not predefined)• Exchange of capabilities before interactions

– Postscript/double-sided

• Storing of interactions outcome– Only single-sided, no printing

• Local trust value computation and update• Propagation of recommendations• Risks:

– Losing time using a far located printer, printer runs out of paper, etc.


Printers and Users (1)

lw6

lw6: PostScript / Double-Sided/ Paper Jam / Problems with PDFs

lw3

lw3: New / Prints all PDFs



lw3

lw6: New Printer

lw8

lw6: Random Printinglw8: In the Library

lw6



lw3

lw6: Software Evolution

lw8lw6


Conclusion

• SCC– Simple specifications of behavior– Implementation through a middleware infrastructure

• Trust-based model– Defined and implemented as part of EU Funded project –

SECURE • Future work

– Own specification language (pre- post- conditions, parameters mapping)

– Large scale examples– “Google” services

giovanna di marzo serugendo university of geneva, switzerland

Documents

request sorting request

unknown software

request functionality

unknown peersintegration

new software

apiformal specification

software error

common apiidea