-This paper presents a general approach for automatic composing and orchestrating applications distributed over the cloud. The process is driven by user requirements that are made explicit though a goal specification language. The self-configuration module dynamically organizes a mashup application by composing existing cloud application as atomic brick to compose. Finally the orchestrator module is responsible of a seamless enacting of the selected cloud applications. A prototype has been implemented as a multi agent system for implementing the business process for a company working for fashion firms.
Cloud computing focuses on maximizing the effectiveness
of shared resources and information (that are provided to
users on-demand) and reducing the overall cost by using less
power, air conditioning, rack space, etc. Cloud applications
are currently developed as monolithic solutions tethered to
proprietary stack architectures in which the provider typically
runs all elements of the service [
The objective of Cloud Application Mashup is to enable easy customization and composition of SaaS applications from many providers by providing a cohesive solution that offers improved functionality to the client. In this paper we report a practical experience of Cloud Application Mashup that derives from a background of research in self-configuring system and dynamic workflow composition.
We describe an architecture for closing the gap between
goal-oriented requirement engineering [
The paper is organized as follows: Section II presents the concept of Cloud Application Mashup and provides a real scenario emerged during a research project. Section III introduces the goal-oriented language to specify user’s requirements. Section IV describes a three layer architecture for self-configuration that is the core for service mashup. Section V presents the orchestrator module and describes the ad hoc business process obtained at run-time. Related works are discussed in Section VI whereas some Conclusions are given in Section VII.
The term mashup is a shortcoming for applications created by integrating modular components. It originates in the context of web applications for referring to a some kind of collaboration between websites and/or webservices. In general a webbased mashup is a resource that combines existing sources, whether it is content, data or application functionality, from more than one resource enabling end users to create and adapt individual information centric and situational applications.
So far, mashup is mainly intended as an instrument for web developers for integrating content from more than one source in a new single graphical interface. Enablers of web mashup are i) popular standard-based interface/communication technologies (such as WSDL, REST, and RSS) and ii) the fact many Internet companies opened up their data to be used through a set of APIs.
Now, we are moving towards a variety of Web Applications that run over the Cloud as SaaS, the new mashup trend is mixing data but also processes.
Cloud Applications are currently developed as monolithic
solutions in which the SaaS layer is tethered to proprietary
cloud stack architecture. The cloud provider runs all elements
of the service and presents a complete application to the
client [
Cloud Application Mashup objective is to surpass vendor lock-in (i.e. the situation in which customers are dependent 1The research was partially funded by the Autonomous Region of Sicily, Project OCCP (Open Cloud Computing Platform), within the Regional Operative Plans (PO-FESR) of the EU Community. on a single manufacturer or supplier for some product) in order to customize and combine SaaS applications from many providers. It provides ways to orchestrate a cohesive solution that assembles virtual services in order to offer improved functionality to the client.
We refined the current vision of Cloud Application Mashup as follows: • Cloud services will be available via a cloud marketplace in which providers store their offerings. Clients can discover and buy the needed services for thirdparty cloud applications that they can use for their own mashup. Cloud services will be available through an adhoc description language that provides all the relevant aspects for their integration and usage. • Mashups are created for the consuming user, often directly by the users themselves, so that they can take advantage of software licensing and billing model based on the pay-per-use concept. Therefore users will establish or modify situational collaborations for integrating services from a variety of cloud providers. • There will be a mashup engine, offered as SaaS to clients.
It will act as a mediator for atomic cloud services in order to realize user’s mashup application.
This vision may have substantial value for IT in this
approach by improving the return-on-assets of the existing
systems since Mashup enables fast and flexible B2B collaboration
(short development cycles, cheap development) whereas
existing B2B collaboration solutions focus on long-term business
relationships [
In this subsection we introduce some concepts that are used
along the paper. For the sake of clarity the definitions are
provided in informal way, however, for the formal counterpart
please refer to [
The concept of goal is often used in the context of business
process. A Goal is “a desired change in the state of the world
an actor wants to achieve”. Goals represent enterprise strategic
interests that motivate the execution of business processes [
A Capability is a wrapper for cloud applications and services that introduces a semantic description layer. It allows the developer to specify i) how to invoke the specified functionality (which data must be passed and which data will be returned) and ii) which effect is expected by executing the encapsulated application or service. The capability also has the advantage of being automatically composable in order to address a complex result.
A big manufacturer company who works in fashion (FashionFirm 2) uses a legacy system to manage its information system (IBM AS/400) . They decided to improve their commercial network and designated Company.com, a small software house, to handle their B2B processes. The resulting system is built as a set of services running on a cloud stack: a set of scalable backend services (VPN) capable of interacting with the legacy system and a SaaS eCommerce platform (OrderPortal). The provided solution scales up very well for increasing the volume of requests by deploying clustered VPNs on the need.
Given this existing scenario, the Company.com is demanded to extend the FashionFirm’s business process by adding new services for customer management. In order to improve costeffects these new services are conceived as cloud application mashups. This allows to fast prototype the solution by reusing existing third part cloud applications (Cloud Calendar, File Storage and Voicemail).
The mashup application that will be used as a running example in this paper is intended to support customer relationships during the order management process. ManyFirmsShop is a retailer of FashionFirm’s products. When the ManyFirmsShop agent requests a stock of products (through the OrderPortal), the system merges VPN (used as usual to interact with the legacy system) with external cloud applications existing in the market: a Cloud Storage system to deliver receipts to ManyFirmsShop, Voicemail to communicate the delivery status and, finally, a Cloud Calendar service for annotating the delivery date.
The primary driver of this work is allowing the end-user to build her own mashup over the SaaS infrastructure according to personal requirements. At first analysis the easier choice was to use BPEL, the de facto standard language for orchestrating web-services. However BPEL is a static model, whereas selfconfiguration allows: • integrating dynamic user’s preferences into the flow of activities; • introducing new services without revising the whole workflow model; • service failures may be discovered at run-time.
We used self-configuration in order to configure a Cloud
Application Mashup. The most important requisite it demands
is the system be requirements-aware. A requirements-aware
system should be able to introspect about its requirements in
the same way that reflective middleware-based systems permit
introspection about their architectural configuration [
In our approach, the GoalSPEC language [
In GoalSPEC a goal is composed of three main
compartments: a triggering condition (introduced by the ‘when’
keyword) that states when the goal starts to be interesting for
the system, a list of actors that are involved in, and a desired
final state (introduced by the ‘address’ keyword) that describes
what is expected in terms of states of the world. For more
details about GoalSPEC see [
Listing 1. Set of GoalSPEC goals for the B2B scenario GOAL t o w a i t o r d e r : WHEN MESSAGE o r d e r RECEIVED FROM
THE u s e r ROLE THE SYSTEM SHALL ADDRESS a v a i l a b l e ( Order ) 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 ( Order ) THE SYSTEM SHALL ADDRESS a v a i l a b l e ( User ) GOAL t o c h e c k o r d e r : WHEN a v a i l a b l e ( Order ) AND
a v a i l a b l e ( User ) THE SYSTEM SHALL ADDRESS a c c e p t e d ( Order ) OR r e f u s e d (
Order ) 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 ( Order ) THE SYSTEM SHALL ADDRESS a v a i l a b l e ( R e c e i p t ) 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 ( User ) AND a v a i l a b l e ( R e c e i p t ) THE SYSTEM SHALL ADDRESS MESSAGE r e c e i p t SENT TO THE u s e r ROLE 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 u s e r ROLE THE SYSTEM SHALL ADDRESS 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
ROLE 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 ( User ) AND r e f u s e d ( Order ) THE SYSTEM SHALL ADDRESS
MESSAGE f a i l u r e SENT TO THE u s e r ROLE
An example of goal-model for the FashionFirm scenario is reported in Figure 1, where goals are described in Listing 1. It is worth noting that such a goal model does not provide a logical ordering of the goals to address. It is up to the orchestrator module to deduct the best ordering that applies to the current context.
Fashion
Order Management
AND MaInnavgoeicmeent
AND
Delivery Management
OR
One of the prominent features of autonomic system is
selfconfiguration i.e. the ability to automatically configure its own
components thus to ensure the correct global functioning with
respect to defined requirements [
In a previous work [
This section illustrates domain-independent architecture for goal injection and self-configuring of cloud applications.
The proposed architecture handles run-time addition of new
requirements [
The users may specify new requirements (in the form of goal-models) to inject into the system at run-time thus they become a stimulus for modifying the overall system behavior. It is responsibility of the middleware, via the PMR Ability, to configure itself to the new needs.
On one hand, the system activates a goal injection monitor that waits for goals from the user. On the other hand, usergoals are run-time entities, as well as other environment properties. The system acquires goals from the user and maintains knowledge of them thus to be able of reasoning on expected results and finally conditioning its global behavior. Of course, existing goals may be retreated as well.
without either user-management or restarting the system. This could be fundamental for some categories of domain in which continuity of service is central (financial, service providing and so on).
of the system just injecting a new set of requirements and updating the repository with new domain-specific capabilities. Given that connections between goals and capabilities are discovered on demand, the architecture is robust to capability evolution and may be used for different problem domains without any other specific customization.
The operative hypothesis for self-configuration is the system owns a repository with a redundant set of capabilities, thus being able solve the same problem by exploiting different combinations of capabilities.
The proposed architecture is made of three layers: the goal layer, the capability layer and the business layer.
The uppermost layer of this architecture is the Goal Layer in which the user may specify the expected behavior of the system in terms of high-level goals. Goals are no hard-coded in a static goal-model defined at design time. The goal injection phase allows the introduction of user-goals defined at run-time. Goals are interpreted and analyzed and therefore trigger the need of the system to generate a new configuration.
The second layer is the Capability Layer, based on solving
at run-time the problem of Proactive Means-End
Reasoning [
The third layer is the Business Layer manages and interconnects autonomous blocks of computation thus generating a seamless integration for addressing the desired result specified at the first layer. Section V describes the run-time orchestrator that executes the business process generated at the second layer by interacting with the corresponding cloud applications and web-services.
Capabilities play a central role in the aforementioned architecture: to compose and execute capabilities the system must know what the service is and that executing the capability would result in a state of the world in which the goal being satisfied. In this approach each capability is a wrapper for a specific service or a cloud application. For instance Upload on Cloud Storage is a wrapper for a generic Cloud File Storage HTTP endpoint that creates a new file in a remote path. Each capability is bound to a block of code for authenticating and invoke the specified endpoint.
We adopted a language to specify the ‘self-configuration’
part of a capability with the same the same kind of abstraction
used for user’s goals (the knowledge level [
The ‘self-configuration’ description is made of the following compartments: Name is the unique label used to refer to the capability Input is the definition of the input Data Objects necessary for the execution. The existence of the specified DataObject is mandatory for enabling the capability execution Output is the definition of the output Data Objects produced as result.
Params is an optional list of Variables that must be assigned to a value (grounded) in order to enable the execution. Pre-Condition is a run-time logical condition that must hold in the current state of the world in order to trigger the capability execution.
Post-Condition is a run-time logical condition that must hold after the capability execution for asserting either success or failure.
Evolution is a function that describes at knowledge level the
possible impact of the capability for addressing a final state.
This function is used in conjunction with grounded params
for simNualmateing the useCHoECfKc_SaTpOaRbEiHliOtiUeSsE for self-configuration
purposeIsnp[u1t0], [
FigurOeut2putshows an steaxtuasm:epnluem(oafccecpatpeda,breifluitsyed)used by Company.coPmre:-CUonpdliotiaond OnavCaillaobuled(OrSdteorr)age is a wrapper for the DropboPxosut-pCloonadditioenndpaocicnetptaeds(Odridsecr)uOsRserdefubseedf(oOrrede.r)It receives a document to upload as input, and it requests a token and path asEvpoaluratimoneters toevcoo=n{afigdudr(eacceptedw(oorrdkeri)n)g,. The output is for add( refused(order) )} the identification of the remote file.
Name Input Output Params Pre-Condition
UPLOAD_ON_CLOUD_STORAGE Invoice: Document Remote_id: RxFile Token: String Dest_path: String available(Invoice) Post-Condition uploaded_on_cloud(Invoice) Evolution
evo={add(uploaded_on_cloud(document))} Fig. 2. Example of capability for interfacing with a Cloud File Storage.
Name
SHARE_LINK_FILE FigurIenp3utshow a couInpvloeicoef:Dsoocluumtieonnt s for the FashionFirm sce
UserMail : Email nario. CPaarpaambsilities areTorkeepn:reStsreinngted in capital letters, followed by assignments for thReeimroptea_riadm:RextFeilres.
User: UserId In thePrfires-tCosnodliutitoionn (oupnloadedl_eofnt_)cltohuedr(eInvisoicae)coincidental direct the correspondence between goals and capabilities obtained as the result oPfosset-lCfo-ncdointifigonuramtiaoinle.d_Ipnertmhaenecnats_leinkth(Ienvcoiucse,toUsmereMradil)oAeNsDnot grant thEevolaucticoenss to tsehevenot=(c{Inalvdoodui(cdme,aUsislteeodr)r_paegremasneernvt_ilcinek,(dtohceumpernot,aecmtiavile)), means-end reasoningaeddla( bseonrta(itnevsoicae,udsiefrf)e)r}ent configuration (on the right) where the goal to notify receipt is addressed by uploading the file in a Company.com’s private cloud storage and then by sharing the URL via email.
This section describes the bottom layer of the proposed architecture, in which a set of capabilities is harmonized thus to make the overall behavior consistent with user’s requirements.
The input of this phase is a set of associations hcap, goali generated through the proactive means-end reasoning. The desired output is a workflow model that addresses the root goal of the goal-model.
The orchestrator module works according two principles:
• Principle 1: Dynamic Association between Capability
and Goals. Each capability selected for addressing a goal
is executed according to a specific schema 3.
• Principle 2: Distributed Control. All the goals start in
parallel and are coordinated by conditions over the state
of the world and through exchange of data objects.
3More details can be found in [
The Principle 1 arises from the fact that each capability is executed because it contributes to address one of the goals of the goal-model. As stated in Section III a goal is described by a triggering-condition (TC) that specifies when it becomes interesting for the system. This is the first condition that must hold for executing the capability. However also the capability has a precondition to verify and some data objects are necessary in order to execute it. At the same way, after the capability is executed, the post-condition reveals whether there is a failure. In addition, by comparing the achieved state of the world with the goal’s final state the orchestrator reveals when the goal is addressed.
There is an additional motivation behind the way a capability lifecycle is structure. It already contains all the coordination information for synchronizing the execution of a capability with respect to all the others. Therefore the Principle 2 has been introduced to allow capabilities are deployed in a distributed and scalable system. By executing all the capabilities in parallel generates a distributed BPMN in which each branch represents the instance of a different lifecycles. Different branches interact by two different synchronization approaches: i) passive mode: a branch waits a condition of the state of the world is true, whereas this is generated as final state of another capability of the workflow; ii) active mode: a branch needs a data object as input parameter for the corresponding capability, therefore a Query Interaction Protocol is employed to allows the exchange of data.
It is worth noting the orchestrator may raise signals for
selfconfiguration (capability failure or unexpected state). Please
refer to [
The Cloud Application Mashup has been realized through MUSA (Middleware for User-driven Service Adaptation) a multi-agent system for the composition and orchestration of services in a distributed and open environment. MUSA aims at providing run-time modification of the flow of events, dynamic hierarchies of services and integration of user preferences together with a system for run-time monitoring of activities that is also able to deal with unexpected failures and optimization.
MUSA4, has been implemented by using JASON [
Figure 4 shows some screenshots captured during the execution of the FashionFirm scenario.
Some initiatives have been launched in last years for the
automated orchestration of Cloud applications. A couple of
representative examples are OpenCloudware and FIWARE.
OpenCloudware [
The presented approach can be classified among the
alternative approaches to classic workflow models for describing
service compositions, for instance semantic type matching
approach for creating or updating a workflow [
Blanchet et al. [
OSIRIS [
This paper has described the practical experience of Cloud Application Mashup, made in the context of a research project. We adopted MUSA as the middleware for service composition and adaptation. This allowed defining the business logic of
the mashup in the form of goal model plus a set of GoalSPEC specifications. On the other side the involved Cloud applications have been decomposed in a set of components to wrap into capabilities and to describe through a template based on descriptive logic. The middleware offers a three layerarchitecture for monitoring goal injections, self-configuring ad-hoc solutions and finally to orchestrate Cloud components. The approach has been employed in the context of a B2B process for customer management of a big company working in fashion.