scel: service component ensemble language by rosario pugliese

SCEL: Service-Component Ensemble Language

Rosario Pugliese

Dipartimento di Sistemi e InformaticaUniversita degli Studi di Firenze

Awareness Virtual Lecture Series (AVLS) — Autumn 2011

Work developed within the EU project ASCENS (257414)

SCEL: Service-Component Ensemble Language c© Rosario Pugliese 1

Outline

1 Motivations

2 SCEL: Design Principles

3 SCEL: Syntax

4 SCEL: Operational Semantics (sketch)

5 Ongoing & Future Work

SCEL: Service-Component Ensemble Language c© Rosario Pugliese 2

Ensembles

Future generation of software-intensive systems featuring

massive numbers of components

complex interactions among components, and with humans and other systems

operating in open and non-deterministic environments

dynamically adapting to new requirements, technologies and environmentalconditions

Definition introduced in the IST Coordinated Action InterLink [2007]

Motivations SCEL: Service-Component Ensemble Language c© Rosario Pugliese 3

Challenges

Adaptation has been proposed as a powerful mean for taming the ever-increasingcomplexity of today’s computer systems, networks and applications

Developing software for ensembles creates new difficulties related to e.g.I the large dimension of the systemsI the need to adapt to changing environments and requirementsI the emergent behaviours resulting from complex interactionsI the uncertainty during design-time and run-time

Formalisms, linguistic constructs and programming tools should be designedfeaturing high level of autonomous and adaptive system behavior

Rigorous and sound concepts should be devised to reason and prove systemproperties


Autonomic Service-Component Ensembles (ASCENS)Researching ways to build ensembles that combine

I traditional software engineering approachesI techniques from autonomic, adaptive, knowledge-based and self-aware systemsI the assurance about functional and non-functional properties provided by formal methods

Industrial

Community

Formal Methods

Community

Software Engineering

and Autonomic Systems

Communities

Highly innovative

results

Real-world practical

challenges

Real-world practical

challengesInspiration through

pragmatic approaches

Inspiration through

methods and techniques


Service Components (SCs)

The notions of service components and service-component ensembles are ameans to dynamically structure independent and distributed system entities

SCs are autonomic entities that can cooperate, with different roles, in open andnon-deterministic environments

I These basic properties, already satisfied by, e.g., current service-oriented architectures,are enriched with awareness

Awareness is achieved byI equipping SCs with information about their own state and behaviorI enabling SCs to collect and store information about their working environmentI allowing SCs to use this information for redirecting and adapting their behavior

Awareness-rich behavior makes SCs adaptable, connectable and composable


Service-Component Ensemble (SCE)A set of service components (and possibly simpler SCEs)

with dedicated knowledge units, to represent shared, local and global knowledgeinterconnected via highly dynamic infrastructuresfeaturing goal-oriented, safe and secure execution, and efficient resource management

Knowledge

Knowledge

K

K

Service Component Ensemble

SCE

Service Component

SC

SCSC


(Some ASCENS) Research issues

To develop SCEs whose properties go beyond the state of the art in current softwareengineering, we are investigating different issues

Languages for modelling and programming SCEs

Foundational models for adaptation, dynamic self-expression and reconfiguration

Formal methods for the design and verification of reliable SCs and SCEs

Software infrastructures supporting deployment and execution of SCE-basedapplications

. . .


Our aim

To model the behavior of service components and of their ensembles,their interactions, their sensitivity and adaptivity to the environment

We are designing SCEL, a specific language withI programming abstractions for

F directly representing Knowledge, Behaviors and Aggregations

according to specific PoliciesF naturally programming interaction, adaptation and self- and context-awareness

I a small set of basic constructs with solid semantic groundsF so that logics, tools and methodologies can be developed

for formal reasoning on systems behaviorF in order to establish qualitative and quantitative properties

of both the individual components and the ensembles


SCEL: programming abstractions

The Service-Component Ensemble Language (SCEL) provides primitives andconstructs for describing the following programming abstractions:

Knowledge: describe how data, information and knowledge is managed

Behaviours: describe how systems of components progress

Aggregations: describe how different entities are brought together to formcomponents, systems and, possibly, ensembles

Policies: deal with the way properties of computations are represented andenforced

SCEL: Design Principles SCEL: Service-Component Ensemble Language c© Rosario Pugliese 10

Our Starting Points (1980 — . . . )

Process AlgebrasI CCS, CSP, ACP, . . .

Calculi and Languages for MobilityI Pi-calculus, Obliq, Ambients, . . .

Tuple-space-based Coordination LanguagesI Linda, Klaim, MARS, . . .

SCEL: Design Principles SCEL: Service-Component Ensemble Language c© Rosario Pugliese 11

SCEL: Syntax (at once)

