MUSA: A Middleware for User-driven Service Adaptation

GOAL LIFECYCLE

Injected

ActiveAddressed

Readycommit

FS=true

FS=false

TC=truecapability

failure

commitment failureretreat

MUSA

Massimo Cossentino, Carmelo Lodato, Salvatore Lopes, Luca Sabatucci

A Middleware for User-driven Service Adaptation

XVI Workshop dagli Oggetti agli Agenti, WOA 2015, Napoli, 17-19 Giugno 2015

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

Operative Implementation of Goal

!  Goal's Tirgger Condition (TC) is the Condition that must hold in the state of the world in order the agent can actively pursue that goal.

!  Goal's Final State (FS) is the Condition that must hold in the state of the world in order the goal can be marked as addressed.

!  GOALSpec is the language conceived for specifying user-goals in a human-friendly format that is possible to inject at run-time

GOAL LIFECYCLE

Injected ActiveReadycommitFS=true

FS=false

TC=true

state failurecommitment failure

[maintain-goal][achieve-goal]

Addressed

goal retreat

goal injection

GOAL

SUBJECTTRIGGER

CONDITIONFINAL STATE

EVENT STATE OF THE WORLD

wants

is active when is addressed when

generated by composed of

Fig. 7. The Core Metamodel of the Goal Specification Language.

a Trigger Condition and a Final State. The subject is a nounthat describes the name of the involved person, role or groupof persons that owns the responsibility to address the goal. Thetrigger condition is an event that must occur in order to startacting for addressing the goal. The final state is the desiredstate of the world that must be addressed.

It is worth underlining that both Trigger Conditions andFinal States must be expressed by using a State of the World,that in turn is expressed through domain ontology predicates.

For a complete specification of the syntax of GoalSPECsee [32]. Some examples of GoalSPEC productions for thedomain of the Meeting Scheduling are listed below:

1) WHEN schedule(Usr,Meeting) THE system SHALLPRODUCE canceled(Meeting) OR confirmed(Meeting)

2) WHEN pending(Meeting) AND meeting datetime(DT) ANDattendee(Meeting,A) THE system SHALL PRODUCEnotified(A,Meeting,DT)

3) AFTER 2 days SINCE WHEN notified(Usr,Meeting,DT)THE system SHALL PRODUCE accepted(Usr, Meeting,DT)OR rejected(Usr, Meeting,DT)

Each of the items shown before are goals. For purpose ofclarity we put in uppercase the keywords of the language, andin lowercase the domain specific predicates constrained by theproblem ontology (Figure 5). Goal 1 indicates that ‘when thesoftware agent knows a user is going to schedule a meeting,then it should bring the meeting to a state of canceled orconfirmed’. Goal 2 states that ‘when a meeting is yet in astate of pending, but a date-time is going to be proposed to aset of attendees, then each of these attendees has to be notifiedabout’. Finally, Goal 3 says that ‘when two days past sincethe notification has been sent, then the system must collect theresults (accepted or rejected)’.

After that a set of goals has been completed, it can beinjected into the running system, thus to let the system try toaddress them. We called this mechanism goal injection [33].

C. A Capability Specification LanguageIn AI, the need for representing software agent’s actions

in order to implement reasoning directed towards action is along-dated point of discussion [13], [21], [22], [34]. An agent

is able to achieve a goal by doing an action if i) the agentknows what the action is and ii) knows that doing the actionwould result in the goal being satisfied [21]. This topic hasbecome even more current because the amount of servicesdeployed in the web is exponentially growing and researchersare looking for ways for automatically searching, selecting andcomposing them [35].

We use Capability as an internal representation of an atomicunit of work that a software agent may use for addressingchanges in the state of the world. A Capability is made oftwo components: an abstract description (a set of beliefs thatmakes an agent aware of owning the capability and able toreason on its use), and a concrete body implementation (a setof plans for executing the job).

