The main beneficiaries of the Cloud4SOA’s capabilities are the Cloud-based applica- tion developer and Cloud PaaS provider. A developer may be a free-lancer or working for a company who wants to deploy their applications on a PaaS offering, a software company that wants to use a local PaaS for internal development or an Independent Software Vendor (ISV) interested in selling SaaS services on top of a hosted PaaS. On the other hand, a PaaS provider may be a small-medium enterprise (SME) or a larger industry working in the PaaS field.
Cloud4SOA combines three fundamental and complementary computing para- digms, namely Cloud computing, Service Oriented Architectures (SOA) and light- weight semantics, to propose a reference architecture and deploy fully operational prototypes optimising the initial envisioned architecture [15]. The envisioned broker- based reference architecture that exhibits these characteristics is depicted in Fig. 1 and consists of five layers, three horizontal and two vertical, outlined below.
Fig. 1. Cloud4SOA Reference Architecture
4.1 Frond-end Layer
The Front-end layer supports the user-centric focus of the Cloud4SOA and the easy access of both developers and PaaS providers to Cloud4SOA’s functionalities ex- posed via widgetized services which are adaptable to the user’s context.
The Front-end layer makes use of a web-based interface that implements a design metaphor based on the concept of a dashboard. The choice is motivated by the fact that the user needs an overview about the performance of the application(s) deployed on different PaaS providers and a centralized point for managing applications. The dashboard offers a set of widgets which allow encapsulating functionality in a self- contained application, i.e. an application with a front-end and business logic. Widgets
can be modelled to correspond to the different actions the user wants to perform on the platform, e.g. search a PaaS offering or deploy an application. At the same time, they can be grouped in different ways to allow presenting the user only with the func- tionalities he is likely to need in the course of a certain activity.
4.2 SOA Layer
The SOA layer acts as a mediator to the other layers’ services, translating a resource centric architecture, provided by the Semantic layer with its implementation and management concepts, into the high-level architecture, letting Front-end layer access Cloud4SOA’s core functionalities. The SOA layer comprises of a toolbox that is accessible through the adaptable Front-end layer including:
The Profile Management module capitalizes on the models provided by the Seman- tic layer to enable the management of the semantic profiles, namely PaaS offerings, applications and user profiles.
The PaaS Matchmaking module relies on the search mechanisms offered by the Repository layer and employs lightweight semantic models and techniques in order to find available, best matching (according to user requirements) PaaS offerings.
The PaaS Recommendation module offers suggestions for the best matches of PaaS offerings. The degree of relation between a PaaS offering and an application is com- puted based on the similarity of their semantic profiles. Moreover this module offers a rating mechanism that enables the user rating and the system automatic rating (based on SLA violations) of PaaS offerings.
The Application Deployment module capitalizes on the functionality offered by the Cloud4SOA Harmonized API to provide a set of back-end capabilities including de- ployment and governance (start, stop and undeploy) of applications on PaaS offerings.
The Application Migration module facilitates the user in migrating to another PaaS offering while it tackles the semantic interoperability conflicts that are raised when applications need to migrate between different Cloud PaaS offerings.
The Application Monitoring module provides the interface to interact with the moni- toring functionality and to retrieve the collected data according to different parameters.
4.3 Semantic Layer and Cloud4SOA Semantic Model
The Semantic layer is the backbone of the architecture that puts in place the PaaS Semantic Interoperability Framework (PSIF) [15] and facilitates the formal represen- tation of information (i.e. PaaS offerings, applications and user profiles). It spans the entire architecture resolving interoperability conflicts and providing a common basis for publishing and searching different PaaS offerings. Each of the three main compo- nents has a unique objective and utilizes a specific set of fundamental PaaS entities depending on its focus, implementing in this way a specific part of the adopted the Cloud4SOA Semantic Model.
The Cloud4SOA Semantic Model, depicted in Fig. 2, serves as a means for the unification and the disciplined representation of different Cloud systems. It consists of five tiers, where each tier describes a set of fundamental PaaS entities and their relations:
• The Infrastructure tier c cepts such as hardware and QoS parameters. Th tions and PaaS offerings,
• The Platform tier is use offerings using entities prise. It is based on the is the PaaS offering.
• The Application tier is u entities related to the app Cloud-based Application
• The User tier facilitates system to create a seman
• The Enterprise tier des layer and their relations concepts such as of the P
F
4.4 Governance Layer
The Governance layer im where developers can estab ance and mitigate violation Cloud-based applications, scalability issues. In particu The Execution Managem thing related to the applicat tenance and migration relate
captures knowledge related to infrastructure modeling c component, software component, programming langu his tier offers a common language to describe both appli
, thus enabling their matching.
ed by PaaS providers to semantically annotate their P to describe the platform, the infrastructure and the en Infrastructure tier in order to operate and its main conc used by developers to annotate their applications utiliz plication’s requirements. It captures knowledge related t n and the central concept of this tier is the Application.
the users’ annotation enabling any user in the Cloud4S ntic profile reusing concepts coming from FOAF ontolog
cribes the enterprises that participate at the Cloud P s with other entities (e.g. users). This tier mainly mod PaaS provider and the SLA agreement.
Fig. 2. Cloud4SOA Semantic Model
mplements the business-centric focus of the Cloud4S blish their user-defined SLA metrics to measure perfo ns. It enables the lifecycle execution and management
taking into account monitoring information, SLAs ular:
ment Service (EMS) module is the key interface in eve tion lifecycle including deployment, un-deployment, ma
ed tasks. con- uage ica- PaaS nter- cept zing to a OA gy. PaaS dels OA rm- t of and ery- ain-
The Monitoring module is responsible for monitoring applications’ and platform’s health. It is based on a unified and Cloud platform-independent approach in order to consider heterogeneity of different Clouds architectures.
The SLA module enables the SLA management. The SLA module consists of three sub-components that interact with the Monitoring and EMS modules:
The SLA Negotiation allows Cloud4SOA to perform automatic negotiations on be- half of PaaS providers, based on the semantic description of offerings and the QoS requirements specified by the developer. However, in the scope of project, SLAs do not aim at representing a contractual relationship between the customers consuming virtualized Platforms and the PaaS vendors that provide them. SLAs describe the service that is delivered, the functional and non-functional properties of the resource, and the duties of each party involved.
The SLA Enforcement is in charge of supervising that all the agreements (SLAs guarantees) are respected.
The SLA-Decisor is responsible for dealing with the violations and deciding the appropriate recovery action to take (stop, migration, etc.) when a violation occurs.
4.5 Repository Layer and Cloud4SOA Harmonized API
Cloud4SOA uses a persistency layer, named Repository layer, in order to store both semantic and syntactic data. In order for Cloud4SOA to provide high-level functional- ities (e.g. matchmaking) it needs to persistently store the RDF triples related to devel- oper’s profiles and PaaS providers’ capabilities. Additional requirements are also imposed by the Security and SLA modules. Moreover, it provides a Harmonized API that enables the seamless interconnection and management of applications across different Cloud PaaS offerings.
The Cloud4SOA Harmonized API capitalizes on the Cloud4SOA Semantic Model and acts as an intermediary between the Cloud4SOA system and the PaaS offerings, where the Cloud-based applications are actually executed. Therefore, heterogeneity of the numerous PaaS providers, each of them introducing their own APIs, can be han- dled by this unified API. The API contains a number of operations that support the management of the Cloud-based applications independent of the specific API of the underlying PaaS offering. Given that each PaaS offering uses its own API, an adapter is needed as a middleware between the Cloud4SOA API and the native API of the PaaS offering. More specifically, the adapter translates the functions of the Cloud4SOA API to the PaaS offering’s native API, and vice versa.