Systems: S ::= C∣∣ S1 ‖ S2

∣∣ (νn)S

Components: C ::= I[K,Π,P]

Knowledge: K ::= 〈t〉∣∣ K1 ‖ K2

Processes: P ::= nil∣∣ a.P

∣∣ P1 + P2

∣∣ P1[P2 ]∣∣ X

∣∣ A(p) (A(f ) , P)

Actions: a ::= get(T )@c∣∣ rtv(T )@c

∣∣ put(t)@c∣∣ exec(P)

∣∣ new(I,K,Π,P)

Targets: c ::= n∣∣ x

∣∣ self

Items: t ::= . . .

Templates: T ::= . . .

SCEL: Syntax SCEL: Service-Component Ensemble Language c© Rosario Pugliese 12

Knowledge

SCEL is parametric wrt the means of managing knowledgeas we don’t want to take a definite stand about

Knowledge representation

Tuples, Records, Clauses, Constraints, . . .

Corresponding knowledge handling mechanisms

Pattern-matching, Reactive TS, Queries,Logic programming, Concurrent constraint programming, . . .

They may depend on the application domain


Knowledge

K ::= 〈t〉∣∣ K1 ‖ K2

Knowledge repositories are (multi)sets of items 〈t〉I Application data: data used for the progress of the computationI Control data: data providing information about

F the environment in which a component is running (e.g. monitored data from sensors)F the current status of a component (e.g. its position or its battery level)

The knowledge handling mechanism provides three operationsI for adding information to a repositoryI for retrieving information from a repositoryI for withdrawing information from a repository

which can be triggered by (the abstractions relative to) behaviours


Behaviors

Describe how systems of components progress

Are modeled as processes in the style of process calculi

Interaction is rendered by allowing processes to access to knowledge repositories,possibly of other components

Adaptation is modeled by retrieving from the knowledge repositoriesboth information about the changing environment and the component stateand (suggestions about) the code to execute for reacting to these changes


Processes

P ::= nil∣∣ a.P

∣∣ P1 + P2

∣∣ P1[ P2 ]∣∣ X

∣∣ A(p) (A(f ) , P)

Processes: the SCEL active computational unitsProcesses are built up from the inert process nil via

action prefixing: a.P ,

nondeterministic choice: P1 + P2,

controlled composition: P1[ P2 ]

process variable: X ,

parameterised process invocation: A(p)

parameterised process definition: A(f ) , P


Processes

P ::= nil∣∣ a.P

∣∣ P1 + P2

∣∣ P1[ P2 ]∣∣ X

∣∣ A(p) (A(f ) , P)

Processes: the SCEL active computational unitsControlled composition P1[ P2 ] can be seen as a generalisation of the various formsof “parallel composition of P1 and P2” commonly used in process calculi


Actions

a ::= get(T )@c∣∣ rtv(T )@c



Actions: processes can perform five different kinds of actionsActions get(T )@c , rtv(T )@c and put(t)@c manage knowledge repositories bywithdrawing/retrieving/adding information items t from/to the knowledgerepository c

I Exploit templates T as patterns to select knowledge itemsI Trigger execution of the corresponding operation provided by the knowledge handling

mechanism of the target repository c

Action exec(P) triggers a controlled execution of process P

Action new(I,K,Π,P) creates a new component I[K,Π,P]


Aggregations

Describe how different entities are brought together to form components, systemsand, possibly, ensembles

Model resource allocation and distribution

Reflect the idea of administrative domains, i.e. resources and computations of agiven entity are under the control of a specific authority

Compositionality and interoperability are supported by component interfacesthat specify attributes and functionalities provided by components


ComponentsC ::= I[K,Π,P]

ComponentsAn interface I containing information about the component itself

A knowledge manager K providing local (and possibly part of the global)knowledge (i.e. control data) in addition to the application data, together with aspecific handling mechanism

A set of policies Π regulating the interaction among the different internal partsof the component and its interaction with the other componentsA process term P

I Some of the processes composing P perform the local computationI Some other ones may coordinate processes interaction with the knowledge repository

and/or deal with the issues related to adaptation and reconfiguration


Interfaces

Contain attributes and functionalities provided by a component

Attribute: a name to which a values is associatedAttribute values can be dynamically changedNecessary attributes of any component C are

I id : the name of the component CI ensemble: a predicate on interfaces used to determine the actual components of the

ensemble created and coordinated by CI membership: a predicate on the interfaces used to determine the ensembles which C is

willing to be member of

Functionality: a behaviour made available for external invocation


Systems

S ::= C∣∣ S1 ‖ S2

∣∣ (νn)S

Systems: aggregations of components where some names are restricted

Single component C

Parallel composition ‖Name restriction νn (to delimit the scope of name n)