Whereas we define a template for providing the abstractdescription of a capability, we do not provide any language forthe body, leaving the choice of the specific technology to thedeveloper. The proposed template (Table I) is a refinement ofthat presented in [35] for LARKS (language for advertisementand request for knowledge sharing).

TABLE ITEMPLATE FOR DOCUMENTING A CAPABILITY DESCRIPTION.

Name Unique label used to refer to the capability

InputParams Definition of the input variables necessary forthe execution.

OutputParams Definition of the output variables produced bythe execution.

Constraints Optional (logical or structural) constraints oninput/output variables.

Pre-Condition Condition that must hold in the current state ofthe world in order to execute the capability.

Post-Condition Condition that must hold in the final state ofthe world in order to assert the capability hasbeen correctly executed.

Evolution Function of evolution evo : W �! W asdescribed in Section II

Tables II and III are two examples of capabilities that workwith emails. The Proposal Mail Sender capability encodesa question into the content of an email, thus the receivercan select two links, for answering yes or no. The secondcapability, Collect Response, looks at all the received answersto a given question and returns an array in which there is anitem for each user who replied.

There is also a special category of capabilities that is CloudCapability. These capabilities have been created for interactingwith a REST application on the cloud. An example is theGoogle Calendar Check capability reported in Table IV. Theaim of this capability is to interact with users’ google calendaraccount for obtaining whether a given time slot is free or busy.

D. Implementing Self-Awareness

Reasoning about knowledge and belief is still an issueof concern in philosophy and artificial intelligence. For the

GOAL

SUBJECTTRIGGER

CONDITIONFINAL STATE

EVENT STATE OF THE WORLD

wants

is active when is addressed when

generated by composed of

Fig. 7. The Core Metamodel of the Goal Specification Language.

a Trigger Condition and a Final State. The subject is a nounthat describes the name of the involved person, role or groupof persons that owns the responsibility to address the goal. Thetrigger condition is an event that must occur in order to startacting for addressing the goal. The final state is the desiredstate of the world that must be addressed.

It is worth underlining that both Trigger Conditions andFinal States must be expressed by using a State of the World,that in turn is expressed through domain ontology predicates.

For a complete specification of the syntax of GoalSPECsee [32]. Some examples of GoalSPEC productions for thedomain of the Meeting Scheduling are listed below:

1) WHEN schedule(Usr,Meeting) THE system SHALLPRODUCE canceled(Meeting) OR confirmed(Meeting)

2) WHEN pending(Meeting) AND meeting datetime(DT) ANDattendee(Meeting,A) THE system SHALL PRODUCEnotified(A,Meeting,DT)

3) AFTER 2 days SINCE WHEN notified(Usr,Meeting,DT)THE system SHALL PRODUCE accepted(Usr, Meeting,DT)OR rejected(Usr, Meeting,DT)

Each of the items shown before are goals. For purpose ofclarity we put in uppercase the keywords of the language, andin lowercase the domain specific predicates constrained by theproblem ontology (Figure 5). Goal 1 indicates that ‘when thesoftware agent knows a user is going to schedule a meeting,then it should bring the meeting to a state of canceled orconfirmed’. Goal 2 states that ‘when a meeting is yet in astate of pending, but a date-time is going to be proposed to aset of attendees, then each of these attendees has to be notifiedabout’. Finally, Goal 3 says that ‘when two days past sincethe notification has been sent, then the system must collect theresults (accepted or rejected)’.

After that a set of goals has been completed, it can beinjected into the running system, thus to let the system try toaddress them. We called this mechanism goal injection [33].

C. A Capability Specification LanguageIn AI, the need for representing software agent’s actions

in order to implement reasoning directed towards action is along-dated point of discussion [13], [21], [22], [34]. An agent

is able to achieve a goal by doing an action if i) the agentknows what the action is and ii) knows that doing the actionwould result in the goal being satisfied [21]. This topic hasbecome even more current because the amount of servicesdeployed in the web is exponentially growing and researchersare looking for ways for automatically searching, selecting andcomposing them [35].

