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