I In a system of the form S1 ‖ (νn)S2, the effect of the operator is to make name ninvisible from within S1


EnsemblesNo specific syntactic construct for making ensembles

They are dynamically formed by exploiting attributes, e.g. ensemble andmembership, to put requirements on the other partnersThe design choice of having ‘synthesized’ ensembles dynamically determined

I supports an high dynamicity and flexibility in forming, joining and disjoining ensemblesI permits avoiding to structure ensembles through rigid syntactic constructsI affects the communication abilities of components (and of the processes therein)





ensemble predicatesI.id ∈ {n,m, p}

I.active = yes ∧ I.battery level ≥ 30%

rangemax ≥√

(self.x − I.x)2 + (self.y − I.y)2





membership predicatestrue

false

I.trust level > medium


Policies

Deal with the way properties of computations are represented and enforced

Interaction: interaction predicates, . . .

Resource usage: accounting, leasing, . . .

Security: access control, trust, reputation, . . .

SCEL is parametric wrt the actual language used to express policies


SCEL: Operational SemanticsThe operational semantics is given in the Structural Operational Semantics(SOS) style by relying on the notion of Labelled Transition System (LTS)

LTS: a triple 〈S,L, −→ 〉I A set of states SI A set of transition labels LI A labelled transition relation −→ ⊆ S × L× S accounting for the actions that can

be performed from each state and the new state reached after each such transition

The semantics is defined in two steps

I First, the semantics of processes specifies process commitments,i.e. the actions that processes can initially perform,ignoring process allocation, available data, regulating policies, . . .

I Then, by taking process commitments and systems configuration into account,the semantics of systems provides a full description of systems behaviour

SCEL: Operational Semantics (sketch) SCEL: Service-Component Ensemble Language c© Rosario Pugliese 24

Operational Semantics of ProcessesProcesses: P ::= nil

∣∣ a.P∣∣ P1 + P2

∣∣ P1[P2 ]∣∣ X

∣∣ A(p) (A(f ) , P)




LTS rules (excerpt)

a.Pa−→ P (a 6= exec(P ′)) exec(P).P ′ exec(P)−−−→ P ′[ P ]

Pα−→ P ′ Q

β−→ Q ′

P[ Q ]α[β ]−−→ P ′[ Q ′ ]



∣∣ a.P∣∣ P1 + P2

∣∣ P1[P2 ]∣∣ X

∣∣ A(p) (A(f ) , P)




LTS rules (excerpt)


Pα−→ P ′ Q

β−→ Q ′

P[ Q ]α[β ]−−→ P ′[ Q ′ ]

exec spawns a new process P whose execution can be controlled by the continuation P ′ of theprocess performing the action



∣∣ a.P∣∣ P1 + P2

∣∣ P1[P2 ]∣∣ X

∣∣ A(p) (A(f ) , P)




LTS rules (excerpt)


Pα−→ P ′ Q

β−→ Q ′

P[ Q ]α[β ]−−→ P ′[ Q ′ ]

The semantics of P[Q ] at the level of processes is absolutely permissive and generates all possiblecombinations of the commitments of the involved processes; it is then refined at the level of systemsto also take polices into account


Operational Semantics of Systems: LTS rules (excerpt)

Systems: S ::= I[K,Π,P]∣∣ S1 ‖ S2

∣∣ (νn)S

From process actions to component actions

Pα−→ P ′ Π, I : α � λ, σ

I[K,Π,P]λ−→ I[K,Π,P ′{σ}]

Intra-component withdrawal

I[K,Π,P]I:t/n−−→ I[K,Π,P ′] n = I.id K t = K′ Π, I ` I : t / I

I[K,Π,P]τ−→ I[K′,Π,P ′]

Inter-component, intra-ensemble withdrawal

S1I:t/n−−→ S ′

1 S2I:t/J−−−→ S ′

2 n = J .id ens(I,J )

S1 ‖ S2τ−→ S ′

1 ‖ S ′2


Ongoing & Future Work

We are assessing to which extent SCEL fits for modelling the behavior ofservice components and of their ensembles, their interactions, their sensitivityand adaptivity to the environment

I As testbeds we will use three case studies from different application domainsi.e. Robotics (collective transport), Cloud-computing (transiently available computers),and e-Mobility (cooperative e-vehicles)

This process might require tuning the language features

We will implement SCEL, possibly by exploiting the distributed softwareframework IMC developed in previous EU projects (MIKADO & SENSORIA)

We will develop logics, tools and methodologies for formal reasoning on systemsbehavior, in order to establish qualitative and quantitative properties of both theindividual components and the ensembles

Ongoing & Future Work SCEL: Service-Component Ensemble Language c© Rosario Pugliese 27

scel: service component ensemble language by rosario pugliese

Education