We use Capability as an internal representation of an atomicunit of work that a software agent may use for addressingchanges in the state of the world. A Capability is made oftwo components: an abstract description (a set of beliefs thatmakes an agent aware of owning the capability and able toreason on its use), and a concrete body implementation (a setof plans for executing the job).

Whereas we define a template for providing the abstractdescription of a capability, we do not provide any language forthe body, leaving the choice of the specific technology to thedeveloper. The proposed template (Table I) is a refinement ofthat presented in [35] for LARKS (language for advertisementand request for knowledge sharing).

TABLE ITEMPLATE FOR DOCUMENTING A CAPABILITY DESCRIPTION.

Name Unique label used to refer to the capability

InputParams Definition of the input variables necessary forthe execution.

OutputParams Definition of the output variables produced bythe execution.

Constraints Optional (logical or structural) constraints oninput/output variables.

Pre-Condition Condition that must hold in the current state ofthe world in order to execute the capability.

Post-Condition Condition that must hold in the final state ofthe world in order to assert the capability hasbeen correctly executed.

Evolution Function of evolution evo : W �! W asdescribed in Section II

Tables II and III are two examples of capabilities that workwith emails. The Proposal Mail Sender capability encodesa question into the content of an email, thus the receivercan select two links, for answering yes or no. The secondcapability, Collect Response, looks at all the received answersto a given question and returns an array in which there is anitem for each user who replied.

There is also a special category of capabilities that is CloudCapability. These capabilities have been created for interactingwith a REST application on the cloud. An example is theGoogle Calendar Check capability reported in Table IV. Theaim of this capability is to interact with users’ google calendaraccount for obtaining whether a given time slot is free or busy.

D. Implementing Self-Awareness

Reasoning about knowledge and belief is still an issueof concern in philosophy and artificial intelligence. For the

USER-GOAL_01 USER-GOAL_02

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.

data consumed in order to properly work, and data produced as result of the work

when the capability may be executed and what to expect as resulthow to change the state of the world

how to customize the capability

Knowledge about: Name flight booking

Input DptPlace : Airport,

DptDate: Date,

ArrPlace : Airport,

PassNum : Integer

Output DptSchedule: Date,

ArrSchedule: Date

Constraints DptP lace 6= ArrP lace

DptSchedule > DptDate

ArrSchedule > DptSchedule

PassNumber > 1Params Flight Id : string

Pre-Condition seat available(FlightId,DptSchedule,

PassNum)Post-Condition flight booked(FlightId,DptSchedule,

PassNum)Evolution evo = {remove(being at(DptP lace)),

add(being at(ArrP lace))}

1

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

FLIGHT BOOKING SERVICE PARTY

FLIGHT_BOOKING CAPABILITY

Customize helper

flightdeparture,destination,schedule

get_flight_infoflight

id

search_availability

FLIGHT BOOKING SERVICE

FLIGHT_BOOKING CAPABILITY

book_seat

confirmation

Dispose Service

FLIGHT BOOKING SERVICE

cancel_booking

confirmation

FLIGHT_BOOKING CAPABILITY

Compensate Service

MUSA Vision, Architecture and Implementation

serviceprovider

MUSA RUNNING SYSTEM

GOALS

user analyst

ACTIVE GOALSCAPABILITIES

dev team

TASKSREAL SERVICES

goal injectioncapability

deploy and maintenance

serviceprovider

serviceprovider

bridge

WHAT HOW

PODontology

commitmentontology

commitment

The Vision

PROACTIVE MEANS-END REASONING

Problem Ontology

Norms Capabilities

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

holonic schema

head

statemonitor

servicebroker goal

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

ACTIVE GOALS TASKS

what

MUSA RUNNING SYSTEM

PROACTIVE*MEANS.END*REASONING

how

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 root-goal

one among all complete-solutions 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?