=Paper=
{{Paper
|id=Vol-1664/w12
|storemode=property
|title=Self-Configuring Mashup of Cloud Applications
|pdfUrl=https://ceur-ws.org/Vol-1664/w12.pdf
|volume=Vol-1664
|authors=Antonella Cavaleri,Massimo Cossentino,Carmelo Lodato,Salvatore Lopes,Luca Sabatucci
|dblpUrl=https://dblp.org/rec/conf/woa/CavaleriCLLS16
}}
==Self-Configuring Mashup of Cloud Applications==
https://ceur-ws.org/Vol-1664/w12.pdf
Self-Configuring Mashup of Cloud Applications
A.Cavaleri, M. Cossentino, C. Lodato, S. Lopes, L. Sabatucci
ICAR-CNR, Palermo, Italy
Email: {sabatucci,s.lopes,cossentino}@pa.icar.cnr.it
Abstract—This paper presents a general approach for au- tomer service business process of the B2B process of a big
tomatic composing and orchestrating applications distributed fashion firm1 .
over the cloud. The process is driven by user requirements The paper is organized as follows: Section II presents
that are made explicit though a goal specification language.
The self-configuration module dynamically organizes a mashup the concept of Cloud Application Mashup and provides a
application by composing existing cloud application as atomic real scenario emerged during a research project. Section III
brick to compose. Finally the orchestrator module is responsible introduces the goal-oriented language to specify user’s re-
of a seamless enacting of the selected cloud applications. A quirements. Section IV describes a three layer architecture
prototype has been implemented as a multi agent system for for self-configuration that is the core for service mashup.
implementing the business process for a company working for
fashion firms. Section V presents the orchestrator module and describes the
ad hoc business process obtained at run-time. Related works
I. I NTRODUCTION are discussed in Section VI whereas some Conclusions are
given in Section VII.
Cloud computing focuses on maximizing the effectiveness
of shared resources and information (that are provided to II. C LOUD A PPLICATION M ASHUP
users on-demand) and reducing the overall cost by using less The term mashup is a shortcoming for applications created
power, air conditioning, rack space, etc. Cloud applications by integrating modular components. It originates in the context
are currently developed as monolithic solutions tethered to of web applications for referring to a some kind of collabora-
proprietary stack architectures in which the provider typically tion between websites and/or webservices. In general a web-
runs all elements of the service [9]. These architectures are a based mashup is a resource that combines existing sources,
barrier for third-part developers to mix and match services whether it is content, data or application functionality, from
freely from diverse cloud service tiers to configure them more than one resource enabling end users to create and adapt
dynamically to address application needs [9]. individual information centric and situational applications.
The objective of Cloud Application Mashup is to enable So far, mashup is mainly intended as an instrument for
easy customization and composition of SaaS applications from web developers for integrating content from more than one
many providers by providing a cohesive solution that offers source in a new single graphical interface. Enablers of web
improved functionality to the client. In this paper we report a mashup are i) popular standard-based interface/communication
practical experience of Cloud Application Mashup that derives technologies (such as WSDL, REST, and RSS) and ii) the
from a background of research in self-configuring system and fact many Internet companies opened up their data to be used
dynamic workflow composition. through a set of APIs.
We describe an architecture for closing the gap between Now, we are moving towards a variety of Web Applications
goal-oriented requirement engineering [20] and autonomous that run over the Cloud as SaaS, the new mashup trend is
systems [5] with the aim of creating a highly customizable mixing data but also processes.
orchestration of distributed services. The request for a mashup
A. Cloud Application Mashup: The Enterprise Vision
is based on a technique we called goal-injection: a goal is the
high-level specification of the kind of service desired by the Cloud Applications are currently developed as monolithic
user. Goal orientation is used for decoupling the specification solutions in which the SaaS layer is tethered to proprietary
of what the system has to do from how it will be done. Service cloud stack architecture. The cloud provider runs all elements
compositions must not be programmed. Once a goal has been of the service and presents a complete application to the
introduced into the system, it becomes a stimulus for self- client [9]. This architecture hinders third-part developers to
configuring ad-hoc solutions in order to fulfill the request. mix and match services freely from diverse cloud service
The basic assumption is to make available some wrappers for tiers to configure them dynamically to address application
existing services and cloud applications, namely capabilities. It needs [9].
is a responsibility of the system to aggregate capabilities thus Cloud Application Mashup objective is to surpass vendor
to obtain composed behavior. Finally, orchestration is based lock-in (i.e. the situation in which customers are dependent
on establishing (temporary) collaborations between services 1 The research was partially funded by the Autonomous Region of Sicily,
according to self-configured conditions. A prototype has been Project OCCP (Open Cloud Computing Platform), within the Regional Oper-
developed as a multi-agent system for implementing a cus- ative Plans (PO-FESR) of the EU Community.
68
on a single manufacturer or supplier for some product) in C. A B2B Cloud Application for Fashion Firms
order to customize and combine SaaS applications from many A big manufacturer company who works in fashion (Fash-
providers. It provides ways to orchestrate a cohesive solution ionFirm 2 ) uses a legacy system to manage its informa-
that assembles virtual services in order to offer improved tion system (IBM AS/400) . They decided to improve their
functionality to the client. commercial network and designated Company.com, a small
We refined the current vision of Cloud Application Mashup software house, to handle their B2B processes. The resulting
as follows: system is built as a set of services running on a cloud stack: a
• Cloud services will be available via a cloud market- set of scalable backend services (VPN) capable of interacting
place in which providers store their offerings. Clients with the legacy system and a SaaS eCommerce platform
can discover and buy the needed services for third- (OrderPortal). The provided solution scales up very well for
party cloud applications that they can use for their own increasing the volume of requests by deploying clustered
mashup. Cloud services will be available through an ad- VPNs on the need.
hoc description language that provides all the relevant Given this existing scenario, the Company.com is demanded
aspects for their integration and usage. to extend the FashionFirm’s business process by adding new
• Mashups are created for the consuming user, often di- services for customer management. In order to improve cost-
rectly by the users themselves, so that they can take ad- effects these new services are conceived as cloud application
vantage of software licensing and billing model based on mashups. This allows to fast prototype the solution by reusing
the pay-per-use concept. Therefore users will establish or existing third part cloud applications (Cloud Calendar, File
modify situational collaborations for integrating services Storage and Voicemail).
from a variety of cloud providers. The mashup application that will be used as a running exam-
• There will be a mashup engine, offered as SaaS to clients. ple in this paper is intended to support customer relationships
It will act as a mediator for atomic cloud services in order during the order management process. ManyFirmsShop is a
to realize user’s mashup application. retailer of FashionFirm’s products. When the ManyFirmsShop
This vision may have substantial value for IT in this agent requests a stock of products (through the OrderPortal),
approach by improving the return-on-assets of the existing sys- the system merges VPN (used as usual to interact with
tems since Mashup enables fast and flexible B2B collaboration the legacy system) with external cloud applications existing
(short development cycles, cheap development) whereas exist- in the market: a Cloud Storage system to deliver receipts
ing B2B collaboration solutions focus on long-term business to ManyFirmsShop, Voicemail to communicate the delivery
relationships [15]. Short and cheap development cycles make status and, finally, a Cloud Calendar service for annotating
B2B solutions available for small and medium enterprises. the delivery date.
B. Preliminary Definitions III. T HE R EQUIREMENT AWARENESS
In this subsection we introduce some concepts that are used The primary driver of this work is allowing the end-user to
along the paper. For the sake of clarity the definitions are build her own mashup over the SaaS infrastructure according
provided in informal way, however, for the formal counterpart to personal requirements. At first analysis the easier choice was
please refer to [10], [12]. to use BPEL, the de facto standard language for orchestrating
The concept of goal is often used in the context of business web-services. However BPEL is a static model, whereas self-
process. A Goal is “a desired change in the state of the world configuration allows:
an actor wants to achieve”. Goals represent enterprise strategic • integrating dynamic user’s preferences into the flow of
interests that motivate the execution of business processes [20]. activities;
A Goal Model is a requirement engineering conceptual model • introducing new services without revising the whole
used to depict the strategic rationale of a business process workflow model;
in the form of a hierarchy of goals. It basically provides a • service failures may be discovered at run-time.
hierarchical decomposition of goals into sub-goals through We used self-configuration in order to configure a Cloud
AND/OR operators. In our approach goal-models are used to Application Mashup. The most important requisite it demands
specify the business logic of the desired service composition is the system be requirements-aware. A requirements-aware
in terms of which outcome the user will receive. system should be able to introspect about its requirements in
A Capability is a wrapper for cloud applications and ser- the same way that reflective middleware-based systems permit
vices that introduces a semantic description layer. It allows introspection about their architectural configuration [14]. In a
the developer to specify i) how to invoke the specified func- requirement aware system, requirements are at the same time:
tionality (which data must be passed and which data will be i) first class abstractions of the modeling language and ii) run-
returned) and ii) which effect is expected by executing the time entities over which the system can assess and reason
encapsulated application or service. The capability also has about.
the advantage of being automatically composable in order to
address a complex result. 2 Names in this scenario are obfuscated for privacy reasons.
69
In our approach, the GoalSPEC language [13] has been IV. S ELF -C ONFIGURATION
selected for implementing requirement awareness because it One of the prominent features of autonomic system is self-
uses goals for representing user’s requirements and it provides configuration i.e. the ability to automatically configure its own
the necessary characteristics for enabling goal injection and components thus to ensure the correct global functioning with
reasoning. It represents the first step in the direction of making respect to defined requirements [18].
end-user able to autonomously sketch up her requirements. It In a previous work [10] we have introduced the Proactive
is based on structured English and it adopts a core grammar Means-End Reasoning as the problem of automatically asso-
in which a domain vocabulary of terms can be plugged on. ciating system capabilities to user’s goals thus to achieve the
In GoalSPEC a goal is composed of three main com- desired functions. We have called PMR Ability the procedure
partments: a triggering condition (introduced by the ‘when’ for solving the proactive means-end reasoning problem. By
keyword) that states when the goal starts to be interesting for reasoning at the knowledge level the procedure returns 0..n
the system, a list of actors that are involved in, and a desired alternative Configurations for a given goal-model. It works
final state (introduced by the ‘address’ keyword) that describes by composing capabilities in order to match the final state
what is expected in terms of states of the world. For more specified by goals thus to solve the user’s request.
details about GoalSPEC see [13]. This section illustrates domain-independent architecture for
Listing 1. Set of GoalSPEC goals for the B2B scenario goal injection and self-configuring of cloud applications.
GOAL t o w a i t o r d e r : WHEN MESSAGE o r d e r RECEIVED FROM A. Goal Injection
THE u s e r ROLE
THE SYSTEM SHALL ADDRESS a v a i l a b l e ( O r d e r ) The proposed architecture handles run-time addition of new
GOAL t o r e t r i e v e u s e r d a t a : WHEN a v a i l a b l e ( O r d e r ) requirements [13], [11] moving a step forward traditional
THE SYSTEM SHALL ADDRESS a v a i l a b l e ( U s e r ) systems defined for satisfying a fixed set of hard-coded re-
GOAL t o c h e c k o r d e r : WHEN a v a i l a b l e ( O r d e r ) AND quirements.
a v a i l a b l e ( User ) The users may specify new requirements (in the form of
THE SYSTEM SHALL ADDRESS a c c e p t e d ( O r d e r ) OR r e f u s e d (
Order ) goal-models) to inject into the system at run-time thus they
become a stimulus for modifying the overall system behavior.
GOAL t o p r o d u c e r e c e i p t : WHEN a c c e p t e d ( O r d e r )
THE SYSTEM SHALL ADDRESS a v a i l a b l e ( R e c e i p t ) It is responsibility of the middleware, via the PMR Ability, to
configure itself to the new needs.
GOAL t o n o t i f y r e c e i p t : WHEN a v a i l a b l e ( U s e r ) AND
available ( Receipt ) On one hand, the system activates a goal injection monitor
THE SYSTEM SHALL ADDRESS that waits for goals from the user. On the other hand, user-
MESSAGE r e c e i p t SENT TO THE u s e r ROLE
goals are run-time entities, as well as other environment
GOAL t o d e l i v e r o r d e r : WHEN MESSAGE r e c e i p t SENT TO THE properties. The system acquires goals from the user and
u s e r ROLE
THE SYSTEM SHALL ADDRESS maintains knowledge of them thus to be able of reasoning on
MESSAGE d e l i v e r y o r d e r SENT TO THE s t o r e h o u s e m a n a g e r expected results and finally conditioning its global behavior.
ROLE
Of course, existing goals may be retreated as well.
GOAL t o n o t i f y f a i l u r e : WHEN a v a i l a b l e ( U s e r ) AND Goal injection enables user-requirements to evolve over time
r e f u s e d ( Order )
THE SYSTEM SHALL ADDRESS without either user-management or restarting the system. This
MESSAGE f a i l u r e SENT TO THE u s e r ROLE could be fundamental for some categories of domain in which
continuity of service is central (financial, service providing
An example of goal-model for the FashionFirm scenario is and so on).
reported in Figure 1, where goals are described in Listing 1. In addition it is possible to increase or enhance the functions
It is worth noting that such a goal model does not provide of the system just injecting a new set of requirements and
a logical ordering of the goals to address. It is up to the updating the repository with new domain-specific capabilities.
orchestrator module to deduct the best ordering that applies Given that connections between goals and capabilities are
to the current context. discovered on demand, the architecture is robust to capability
evolution and may be used for different problem domains
Fashion
Order
Management
without any other specific customization.
AND
B. A Three-Layered Architecture for Self-Configuration
Order Invoice Delivery The operative hypothesis for self-configuration is the system
Management Management Management
owns a repository with a redundant set of capabilities, thus
AND AND OR being able solve the same problem by exploiting different
to wait
to
to check
to
to notify to deliver to notify combinations of capabilities.
retrieve produce
order
userdata
order
receipt
receipt order failure
The proposed architecture is made of three layers: the goal
layer, the capability layer and the business layer.
Fig. 1. Goal-model for the FashionFirm scenario.
The uppermost layer of this architecture is the Goal Layer
in which the user may specify the expected behavior of the
70
system in terms of high-level goals. Goals are no hard-coded in after the capability execution for asserting either success or
a static goal-model defined at design time. The goal injection failure.
phase allows the introduction of user-goals defined at run-time. Evolution is a function that describes at knowledge level the
Goals are interpreted and analyzed and therefore trigger the possible impact of the capability for addressing a final state.
need of the system to generate a new configuration. This function is used in conjunction with grounded params
Name CHECK_STOREHOUSE
The second layer is the Capability Layer, based on solving for simulating the use of capabilities for self-configuration
Input
at run-time the problem of Proactive Means-End Reason- purposes [10], [12]. Order: Order
ing [10]. It aims at selecting the capabilities (and configuring Figure 2 shows an status:
Output enum(accepted,refused)
example of capability used by Com-
them) as a response to requests defined at the top layer. Pre-Condition available(Order)
pany.com: Upload On Cloud Storage is a wrapper for the
This corresponds to a strategic deliberation phase in which Dropbox upload endpoint
Post-Condition as discussed
accepted(Order) before. It receives a
OR refused(Order)
decisions are made according to the (often incomplete) system document to upload as input, and it requests a token and
knowledge about the environment. The output is the selection path asEvolution
parameters toevo={add(accepted(order)),
configure for working. The output is
add( refused(order) )}
of a set of capabilities that will form a concrete business the identification of the remote file.
process. This is obtained by instantiating system capabilities
into business task and associating capability parameters with Name UPLOAD_ON_CLOUD_STORAGE
data objects. In this phase the procedure also specifies depen- Input Invoice: Document
dencies among tasks and how data items are connected to task Output Remote_id: RxFile
input/output ports.
Params Token: String
The third layer is the Business Layer manages and inter- Dest_path: String
connects autonomous blocks of computation thus generating a Pre-Condition available(Invoice)
seamless integration for addressing the desired result specified Post-Condition uploaded_on_cloud(Invoice)
at the first layer. Section V describes the run-time orchestrator
that executes the business process generated at the second layer Evolution evo={add(uploaded_on_cloud(document))}
by interacting with the corresponding cloud applications and
web-services. Fig. 2. Example of capability for interfacing with a Cloud File Storage.
Name SHARE_LINK_FILE
C. Describing Capabilities for Self-Configuration
Input Invoice: Document
Capabilities play a central role in the aforementioned archi- Figure 3 show a couple of solutions for the FashionFirm sce-
UserMail : Email
tecture: to compose and execute capabilities the system must nario. Capabilities
Params are represented
Token: String in capital letters, followed
know what the service is and that executing the capability by assignments for their parameters.
Remote_id: RxFile
User: UserId
would result in a state of the world in which the goal being In thePre-Condition
first solution uploaded_on_cloud(Invoice)
(on the left) there is a coincidental direct
satisfied. In this approach each capability is a wrapper for a correspondence between goals and capabilities obtained as the
specific service or a cloud application. For instance Upload on result ofPost-Condition mailed_permanent_link(Invoice,
self-configuration. UserMail)does
In the case the customer AND not
sent(Invoice,User)
Cloud Storage is a wrapper for a generic Cloud File Storage grant the access to the
Evolution cloud storage service, the proactive
evo={add(mailed_permanent_link(document, email)),
HTTP endpoint that creates a new file in a remote path. Each means-end reasoning add( elaborates a different
sent(invoice,user) )} configuration (on
capability is bound to a block of code for authenticating and the right) where the goal to notify receipt is addressed by
invoke the specified endpoint. uploading the file in a Company.com’s private cloud storage
We adopted a language to specify the ‘self-configuration’ and then by sharing the URL via email.
part of a capability with the same the same kind of abstraction
V. T HE RUN -T IME O RCHESTRATOR
used for user’s goals (the knowledge level [8]). The following
language, inspired to LARKS [17]) responds to the need to This section describes the bottom layer of the proposed ar-
implement reasoning directed towards capabilities [19]. chitecture, in which a set of capabilities is harmonized thus to
The ‘self-configuration’ description is made of the following make the overall behavior consistent with user’s requirements.
compartments: The input of this phase is a set of associations hcap, goali
Name is the unique label used to refer to the capability generated through the proactive means-end reasoning. The
Input is the definition of the input Data Objects necessary desired output is a workflow model that addresses the root
for the execution. The existence of the specified DataObject goal of the goal-model.
is mandatory for enabling the capability execution The orchestrator module works according two principles:
Output is the definition of the output Data Objects produced • Principle 1: Dynamic Association between Capability
as result. and Goals. Each capability selected for addressing a goal
Params is an optional list of Variables that must be assigned is executed according to a specific schema3 .
to a value (grounded) in order to enable the execution. • Principle 2: Distributed Control. All the goals start in
Pre-Condition is a run-time logical condition that must hold parallel and are coordinated by conditions over the state
in the current state of the world in order to trigger the of the world and through exchange of data objects.
capability execution.
Post-Condition is a run-time logical condition that must hold 3 More details can be found in [12]
71
a) b)
to wait to retrieve to check to produce to notify to deliver to notify to notify
order userdata order receipt receipt order failure receipt
[RETRIEVE_USER_DATA] [GENERATE_RECEIPT_PDF]
[DELIVER_STOCK] [SHARE_LINK_FILE]
[UPLOAD_ON_CLOUD_STORAGE] [NOTIFY] [UPLOAD_ON_CLOUD_STORAGE]
[RETRIEVE_ORDER_DATA] [CHECK_STOREHOUSE] (CUSTOMER_ACCOUNT) (FAILURE) (COMPANY_ACCOUNT)
Fig. 3. On the left an example of assignment of capabilities to goals. On the left a detail of an alternative configuration in which a goal is addressed by the
composition of a couple of capabilities.
The Principle 1 arises from the fact that each capability is the proactive means-end reasoning in which the result is a
executed because it contributes to address one of the goals of set of capabilities for addressing goals, and also a contract
the goal-model. As stated in Section III a goal is described among the agents for working in collaboration. Therefore,
by a triggering-condition (TC) that specifies when it becomes service composition is obtained at run-time, as the result of
interesting for the system. This is the first condition that a self-organization phenomenon. More details of the MUSA
must hold for executing the capability. However also the architecture are reported in [12].
capability has a precondition to verify and some data objects Figure 4 shows some screenshots captured during the exe-
are necessary in order to execute it. At the same way, after cution of the FashionFirm scenario.
the capability is executed, the post-condition reveals whether
there is a failure. In addition, by comparing the achieved state VI. R ELATED W ORK
of the world with the goal’s final state the orchestrator reveals Some initiatives have been launched in last years for the
when the goal is addressed. automated orchestration of Cloud applications. A couple of
There is an additional motivation behind the way a capabil- representative examples are OpenCloudware and FIWARE.
ity lifecycle is structure. It already contains all the coordination OpenCloudware [1] aims at building an open software en-
information for synchronizing the execution of a capability gineering platform, for the collaborative development of dis-
with respect to all the others. Therefore the Principle 2 has tributed applications to be deployed on multiple Cloud infras-
been introduced to allow capabilities are deployed in a dis- tructures (mainly concerned with IaaS and PaaS). FIWARE
tributed and scalable system. By executing all the capabilities is an open architecture and a reference implementation of a
in parallel generates a distributed BPMN in which each branch novel service infrastructure [6] whose mission is: “to build
represents the instance of a different lifecycles. Different an open sustainable ecosystem around public, royalty-free
branches interact by two different synchronization approaches: and implementation-driven software platform standards that
i) passive mode: a branch waits a condition of the state of the will ease the development of new Smart Applications in
world is true, whereas this is generated as final state of another multiple sectors”. It offers an application mashup platform
capability of the workflow; ii) active mode: a branch needs a aimed at integrating heterogeneous data, application logic, and
data object as input parameter for the corresponding capability, UI components (widgets) sourced from the Web.
therefore a Query Interaction Protocol is employed to allows The presented approach can be classified among the alter-
the exchange of data. native approaches to classic workflow models for describing
It is worth noting the orchestrator may raise signals for self- service compositions, for instance semantic type matching
configuration (capability failure or unexpected state). Please approach for creating or updating a workflow [7] or planning
refer to [10] for details about re-configuration. based for composing a choreography [4].
A. MUSA: a Middleware for User-driven Service Adaptation Blanchet et al. [2] view service orchestration as a con-
versation among intelligent agents, each one responsible for
The Cloud Application Mashup has been realized through delivering the services of a participating organization. An
MUSA (Middleware for User-driven Service Adaptation) a agent also recognizes mismatches between its own workflow
multi-agent system for the composition and orchestration of model and the models of other agents.
services in a distributed and open environment. MUSA aims at OSIRIS [16] is an Open Service Infrastructure for Reliable
providing run-time modification of the flow of events, dynamic and Integrated process Support that consists of a peer-to-peer
hierarchies of services and integration of user preferences to- decentralized service execution engine and organizes services
gether with a system for run-time monitoring of activities that into a self-organizing ring topology.
is also able to deal with unexpected failures and optimization.
MUSA4 , has been implemented by using JASON [3], an VII. C ONCLUSIONS
agent oriented platform and programming language based
This paper has described the practical experience of Cloud
events and actions. It implements a distributed version of
Application Mashup, made in the context of a research project.
4 Available at https://github.com/icar-aose/MUSA/archive/v0.2.zip (Jason We adopted MUSA as the middleware for service composition
1.3.8 or higher is required). and adaptation. This allowed defining the business logic of
72
OrderPortal
Cloud Storage
Share Link by Mail
Cloud Calendar
Fig. 4. Screenshots of the mashup application: OrderPortal is the web application for warehouse orders, a Cloud Storage service is adopted where the invoice
is uploaded, a mail service allows to send the link to the remote invoice, and a Cloud Calendar service is used for annotating the stock delivery date.
the mashup in the form of goal model plus a set of Goal- [11] L. Sabatucci, C. Lodato, S. Lopes, and M. Cossentino. Towards self-
SPEC specifications. On the other side the involved Cloud adaptation and evolution in business process. In AIBP@ AI* IA, pages
1–10. Citeseer, 2013.
applications have been decomposed in a set of components to [12] L. Sabatucci, C. Lodato, S. Lopes, and M. Cossentino. Highly customiz-
wrap into capabilities and to describe through a template based able service composition and orchestration. In S. Dustdar, F. Leymann,
on descriptive logic. The middleware offers a three layer- and M. Villari, editors, Service Oriented and Cloud Computing, volume
9306 of Lecture Notes in Computer Science, pages 156–170. Springer
architecture for monitoring goal injections, self-configuring International Publishing, 2015.
ad-hoc solutions and finally to orchestrate Cloud components. [13] L. Sabatucci, P. Ribino, C. Lodato, S. Lopes, and M. Cossentino. Goal-
The approach has been employed in the context of a B2B spec: A goal specification language supporting adaptivity and evolution.
In Engineering Multi-Agent Systems, pages 235–254. Springer, 2013.
process for customer management of a big company working [14] P. Sawyer, N. Bencomo, J. Whittle, E. Letier, and A. Finkelstein.
in fashion. Requirements-aware systems: A research agenda for re for self-adaptive
systems. In Requirements Engineering Conference (RE), 2010 18th IEEE
International, pages 95–103. IEEE, 2010.
R EFERENCES [15] R. Siebeck, T. Janner, C. Schroth, V. Hoyer, W. Wörndl, and F. Urmetzer.
Cloud-based enterprise mashup integration services for b2b scenarios.
[1] T. Aubonnet and N. Simoni. Self-control cloud services. In Network In Proceedings of the 2nd workshop on mashups, enterprise mashups
Computing and Applications (NCA), 2014 IEEE 13th International and lightweight composition on the web, Madrid, 2009.
Symposium on, pages 282–286. IEEE, 2014. [16] N. Stojnic and H. Schuldt. Osiris-sr: A safety ring for self-healing
[2] W. Blanchet, E. Stroulia, and R. Elio. Supporting adaptive web-service distributed composite service execution. In Software Engineering for
orchestration with an agent conversation framework. In Web Services, Adaptive and Self-Managing Systems (SEAMS), 2012 ICSE Workshop
2005. ICWS 2005. Proceedings. 2005 IEEE International Conference on, pages 21–26, 2012.
on. IEEE, 2005. [17] K. Sycara, S. Widoff, M. Klusch, and J. Lu. Larks: Dynamic matchmak-
[3] R. Bordini, J. Hübner, and M. Wooldridge. Programming multi-agent ing among heterogeneous software agents in cyberspace. Autonomous
systems in AgentSpeak using Jason, volume 8. Wiley-Interscience, 2007. agents and multi-agent systems, 5(2):173–203, 2002.
[4] M. Carman, L. Serafini, and P. Traverso. Web service composition as [18] D. Sykes, W. Heaven, J. Magee, and J. Kramer. From goals to
planning. In ICAPS 2003 workshop on planning for web services, pages components: a combined approach to self-management. In Proceedings
1636–1642, 2003. of the 2008 international workshop on Software engineering for adaptive
[5] J. Ferber, O. Gutknecht, and F. Michel. From agents to organizations: An and self-managing systems, pages 1–8. ACM, 2008.
organizational view of multi-agent systems. In Agent-Oriented Software [19] M. J. Wooldridge. Reasoning about rational agents. MIT press, 2000.
Engineering IV, pages 214–230. Springer, 2004. [20] E. Yu and J. Mylopoulos. Why goal-oriented requirements engineer-
[6] A. Glikson. Fi-ware: Core platform for future internet applications. In ing. Proceedings of the 4th International Workshop on Requirements
Proceedings of the 4th Annual International Conference on Systems and Engineering: Foundations of Software Quality, 15, 1998.
Storage, 2011. [21] J. L. Zhao, M. Tanniru, and L.-J. Zhang. Services computing as
[7] M. Laukkanen and H. Helin. Composing workflows of semantic web the foundation of enterprise agility: Overview of recent advances and
services. In Extending Web Services Technologies, pages 209–228. introduction to the special issue. Information Systems Frontiers, 9(1):1–
Springer, 2004. 8, 2007.
[8] A. Newell. The knowledge level. Artificial intelligence, 18(1):87–127,
1982.
[9] M. P. Papazoglou and W.-J. van den Heuvel. Blueprinting the cloud.
IEEE Internet Computing, 6:74–79, 2011.
[10] L. Sabatucci and M. Cossentino. From Means-End Analysis to Proactive
Means-End Reasoning. In Proceedings of 10th International Symposium
on Software Engineering for Adaptive and Self-Managing Systems,
Florence, Italy, May 18-19 2015.
73