here - Cnr

XVI Workshop dagli Oggetti agli Agenti, WOA 2015, Napoli, 17-19 Giugno 2015
GOAL LIFECYCLE
Addressed
FS=true
Active
capability
failure
Injected
retreat
commit
FS=false
TC=true
Ready
commitment failure
MUSA
A Middleware for User-driven Service Adaptation
Massimo Cossentino, Carmelo Lodato, Salvatore Lopes,
Luca Sabatucci
http://aose.pa.icar.cnr.it/MUSA -- https://github.com/icar-aose/MUSA
What is MUSA
!  MUSA (Acronym) is a middleware for executing business processes
by dynamically orchestrating services:
!  It supports runtime self-adaptation1
!  Self-Healing1: the ability of a system to detect and recover from potential
problems and continue to function smoothly
!  Self-Configuration1: the ability of a system to configure and reconfigure
itself under varying and unpredictable conditions
!  Self-Optimization1: the ability to detect suboptimal behavior and optimize
itself to improve its execution
1J.
O. Kephart and D. M. Chess, “The Vision of Autonomic Computing,” Computer, vol. 36, no. 1, pp. 41–50,
2003.
MUSA Features
!  MUSA is based on three different approaches:
!  Goal-orientation. Goals are core elements of the middleware, used for
representing user-requests.
!  Goals are injected into the running system at run-time.
!  Norm-orientation. Norms introduce permissions/obligations about how agents
will organize to provide a solution.
!  The user can inject (at run-time) rules for self-managing of activities and resources with
respect to the goals to address.
!  In addition, norms can specify organizational needs so that the system is flexible enough
to adapt to changing situations.
!  Norms may be used to specify business rules, and can be easily changed at runtime
!  Capability. Agents of the system own a special entity called capability.
!  It encapsulates a task the agent is able to operate plus the knowledge for deciding when/
how/why to use it
!  The mechanism of composing capabilities for addressing goals (with respect of norms) is
called Proactive Means-End Reasoning. This has been implemented through the BDI
reasoning.
Musa Features
Goal-orientation
A GOAL-ORIENTED APPROACH:
Decoupling WHAT and HOW
!  BPMN is hard to use for
!  run-time modification of the flow of events,
!  creating dynamic hierarchies of services
!  integration of user preferences
!  These properties require to relax some constraints
!  The proposed solution: GoalSPEC + Capabilities
!  GoalSPEC is a declarative language to describe business goals (i.e. the
desired result rather than how to address it)
!  A capability specifies what a component (i.e. an agent) is able to do. It
supports two abstraction levels: Abstract and Implementation
wants
is able to
GOAL
is able to achieve a goal by
doing an action if i)knows
the agen
wha
GOAL
knows what theis active
action
is and ii) knows that doingwould
the action
resu
when
is addressed
would result in the goal being satisfied
[21]. Thisbecome
topic ha
ev
when
is active when
is addressed
deployed
become even TRIGGER
more currentFINAL
because the amount of
servicei
when
SUBJECT
CONDITION
STATE
are looking
deployed in the
web is exponentially
growing and researcher
TRIGGER
FINAL
GOAL LIFECYCLE
Addressed
SUBJECT
CONDITION
STATE
composing
are looking for ways
for automatically searching, selecting
and
[achieve-goal]
We
use
C
STATE
OF
[maintain-goal]
EVENT
composing them
[35]. THE WORLD
FS=true
of wo
We use Capability as an internal representation ofunit
an atomi
STATE OF
EVENT
commit
TC=true
Ready
Injected
Active
THE WORLD
in
composed of
by
unit of work that generated
a software
agent
may use for changes
addressing
two compo
changes in the state of the world. A Capability is made o
goal injectiongenerated by
composed of
makes an
Fig. 7. The Core Metamodel of the Goal Specification Language.
FS=false
two components:
an abstract description (a set of beliefs
tha
reason on
commitment failure
state failure
makes an agent aware of owning the capability and
able fo
to
Fig. 7. The Core Metamodel of the Goal Specification Language.
of plans
on its
andState.
a concrete
body isimplementation
(a se
Whereas
a Triggerreason
Condition
anduse),
a Final
The subject
a noun
goal retreat of plans for executing the job).
that describes the name of the involved person, role or group description
Whereas
weresponsibility
define a template
a Trigger Condition and a Final State. The subject is a of
noun
the abstrac
body, l
persons that
owns the
to addressfor
theproviding
goal. The the
description
a capability,
we
doin
not
provide
any language
fo
that describes
the name
of the Condition
involved person,
role or
developer.
triggerCondition
condition
is anof
event
that must
occur
in the
order
to start
Goal's
Tirgger
(TC)
is group
the
that
must
hold
that presen
body, leaving
the The
choice
the is
specific
technology
to th
the goal.
finalofstate
the desired
of persons that owns the responsibility to address the goal.acting
The fortheaddressing
state
of
the
world
in
order
the
agent
can
actively
pursue
that
goal.
and reques
world that
must
be addressed.
developer.
The
proposed
template (Table I) is a refinement
o
trigger condition is an event that must occur in order tostate
startof the
It is worth
underlining
Trigger (language
Conditions for
andadvertisemen
that presented
in that
[35] both
for LARKS
acting for addressing the goal. The final state is the desired
Final States
must
be expressed
by
a Stateof
of the
Final
(FS) is the Condition
that
must
inusing
thesharing).
state
theWorld,
and
request
forhold
knowledge
state of theGoal's
world that
mustState
be addressed.
T EMPL
that
turn is expressed through domain ontology predicates.
It is worth
Trigger
andinas
worldunderlining
in orderthat
theboth
goal
can Conditions
be marked
addressed.
For a complete specification of the syntax of GoalSPEC
Final States must be expressed by using a State of the World,
TABLE I
Name
see [32]. Some
examples
of GoalSPEC productions for the
T EMPLATE
FOR DOCUMENTING A C APABILITY DESCRIPTION .
that in turn is expressed through domain ontology predicates.
InputPara
domain of the Meeting Scheduling are listed below:
GOALSpec
is the
language
For a complete
specification
of the
syntax ofconceived
GoalSPEC for specifying user-goals in a
Name
Unique label used to refer to the capability
format productions
that is possible
at run-time
see [32]. human-friendly
Some examples of GoalSPEC
for the to inject
OutputPa
1) WHEN InputParams
schedule(Usr,Meeting)
THE system
SHALL
Definition
of
the
input
variables
necessary
for
domain of the Meeting Scheduling are listed below:
wants
Operative Implementation of Goal
! 
! 
! 
PRODUCE canceled(Meeting)
confirmed(Meeting)
the OR
execution.
USER-GOAL_01
Constrain
USER-GOAL_02
OutputParams
Definition of the output variables produced by
AND meeting datetime(DT) AND
the execution.
Pre-Cond
system
SHALL PRODUCE
Optional (logical or structural) constraints on
input/output variables.
Post-Con
2) WHEN pending(Meeting) AND meeting datetime(DT) AND
3) AFTER 2 days SINCE WHEN notified(Usr,Meeting,DT)
1) WHEN schedule(Usr,Meeting) THE system SHALL
PRODUCE canceled(Meeting) OR confirmed(Meeting)
2) WHEN pending(Meeting)
attendee(Meeting,A) THE
notified(A,Meeting,DT)
Constraints
Musa Features
Norms
Rules in a Normative MAS: NORMSPEC
!  NORMSPEC is a structured language aiming to represent all
kinds of rules;
•  It is an intermediate language between a natural rule language
(like SBVR, Rulespeak) and an agent-based programming
language (Human/Machine readable)
!  NORMSPEC is domain independent and general purpose
Norms
!  NORMS in NormSPEC:
!  allow to define an organizational model at runtime by means of
structural rules.
!  The organizational model is not pre-existent.
!  may change at runtime
!  Norm injection
!  Norm deletion
!  make MASs self-adaptive (!self-configuring)
Musa Features
Capabilities
CAPABILITIES
!  The MUSA system is not hard-coded for providing specific functionalities
!  The idea is to provide the system with Capabilities, i.e. atomic and self-contained
actions:
!  programmed for being composable and reusable
!  often acting as a proxy for external services
!  Capabilities may be part of the initial system but they can also be injected at
runtime
!  Capabilities support self-awareness:
!  The system is aware of ‘when’ and ‘how’ to use a capability in order to address a
desired result (achieve a specific goal)
CAPABILITIES/2
!  Abstract Capabilities specify a “self-awareness” layer for agents
in order to reason over the opportunity of using them.
Knowledge about:
Name
Input
Output
Constraints
Params
Pre-Condition
Post-Condition
Evolution
flight booking
DptPlace : Airport,
DptDate: Date,
ArrPlace : Airport,
PassNum : Integer
DptSchedule: Date,
ArrSchedule: Date
DptP lace 6= ArrP lace
DptSchedule > DptDate
ArrSchedule > DptSchedule
P assN umber > 1
Flight Id : string
seat available(F lightId, DptSchedule,
P assN um)
f light booked(F lightId, DptSchedule,
P assN um)
evo = {remove(being at(DptP lace)),
add(being at(ArrP lace))}
data consumed in order to properly
work, and data produced as result
of the work
how to customize the capability
when the capability may be
executed and what to expect as
result
how to change the state of the
world
CAPABILITIES/3
!  Capability Implementation contains the instructions (code)
for concretely addressing the result.
!  The implementation code for a Service-Capability is made of
three independent parts
Dispose Service
Customize helper
FLIGHT_BOOKING CAPABILITY
search_
availability flight
id
get_flight
_info
FLIGHT_BOOKING CAPABILITY
book_seat
flight
departure,
destination,
schedule
FLIGHT BOOKING SERVICE PARTY
Compensate Service
FLIGHT_BOOKING CAPABILITY
cancel_booking
confirmation
FLIGHT BOOKING SERVICE
confirmation
FLIGHT BOOKING SERVICE
MUSA
Vision, Architecture and Implementation
The Vision
analyst
user
ontology
commitment
goal injection
ontology
commitment
Problem
POD
Ontology
MUSA RUNNING SYSTEM
WHAT
GOALS
PROACTIVE
MEANS-END
REASONING
HOW
service
provider
dev team
capability
deploy and
maintenance
service
provider
service
provider
bridge
CAPABILITIES
ACTIVE GOALS
TASKS
Norms
Capabilities
REAL SERVICES
MAS Social Structure - Holons
!  MUSA agents dynamically organize into holons
!  Holons provide an elegant and scalable agent architecture for
dealing with hierarchically decomposable problems
!  They guarantee knowledge sharing, distributed coordination
!  In MUSA, the injected goal introduces the commitment that
glues together an holon
!  user-goals represent the common objectives that trigger holons to
emerge
The Basic Holonic Schema
!  The following schema is the base for recursively creating holons
!  It exploits different agent cabilities for assigning three different roles within
the hierarchy:
!  Goal-Handler -> responsible of managing GoalSPEC and evaluating when
goals are addressed
!  Service-Broker -> responsible of maintaining a working session with external
services, checking failures and exceptions
!  State-Monitor -> responsible of monitoring the state of affair and to check if
the state is the expected one or is going to evolve as planned
head
holonic
schema
service
state
goal
broker
monitor
handler
MUSA Implementation
!  MUSA is based on a MAS developed in JaCaMo
!  BDI architecture
!  AgentSpeak derived language
!  Cartago for the coordinating artifacts
!  The system architecture is made of peers agents …
!  … able to self-organize in holonic hierarchies
The Proactive Means-End
Reasoning
The Proactive Means End Reasoning
MUSA RUNNING SYSTEM
what
ACTIVE GOALS
PROACTIVE*
MEANS.END*
REASONING
how
TASKS
The PROACTIVE MEANS-END REASONING is defined as
the algorithm for discovering the minimal set of couples
<agent, capability>
that can fully address the injected goal model,
given the current state of the world.
L. Sabatucci, M. Cossentino. From Means-End Analysis to Proactive Means-End Reasoning.
In proc. of SEAMS 2015, 10th International Symposium on Software Engineering for Adaptive
and Self-Managing Systems, May 18-19, 2015 Firenze, Best Paper Award.
Goal Decomposition and
Space Exploration
The goal model is
decomposed in a top-down
strategy
for each undecomposable goal,
the goal-handler explores the
space of solutions
the goal-handler asks
state-managers and service-brokers
to participate by selecting their
capabilities to use
partial solutions are aggregated
bottom-up
in order to address the rootgoal
one among all completesolutions is selected for
triggering holon formation
Conclusions and
Future Works
Why we can say MUSA self-adapts
!  MUSA supports self-adaptation:
!  Self-Healing
!  When a capability fails, the system searches for a new solution
!  Self-Configuration
!  Goals are not fixed at design-time, they are injected at runtime
!  Capabilities may change their behaviour according to parameters
!  Entities (agents), capabilities and related services are dynamically involved in the
solution and get organized in holons
!  Norms constraint the solution and may be injected at runtime
!  Self-Optimization:
!  Agents continuously search for a new way to accomplish their duty (goals they are
responsible for).
!  If a new solution is found (for instance because a better performing /cheaper/
… capability is injected in the system) the current solution is replaced by a
more optimal one at any time
Research Projects
!  MUSA has been employed in the following research project :
!  IDS (Innovative Document Sharing): Project started in 2011-closed in 2014 and funded by
the Autonomous Region of Sicily within the Regional Operative Plans (PO-FESR) of the EU
Community.
MUSA is the core engine for executing dynamic workflows in small/medium enterprises.
The architecture includes a BPMN2GOAL component that translates a BPMN 2.0 specification file
into a set of GoalSPEC goals.
!  OCCP (Open Cloud Computing Platform): Project started in 2014-to close in late 2015
and again funded by the Autonomous Region of Sicily within the PO-FESR initiative. MUSA
is currently employed for the automatic mash-up of cloud application. The expected result is
to allow a user to define a new cloud application as the integration (in terms of data and
process) of existing cloud applications.
!  PON SIGMA (integrated cloud system of sensors for advanced multi-risk
management). Project started in 2013-to close in early 2015. This project explores how to
merge protocols for emergency when many disasters (for instance earthquake and fire)
happen at the same time. MUSA is going to be employed for simulating security operations
according to goals and norms.
!  MUSA is planned to be employed in the following projects (starting in the next few
weeks):
!  PON Servify. Challenge: ubiquitum services and coordination
!  Progetto AMICO - Automazione e Monitoraggio Intelligente dei Consumi. Bando Industria
2015, Challenge: vessel emergency procedures decision support system
MUSA limits
!  The current version of MUSA is a prototype developed for research
purposes and tested for small-size applications
!  increasing the number of goals/norms the performance of the system
quickly decreases.
!  the proactive means-end algorithm is inefficient
!  Industrial applications are limited:
!  Goals, norms and capabilities are complex concepts to be hidden to
OO-programmers
!  we are studying a porting for the core parts in an object-oriented
programming language (such as Java),
!  Current version of MUSA requires capabilities (both abstract and
implementation) to be hand written
!  a better integration with a Cloud architecture is planned
!  for improving efficiency and scalability in real enterprise context
Future Works
!  We will try to improve the performance of proactive means-end
algorithm and the consequent scalability of the system
!  Relaxing the link between Capabilities and Goals/Norms.
!  the use of a static ontology is a limit when capabilities/goals/norms
evolve one independently from the others.
!  we are investigating linguistic techniques for making the process more
robust to ontology changes.
Thanks for your attention
Any question?