Main

Evaluation Environment Components 2.1

2017-05-25T13:52:08Z

Overview

The BPaaS Evaluation Environment is a companion to the CloudSocket broker which assists him/her towards optimising the BPaaS services offered. This assistance comes in various forms that map to different types of analysis. These types include: (a) KPI evaluation for assessing the performance of the BPaaS; (b) KPI drill-down to find the root causes of a particular KPI violation; (c) best BPaaS deployment discovery to infer the best deployments for a certain BPaaS; (d) process model recreation via process mining. On top of this functionality there exists a Hybrid Business Dashboard which enables the broker to appropriately invoke the analysis functionality as well as to visualise the analysis results by employing the best possible visualisation metaphors. This dashboard is shared between the BPaaS Desing and Evaluation Environments highlighting the close relationship between these environments where the results of one environment (i.e., evaluation) can enable to optimise the main artefacts of the other (i.e., design). This also enables the fast switch from one to the other environment when the need for optimisation is spotted and has to be applied at once. However, we should also highlight that the results of one analysis kind, i.e., the best BPaaS deployment discovery, can be exploited also by the BPaaS Allocation Environment towards the quest to find the most optimal deployment for a certain BPaaS.

Each analysis functionality is offered by a composite component in the form of an engine. In this respect, KPI evaluation and drill-down are offered by the Conceptual Analytics Engine, best BPaaS deployment discovery is offered by the Deployment Discovery Engine, while the capability to execute process mining algorithms is offered by the Process Mining Engine. To support the proper operation of all these engines with respect to the analysis tasks that have to be performed, another engine called Harvesting Engine was developed with the main goal to harvest information from different information sources (i.e., components) in the CloudSocket architecture, to semantically uplift it with the assistance of two ontology (Evaluation and KPI OWL-Q Extension) and to finally store it in the Semantic Knowledge Base. The latter has been realised in the form of an API which has been built on top of an existing triple store.

The BPaaS Evaluation Environment, similarly to the BPaaS Design one, supports multi-tenancy out of the box. This has been mainly realised thanks to the Harvesting Engine which is able to store the information harvested and semantically uplifted in broker-specific fragments (i.e., RDF graphs) inside the Semantic Knowledge Base. This enables the system to service a broker by considering only the fragment that belongs to him/her, thus also allowing all analysis functionalities to focus only on a specific portion of the whole Semantic Knowledge Base content.

As indicated in the analysis of each individual main component of the BPaaS Evaluation Environment, in many cases most of the components can be interchanged with external ones developed by organisations out of the CloudSocket consortium. This is due to the loose coupling between the components, the development of an abstraction API as well as the interchange of standard, as much as possible, formats. Two main exceptions apply to this rule: (a) the Hybrid Business Dashboard component is shared between the two environments which means that if it has to be interchanged, this should also be allowed by the BPaaS Design Environment; (b) the Harvesting Engine does not offer a certain REST API but is executed periodically in the form of a thread. This engine requires high expertise and knowledge of semantic technologies in order to be reproduced as well as a good knowledge of many APIs that are offered by the CloudSocket platform. It also needs to know what is the information offered by such APIs and how it can be correlated in such a way that appropriate semantic relationships between the different resources created can be expressed by considering the current schema of the Evaluation and KPI (OWL-Q Extension) ontologies. In this respect, we consider the development of such a component a difficult but not impossible job to be performed.

An overview of the architecture of the BPaaS Evaluation Environment is depicted in the figure below. As it can be easily seen, this architecture comprises three main levels: (a) UI; (b) business logic; (c) data. At the UI level resides the Hybrid Business Dashboard responsible for invoking the different analysis components offered. The business logic level comprises all the analysis engines (Conceptual Analytics Engine], [[Deployment Discovery Engine, and Process Mining Engine) as well as the Harvesting Engine. On top of the analysis engines resides the Hybrid Business Management Tool which takes care of the orchestration of the analysis functionality and is the bridge between the UI and the business logic level. Finally, at the data level, the Semantic Knowledge Base exists which enables the querying and the management of the semantic information stored in it.

Architecture of the BPaaS Evaluation Environment.

More information about this architecture, how the components interact with each other at the same or across different adjacent levels and what are the interactions scenarios covered can be found at the following URL: where corresponding UML diagrams can be viewed. This information was also covered in the D4.5 deliverable.

Below, we provide the links of all the components of the BPaaS Evaluation Environment which provide a more thorough analysis for them catering for different types of audience, including developers and operation managers. An overview of these components is also provided in the D4.6 deliverable.

Component Documentations

Semantic Knowledge Base

Harvesting Engine

Conceptual Analytics Engine

Process Mining Engine

Deployment Discovery Engine

Conceptual Analytics Engine 7.6

2017-05-25T13:13:59Z

1 Summary
2 Component responsible
3 Architecture Design
4 Installation Manual
- 4.1 Development
- 4.2 Production
5 Test Cases
6 User Manual
- 6.1 API Specification
- 6.2 Handbook

Summary

The Conceptual Analytics Engine is a composite component in the BPaaS Evaluation Environment which is responsible for performing two types of KPI analysis over the Semantic Knowledge Base (Semantic KB) at the Data Layer of this environment's architecture. This component is invoked by the Hybrid Dashboard to execute the required type of analysis and visualise the respective analysis results according to the best possible visualisation metaphor. The two types of KPI analysis include:

KPI metric measurement: Derives the current and historical measurements for a KPI metric enabling their evaluation against the corresponding KPI threshold by the Hybrid Business Dashboard. This type of analysis is offered in two forms: (a) on-the-fly derivation of the KPI measurements based on measurement information of raw metrics derived from the BPaaS Execution Environment; (b) querying over a historical fragment of the Semantic KB to obtain the measurement history of the KPI. The first form is actually a facilitator of the second as it enables the broker to store the derived information in the historical fragment. The first form is also offered in terms of two variants: (a) KPI measurement: the measurement of the metric of an existing KPI is supported; (b) Metric measurement: measurement for metric specifications which do not necessarily map to KPIs. The second variant is ideal for exploring the possible metric space in order to enable the broker to come up with new KPIs for his/her BPaaSes. This has been deemed a necessity for KPI analysis environments as the determination of KPIs is not an easy task to perform which also requires some form of creativity that has to be supported by such an environment.
KPI drill-down: Drills-down the measurement of a metric of a KPI to the whole KPI hierarchy. Via the checking of the corresponding thresholds of the KPIs involved in the hierarchy, this enables to perform root-cause analysis (for the KPI violation that has occurred at the top-level of the hierarchy).

The Conceptual Analytics Engine does support multi-tenancy. This means that it can support multiple brokers instead of one in a concurrent manner. This feature is enabled via the Harvester component which partitions accordingly the information space in the Semantic KB in broker-specific fragments. Each broker-specific fragment is further separated into normal and historical sub-fragments. In this way, an analysis functionality for a certain broker can be operated over the suitable broker-specific fragment such that, in the end, multiple tenants/brokers can be supported.

Apart from API methods that directly map to the core KPI analysis functionality offered, also auxiliary/utility methods are also offered to better facilitate the analysis and visualisation tasks of the Hybrid Business Dashboard. In overall, the following functionality is offered by the Conceptual Analytics Engine component:

KPI Measurement: the capability to measure the performance of a BPaaS is offered either for the current moment or across a certain time period. The measurement can be across all customers of the broker that have purchased the corresponding BPaaS or for a certain customer. The measurement can be performed either via the KPI name, for fixed KPIs originally defined for the BPaaS at hand, or via the specification of a KPI metric (for a more creative exploration of the possible metric space).
KPI Drill-Down: this offered capability enables to perform root-cause analysis for the violation of a top KPI. As soon as a top KPI is violated, the Hybrid Business Dashboard can call this functionality in order to check the status of the KPIs within the hierarchy of the top-level KPI violated. What happens in the background is that both the top-level KPI and its descendants are evaluated via the first type of functionality analysed in the previous bullet. The measurement results are then compared with the KPI thresholds to derive the chain of KPI violations that led to the top-level KPI violation.
Retrieval of Raw Metric Information: this capability enables to obtain the information of which raw metrics can be exploited by the broker in its effort to produce a new KPI metric. Such raw metrics map to measurements that have been already collected from the BPaaS Execution Environment by the Harvester. These metrics are actually exploited in the production of the KPI metric hierarchy mapping to a new KPI metric that has to be evaluated by the broker via the invocation of the functionality in the 1st bullet. Thus, they participate in the formulas of the metrics involved in this KPI metric hierarchy.
Tenant Information Retrieval: this capability enables the broker to obtain the list of tenants for which KPI measurements have been produced for a certain BPaaS. Such information can then be exploited, e.g., in order to perform KPI measurement and drill-down in a customer-specific manner.
KPI Retrieval: could be argued that this capability is not needed to be offered as the Hybrid Business Dashboard already has the knowledge about which KPIs have been defined for a BPaaS inside the BPaaS Design Package. However, by considering the fact that some KPIs are defined later on by the BPaaS Evaluation Environment, this utility capability, in the end, enables to present to the broker all KPIs that have been defined for a BPaaS and have been incorporated in the corresponding BPaaS bundle definition.

Only the CloudSocket broker has been enabled to exploit such the Conceptual Analytics Engine with the rationale that the BPaaS Evaluation Environment is a facility offered only for this entity that enables it to assist it in the proper management of its BPaaSes. Of course, any CloudSocket enhanced implementation might also take the view of providing an analysis functionality also for the customer. In any case, we consider that only one role from the CloudSocket broker can be involved in the exploitation of the BPaaS Evaluation Environment which is the evaluation expert. This is due to the fact that both the Hybrid Business Dashboard as well as the requirements imposed by its underlying analysis functionality do not force the use of a more technical role. In the context of KPI analysis, this is in contrast to other frameworks which tightly couple the definition of KPIs with the underlying measurement/storage technology (e.g., database queries used for KPI evaluation). On the contrary, the Conceptual Analytics Engine does not impose such a requirement as it demands the use of the OWL-Q language, which is a high-level, implementation-independent language for the definition of KPIs. In this way, the evaluation expert needs just to learn this language in order to define new KPIs which comprise metrics that are specified in a quite user-intuitive and familiar way for the expert. In case that new KPIs are not needed to be specified, then the evaluation expert does not need to possess any special knowledge in order to exploit the analysis functionality offered which greatly eases his/her job.

This component could be easily replaced by another component developed by an organisation outside the CloudSocket consortium. Its integration will be easy as it is loosely coupled with just one from the rest of the BPaaS Evaluation Environment components, the Semantic KB and especially its Semantic KB Service which hides and abstracts away from any implementation details involved in the Semantic KB.

The following table indicates the details of the component.

Type of ownership	Creation
Original tool	New component developed in the context of this project
Planned OS license	Mozilla Public Licence 2.0.
Reference community	ADOxx Community.

Consist of

Conceptual Analytics Service (REST API exposing all core functionalities)

Depends on

Semantic KB

Component responsible

Developer	Email	Company
Kyriakos Kritikos	kritikos@ics.forth.gr	FORTH

Architecture Design

The Conceptual Analytics Engine is a composite component offering KPI analysis capabilities, which is coloured in red in the overall BPaaS Evaluation Environment architecture depicted in the figure below. As it can be seen, it is invoked by the Business Management Tool in order to execute the respective BPaaS analysis functionality. This invocation, in turn, leads to exploiting the content of the Semantic KB at the Data Layer in order to support the analysis functionality needed.

The final, internal architecture of the Conceptual Analytics Engine, which is depicted below, comprises the following 6 main components:

Conceptual Analytics Service: A REST service which encapsulates the whole functionality of the Conceptual Analytics Engine in the form of REST API methods. Depending on the respective API method invoked, different underlying components are executed by this service.
Query Creator: this component is responsible for creating SPARQL queries which are then evaluated by the Conceptual Analytics Service over the Semantic KB. Such queries map to the core functionality of the Conceptual Analytics Engine, thus enabling to obtain measurements related to KPI assessment and drill-down. They also map to auxiliary/utility functionality which is also offered in the form of specific API methods of the Conceptual Analytics Service.
Drill-Down Handler: this component is responsible for performing the drill-down of KPIs. As a KPI forms a hierarchy with its underlying KPI descendants, the facilities of the Query Creator are exploited in order to construct the KPI measurement queries for all the KPIs involved in the KPI hierarchy.
KPI Handler: this component is responsible for obtaining the definition of KPIs and their corresponding metrics from the Semantic KB and offers the functionality of retrieving such information both to the Conceptual Analytics Service and the two main components underlying it. This means that there exist API methods which can be exploited in order to obtain the KPI information involved in the definition of a certain BPaaS.
SPARQL Transformer: it is responsible for transforming the definition of a KPI metric into an SPARQL query which can be exploited in order to derive the measurements of that metric in a certain time period. It is solely exploited by the Query Creator component.
Resource Accessor: it has the duty to retrieve information from external information sources, i.e., REST APIs or databases. It is called by the Query Creator in order to produce the appropriate input information (mapping to such external information source accessing) in metric formulas which is to be implanted in the query that has to be generated for a specific metric. This is due to the fact that metric formulas comprise input parameters, which can be metrics, constants or information generated from calling such external information sources.

Architecture of the Conceptual Analytics Engine.

Installation Manual

The component has been implemented purely in java. It depends on other external components / frameworks like Spring, swagger, jersey and sesame/rdf4j. It also depends on an internal component developed in the context of this project, the owl-q one which enables the parsing of OWL-Q models into domain-specific objects as well as their writing. The following figure explicates the sole artefact generated mapping to this component as well as its dependencies on other artefacts (at a coarse-grained level to simplify the figure).

Artifact dependencies for the Conceptual Analytics Engine.

Maven has been exploited as the main build automation tool, prescribing how the component/artefact can be built and its main dependencies. Such a tool facilitates the building and automatic generation of this artefact for the different CloudSocket environments (development and production) and their configuration. A complete description of how such artefact building and generation can be performed for the different environments is given in the installation manual below.

Development

Currently, the following requirements hold for this component:

Oracle's 1.7.x JDK or higher
Apache tomcat 1.7 or higher
Maven tool for code compilation and packaging

The installation procedure to be followed is the one given below:

Download source code from https://omi-gitlab.e-technik.uni-ulm.de/cloudsocket/evaluation_skb/repository/archive.tar?ref=master
Unzip code with tar (or any other tool)
Go to the root directory of the installed code
Change the configuration file to provide the right access information for the Virtuoso Triple Store (https://virtuoso.openlinksw.com/)
Run:
```
 mvn clean install 
```
and then:
```
 mvn war:war 
```
Move the war file to the webapps directory of tomcat and start tomcat, if not yet started
Test installation by entering in your browser the following URL: http://localhost:8080/evaluation/

Production

The same instructions as above hold for this component

Test Cases

You can run test cases directly from the URL (http://localhost:8080/evaluation in your development environment) of the REST service due to the use of swagger (http://swagger.io) which enables the execution of the API method exposed by exploiting user input provided in a form-based manner. The following test cases are envisioned:

Run a KPI evaluation query

Suppose that the user desires to obtain the most recent value for a KPI named as "MeanAvailabilityKPI". Then, he/she can browse the methods of the API and click on the one named as "evaluateKPI". The following screenshot indicates the upper part of the description of the method when selected: Next, he/she can fill in the kpiName field with the value of "MeanAvailabilityKPI", the field of "brokerId" with the value of "bwcon" and the field of "bundleId" with the value of "SendInvoiceSaaSEurope". Then he/she can press the "Try it out!" button.

Finally, he/she will be able to see the respective curl command issued, the request URL, the corresponding results, as well as the response status and headers as indicated in the following figure:

User Manual

API Specification

The reader should refer to the swagger-based API web page (http://localhost:8080/evaluation for a local installation or http://134.60.64.222:8080/evaluation for a remote existing installation) for browsing an on-line documentation with the capability to execute the API methods. In the following, the API methods of the Conceptual Analytics Service are analysed below:

evaluateKPI

This method enables to produce current and historical measurements for a certain KPI in the context of a specific BPaaS. As multi-tenancy is supported, the id of the broker needs to be specified in order to set the appropriate context for the method execution.

 POST ca/evaluateKPI/{brokerId}

The expected input format is multipart/form-data. The following input parameters are expected:

brokerId: denotes the id of the broker for which the evaluation needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
bundleId: denotes the id of the BPaaS bundle for which the evaluation needs to be performed (optional)
kpiName: denotes the name of the KPI to be evaluated (obligatory)
kpiPeriod: denotes the (history) period of the evaluation. If this parameter is specified, then a set of KPI evaluation values and not just one can be returned matching the respective period provided. The value should conform to String-based Java periods (e.g., "P1M" which declares a period of 1 month until now) (optional)
tenant: denotes the id of the tenant for which the KPI can be evaluated. In this way, the KPI is assessed only for this tenant and not across all tenants that have purchased the respective BPaaS (optional)
maxRows: denotes the maximum number of KPI values to return. Default value is 0 indicating that all possible values can be returned (optional)

The following response codes can be returned depending on whether the API method execution was successful or not:

200 -- The method execution was successful
400 -- Wrong parameter values have been provided
404 -- The resource requested (i.e., the broker) was not found
406 -- The format requested for the method output is not supported

The output can be in both json and xml formats. A sample for a json output is given below:

 { "results": [ { "bundleId": "SendInvoiceSaaSEurope", "value": "0.8010364041400798e0", "instant": "2016-01-27T11:43:38.588Z" } ] }

evaluateMetric

This method enables the production of current and historic measurements for a KPI metric. It is similar to the "evaluateKPI" method but requires from the broker to appropriately specify the KPI metric in two different ways: (a) the metric and its context are passed as input parameters; (b) the name of an existing metric is provided:

 POST ca/evaluateMetric/{brokerId}

The expected input format is multipart/form-data. The following input parameters are expected:

brokerId: denotes the id of the broker for which the evaluation needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
metricName: denotes the name of the existing metric for which the evaluation needs to be performed. This parameter is optional as there is an alternative way of determining the KPI metric to be evaluated (optional)
metric: provides a CompositeMetric specification in OWL-Q for the metric to be evaluated. As a composite metric is associated to a specific metric context, the "metricContext" parameter does not need to be provided in this case (optional)
metricContext: provides the MetricContext specification in OWL-Q for the metric to be evaluated. This metric context includes scheduling and window information for the metric at hand. This parameter is optional and might be provided in case that we need to modify the context of an existing metric (whose name is specified in the "metricName" parameter) temporarily for the context of this evaluation (optional)
bundleId: denotes the id of the BPaaS bundle for which the evaluation needs to be performed (optional)
kpiPeriod: denotes the (history) period of the evaluation. If this parameter is specified, then a set of metric measurement values and not just one can be returned matching the respective period provided. The value should conform to String-based Java periods (e.g., "P1M" which declares a period of 1 month until now) (optional)
tenant: denotes the id of the tenant for which the identified metric can be evaluated. In this way, the metric measurements are only produced for this tenant and not across all tenants that have purchased the respective BPaaS (optional)
maxRows: denotes the maximum number of metric measurements values to return. Default value is 0 indicating that all possible values can be returned (optional)

The following response codes can be returned depending on whether the API method execution was successful or not:

200 -- The method execution was successful
400 -- Wrong parameter values have been provided
404 -- The resource requested (i.e., the broker) was not found
406 -- The format requested for the method output is not supported

The output can be in both json and xml formats. A sample for a json output is given below:

 { "results": [ { "bundleId": "SendInvoiceSaaSEurope", "value": "0.8010364041400798e0", "instant": "2016-01-27T11:43:38.588Z" } ] }

kpiDrillDown

This method enables to perform a drill-down over a certain KPI for a specific BPaaS (again under the context of a specific broker). The drill-down results can be provided in a tree-based form in both JSON & XML formats, where each result contains information which is equivalent to that of the aforementioned methods:

 POST ca/kpiDrillDown/{brokerId}

The expected input format is multipart/form-data. The following input parameters are expected:

brokerId: denotes the id of the broker for which the KPI drill-down needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
bundleId: denotes the id of the BPaaS bundle for which the KPI drill-down needs to be performed (optional)
kpiName: denotes the name of the KPI for which the KPI drill-down needs to be performed (obligatory)
kpiPeriod: denotes the (history) period of the drill-down. If this parameter is specified, then a set of drill-down values and not just one can be returned matching the respective period provided. The value should conform to String-based Java periods (e.g., "P1M" which declares a period of 1 month until now) (optional)
tenant: denotes the id of the tenant for which the identified KPI needs to be drilled down. In this way, the respective KPI measurements and their drill-down are only produced for this tenant and not across all tenants that have purchased the respective BPaaS (optional)
maxRows: denotes the maximum number of drill-down values to return. Default value is 0 indicating that all possible values can be returned (optional)

The following response codes can be returned depending on whether the API method execution was successful or not:

200 -- The method execution was successful
400 -- Wrong parameter values have been provided
404 -- The resource requested (i.e., the broker) was not found
406 -- The format requested for the method output is not supported

The output can be in both json and xml formats. A sample for a json output is given below:

 { "results": [ { "bundleId": "SendInvoiceSaaSEurope", "kpi": "MeanKPIAvailability", "value": "0.8010364041400798e0", "instant": "2016-01-27T11:43:38.588Z", "subRows": [ { "bundleId": "SendInvoiceSaaSEurope", "kpi": "MeanIaaSKPIAvailability", "value": "0.8526374638629035e0", "instant": "2016-01-27T11:43:37.466Z", "subRows": [] } ] } ] }

kpiHistory

This method enables to query the historical measurements for a certain KPI in the context of a specific BPaaS. As multi-tenancy is supported, the id of the broker needs to be specified in order to set the appropriate context for the method execution. The results are equivalent to those returned by the "evaluateKPI" method. Please note that the content of the history fragment of the broker concerned needs to be populated via the "evaluateKPI" method in order to be able to obtain any result.

 POST ca/kpiHistory/{brokerId}

The expected input format is multipart/form-data. The following input parameters are expected:

brokerId: denotes the id of the broker for which the historical query over the broker-specific historical fragment needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
bundleId: denotes the id of the BPaaS bundle for which the historical query needs to be performed (optional)
kpiName: denotes the name of the KPI for which historical measurements need to be obtained (obligatory)
kpiPeriod: denotes the (history) period. If this parameter is specified, then a set of KPI historical measurement values and not just one can be returned matching the respective period provided. The value should conform to String-based Java periods (e.g., "P1M" which declares a period of 1 month until now) (optional)
tenant: denotes the id of the tenant for which the KPI history query can be evaluated. In this way, the required historical KPI values to be retrieved map only to this tenant and do not cross all tenants that have purchased the respective BPaaS (optional)
maxRows: denotes the maximum number of KPI historical measurement values to return. Default value is 0 indicating that all possible values can be returned (optional)

The following response codes can be returned depending on whether the API method execution was successful or not:

200 -- The method execution was successful
400 -- Wrong parameter values have been provided
404 -- The resource requested (i.e., the broker) was not found
406 -- The format requested for the method output is not supported

The output can be in both json and xml formats. A sample for a json output is given below:

 { "results": [ { "bundleId": "SendInvoiceSaaSEurope", "value": "0.8010364041400798e0", "instant": "2016-01-27T11:43:38.588Z" } ] }

kpiQuery

This method enables to retrieve the list of KPIs that have been defined in the context of a specific broker. When the id of the BPaaS is also provided, then the KPI list is filtered to include only those KPIs that have been specified for the BPaaS.

 POST ca/kpiQuery/{brokerId}

The expected input format is multipart/form-data. The following input parameters are expected:

brokerId: denotes the id of the broker for which the KPI query needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
bundleId: denotes the id of the BPaaS bundle for which the defined KPIs need to be retrieved - as stated, if not given, then this maps to obtaining all the KPIs that have been defined for all BPaaSes of a certain broker (optional)

The following response codes can be returned depending on whether the API method execution was successful or not:

200 -- The method execution was successful
400 -- Wrong parameter values have been provided
404 -- The resource requested (i.e., the broker) was not found
406 -- The format requested for the method output is not supported

The output can be in both json and xml formats. A sample for a json output is given below:

 [ { "name": "MeanIaaSAvailabilityKPI", "description": null, "abbreviation": null, "synonym": null, "constraintContext": null, "obliged": null, "firstArgument": { "name": "MeanIaaSAvailability", "description": null, "abbreviation": null, "synonym": null, "scale": null, "monotonicity": "POSITIVE", "unit": null, "valueType": null, "aggregationType": null, "measuredObject": "http://www.cloudsocket.eu/evaluation#IaaS1", "attribute": null, "level": 2, "metricContext": { "name": "MC1", "description": null, "abbreviation": null, "synonym": null, "window": null, "schedule": { "name": "OneDaySchedule", "description": null, "abbreviation": null, "synonym": null, "interval": 1, "repetition": 0, "scheduleType": "FIXED_RATE", "timeUnit": { "name": "Day", "description": null, "abbreviation": null, "synonym": null, "scale": null, "monotonicity": null, "quantity": null, "quantityKind": null, "unitType": "SINGLE", "unitMappings": null, "uri": "http://www.cloudsocket.eu/evaluation#Day" }, "uri": "http://www.cloudsocket.eu/evaluation#OneDaySchedule" }, "uri": "http://www.cloudsocket.eu/evaluation#MC1" }, "formula": { "name": "mean_iaas_availability", "description": null, "abbreviation": null, "synonym": null, "function": "MEAN", "functionURI": null, "argumentList": [ { "RawMetric": { "name": "IaaSAvailability", "description": null, "abbreviation": null, "synonym": null, "scale": null, "monotonicity": "POSITIVE", "unit": null, "valueType": null, "aggregationType": null, "measuredObject": "http://www.cloudsocket.eu/evaluation#IaaS1", "attribute": null, "level": 1, "metricContext": null, "sensor": null, "measurementDirective": null, "manual": true, "uri": "http://www.cloudsocket.eu/metrics/IaaSAvailability" } } ], "uri": "http://www.cloudsocket.eu/formulas/mean_iaas_availability" }, "metricList": [ { "RawMetric": { "name": "IaaSAvailability", "description": null, "abbreviation": null, "synonym": null, "scale": null, "monotonicity": "POSITIVE", "unit": null, "valueType": null, "aggregationType": null, "measuredObject": "http://www.cloudsocket.eu/evaluation#IaaS1", "attribute": null, "level": 1, "metricContext": null, "sensor": null, "measurementDirective": null, "manual": true, "uri": "http://www.cloudsocket.eu/metrics/IaaSAvailability" } } ], "uri": "http://www.cloudsocket.eu/metrics/MeanIaaSAvailability" }, "comparisonOperator": "GREATER_EQUAL_THAN", "optimisationOperator": null, "secondArgument": 0.9, "warningThreshold": 0.8, "validity": null, "childKPIs": null, "bundleURI": "http://www.cloudsocket.eu/evaluation/bwcon#SendInvoice", "qualifyingCondition": false, "uri": "http://www.cloudsocket.eu/kpis/MeanIaaSAvailabilityKPI" } ]

kpiTenantQuery

This method enables to retrieve the list of tenants/customers for which there exist measurements for a certain KPI for the BPaaSes that they have purchased in the context of a specific broker. When the id of the BPaaS is also provided, then the tenant list is filtered to include only those tenants which have purchased the respective BPaaS.

 POST ca/kpiTenantQuery/{brokerId}

The expected input format is multipart/form-data. The following input parameters are expected:

brokerId: denotes the id of the broker for which the KPI tenant query needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
bundleId: denotes the id of the BPaaS bundle that must have been purchased by the tenants to be returned (optional)
kpiName: denotes the name of the KPI for which measurements should have been produced for the tenants to be returned (obligatory)
kpiPeriod: denotes the historical period for which KPI measurements should have been produced. The value should conform to String-based Java periods (e.g., "P1M" which declares a period of 1 month until now) (optional)

The following response codes can be returned depending on whether the API method execution was successful or not:

200 -- The method execution was successful
400 -- Wrong parameter values have been provided
404 -- The resource requested (i.e., the broker) was not found
406 -- The format requested for the method output is not supported
500 -- Internal server error exception

The output can be in both json and xml formats. A sample for a json output is given below:

 [ { 3c1ab6ac-6a7e-4791-8c16-f8f6d400231c } ]

ldQuery

This method enables to pose an arbitrary query over the broker-specific fragment of the Semantic KB. Such a query should only be posed by an expert on semantic technologies which should have an appropriate knowledge of SPARQL as well as of the Evaluation and OWL-Q (KPI Extension) ontologies that have been developed in the context of WP3 in CloudSocket.

 POST ca/ldQuery/{brokerId}

The expected input format is multipart/form-data. The following input parameters are expected:

brokerId: denotes the id of the broker for which the KPI tenant query needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
query: signifies the SPARQL query to be posed over the Semantic KB (obligatory)
timeout: specifies the maximum amount time for waiting (in milliseconds) until a response can be obtained from the Semantic KB. A value of 0, which is the default, denotes that the broker can wait indefinitely (optional)
maxRows: denotes the maximum number of rows to be produced by the query. A value of 0, which is the default, denotes that all rows should be returned. As SPARQL has the LIMIT construct, the broker should be careful of not specifying SPARQL queries including this construct that are evaluated via this method for which has a positive value for this parameter has been provided. In this latter case, the outcome would depend on the correlation between the values for the LIMIT construct and this parameter, i.e., if LIMIT is X and parameter value is Y, >= X, then X values will be returned. If Y < X, then Y values will be returned. In other words, the lowest from the values provided will prevail (optional)

The following response codes can be returned depending on whether the API method execution was successful or not:

200 -- The method execution was successful
400 -- Wrong parameter values have been provided
404 -- The resource requested (i.e., the broker) was not found
406 -- The format requested for the method output is not supported

The output can be in "application/sparql-results+xml", "application/sparql-results+json", "text/csv" and "text/tab-separated-values". A sample for the "application/sparql-results+json" output is given below:

 { "head": { "link": [], "vars": ["bpaas", "id"] }, "results": { "distinct": false, "ordered": true, "bindings": [ { "bpaas": { "type": "uri", "value": "http://www.cloudsocket.eu/evaluation#BPaaS_bwcon_SendInvoiceSaaSEurope" } , "id": { "type": "typed-literal", "datatype": "http://www.w3.org/2001/XMLSchema#string", "value": "SendInvoiceSaaSEurope" }}, { "bpaas": { "type": "uri", "value": "http://www.cloudsocket.eu/evaluation#BPaaS_bwcon_SendInvoiceSaaSWorldwide" } , "id": { "type": "typed-literal", "datatype": "http://www.w3.org/2001/XMLSchema#string", "value": "SendInvoiceSaaSWorldwide" }}, { "bpaas": { "type": "uri", "value": "http://www.cloudsocket.eu/evaluation#BPaaS_bwcon_SendInvoiceIaaSEurope" } , "id": { "type": "typed-literal", "datatype": "http://www.w3.org/2001/XMLSchema#string", "value": "SendInvoiceIaaSEurope" }} ] } }

rawMetricQuery

This method enables to obtain all the raw metrics that have been defined in OWL-Q for a certain broker. In case that a respective BPaaS is also determined, then the raw metric list is filtered to contain only those raw metrics that have been defined for this BPaaS. As has been already stated, this method is a utility one which enables the broker to construct KPI metric specifications out of those returned by this method in order to subsequently make evaluation queries for those KPI metrics via the "evaluateMetric" method and thus better explore the possible KPI metric space.

 POST ca/rawMetricQuery/{brokerId}

The expected input format is multipart/form-data. The following input parameters are expected:

brokerId: denotes the id of the broker for which the raw metric query needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
bundleId: denotes the id of the BPaaS bundle in order to restrain the raw metric list to be obtained to contain only those metrics that have been defined for this bundle (optional)

The following response codes can be returned depending on whether the API method execution was successful or not:

200 -- The method execution was successful
400 -- Wrong parameter values have been provided
404 -- The resource requested (i.e., the broker) was not found

The output can be in XML or JSON form. A sample of an output in JSON form is given below:

 [ { "name": "CycleTime", "description": null, "abbreviation": null, "synonym": null, "scale": null, "monotonicity": "NEGATIVE", "unit": null, "valueType": null, "aggregationType": null, "measuredObject": "http://www.cloudsocket.eu/evaluation#Workflow_SendInvoice", "attribute": null, "level": 1, "metricContext": null, "sensor": null, "measurementDirective": null, "manual": true, "uri": "http://www.cloudsocket.eu/metrics/CycleTime" }, { "name": "EmailNotSent", "description": null, "abbreviation": null, "synonym": null, "scale": null, "monotonicity": "NEGATIVE", "unit": null, "valueType": null, "aggregationType": null, "measuredObject": "http://www.cloudsocket.eu/evaluation#Workflow_SendInvoice", "attribute": null, "level": 1, "metricContext": null, "sensor": null, "measurementDirective": null, "manual": true, "uri": "http://www.cloudsocket.eu/metrics/EmailNotSent" }, { "name": "EmailSent", "description": null, "abbreviation": null, "synonym": null, "scale": null, "monotonicity": "POSITIVE", "unit": null, "valueType": null, "aggregationType": null, "measuredObject": "http://www.cloudsocket.eu/evaluation#Workflow_SendInvoice", "attribute": null, "level": 1, "metricContext": null, "sensor": null, "measurementDirective": null, "manual": true, "uri": "http://www.cloudsocket.eu/metrics/EmailSent" }, { "name": "SaaSAvailability", "description": null, "abbreviation": null, "synonym": null, "scale": null, "monotonicity": "POSITIVE", "unit": null, "valueType": null, "aggregationType": null, "measuredObject": "http://www.cloudsocket.eu/evaluation#ExternalSaaS1", "attribute": null, "level": 1, "metricContext": null, "sensor": null, "measurementDirective": null, "manual": true, "uri": "http://www.cloudsocket.eu/metrics/SaaSAvailability" }, { "name": "CustomerSatisfaction", "description": null, "abbreviation": null, "synonym": null, "scale": null, "monotonicity": "POSITIVE", "unit": null, "valueType": null, "aggregationType": null, "measuredObject": "http://www.cloudsocket.eu/evaluation#Workflow_SendInvoice", "attribute": null, "level": 1, "metricContext": null, "sensor": null, "measurementDirective": null, "manual": true, "uri": "http://www.cloudsocket.eu/metrics/CustomerSatisfaction" }, { "name": "IaaSAvailability", "description": null, "abbreviation": null, "synonym": null, "scale": null, "monotonicity": "POSITIVE", "unit": null, "valueType": null, "aggregationType": null, "measuredObject": "http://www.cloudsocket.eu/evaluation#IaaS1", "attribute": null, "level": 1, "metricContext": null, "sensor": null, "measurementDirective": null, "manual": true, "uri": "http://www.cloudsocket.eu/metrics/IaaSAvailability" } ]

Handbook

Monitoring Engine (InfluxDB Prototype) 1.0

2017-05-22T08:16:44Z

TODO: add brief description according the D3.6

Workflow Engine Component 2.9

2017-04-20T13:43:38Z

1 Summary
2 Component responsible
3 Architecture design
4 Installation manual
- 4.1 Development
- 4.2 Production
5 Test Cases
6 User Manual
- 6.1 API specification
- 6.2 HandBook

Summary

It is responsible for managing the deployment, execution and management of the different workflow instances. It will be multi-tenant leading to executing a workflow instance on behalf of one organisation by also taking care of the corresponding workflow and organisation data level. This component will expose:

A graphical user interface for interacting with the different actors involved in the lifecycle of a workflow
A REST API interface allowing programmatic access to the different types of functionalities offered.

The main functionalities are:

Deploy/redeploy a workflow in the workflow-engine, instantiate it and execute it.
Manage and follow the workflow instances, according to the workflow description in BPMN.
Interact with manual tasks of the workflow.
Manage the workflow engine environment.

Moreover, the executable workflows are designed by the integrated Editor Workflow based on the abstract workflows. Their design has to be aligned with the workflow engine, since the standard BPMN2.0 doesn’t reach the complete execution definition and it is allowed to extend it in order to cover the whole execution through this workflow definition. As the deployment will be executed on the cloud, it is mandatory to define dynamically the self-contained executable workflows, which are included in the BPaaS bundle, following these standards.

The main roles to interact with the functionalities are:

CloudSocket Customer, who wants to use the purchased BPaaS bundles, which has been deployed automatically in the cloud. The customer can interact via the use of different roles: i) Knowledge Worker is responsible for managing the manual task of the workflows; ii) Process Responsible (technical skills) is in charge of dealing with the workflow engine, managing the workflow instances and following their status.
Broker, who is responsible for the configuration of the Workflow Engine, for performing tasks on behalf of customers (e.g., workflow instances actions), for inspecting/monitoring the status of all workflows deployed and especially the status of respective SLAs.
Platform operator, who may be the broker itself, and is responsible for checking if the Workflow Engine works as expected.

Additionally, there is a role that covers the functionalities for creating the executable workflow, which will be included in the BPaaS bundle, during the design phase. Therefore, this role is not directly related with the execution phase, but the internal component is completely integrated with the whole component.

Workflow Designer, which is responsible to design the executable workflows using the executable workflow editor in order to include the necessary information to transform the abstract workflows (independent of the workflow engine) to the executable workflows (associated to a specific workflow engine).

All the actors will interact directly with the graphical user interface and the system will manage automatically the authorization of the appropriated functionalities (see the user guide in the Manual section).

The following table indicates the details of the component.

Type of ownership	Extension
Original tool	FIWARE and Fed4FIRE project
Planned OS license	Apache License Version 2.0.
Reference community	Activiti community

Consist of

Web UI of workflow Engine (Graphical User interface)
Workflow Engine (core functionalities)

Depends on

Process Data Mediator Engine
IdM Marketplace

Component responsible

Developer	Email	Company
Roman Sosa Gonzalez	roman.sosa@atos.net	Atos
Joaquin Iranzo	Joaquin.iranzo@atos.net	Atos

Architecture design

Figure: General architecture for Workflow Engine

The general architecture of this component can be viewed by checking the components coloured in yellow, in above figure:

The below figure introduces in more detail the different modules of the Workflow Engine. The components are split into two main parts: i) one part is responsible for exposing the interfaces with the externals actors (other components, BPaaS Customers or Brokers); ii) the other is responsible for managing the business logic and the data layer.

The two layers allow decoupling the components between the presentation layer, which is directly related to the exposed interfaces (Graphical user interfaces and REST API) and the backend, which is responsible to provide all the functionalities and their persistence. Thus, the interface layer will focus on the look and feel or how to expose these interfaces; moreover it will manage the necessary calls to the backend layer, which will execute the actions.

Figure - Internal architecture for the Workflow Engine.

Front End layer:

REST Workflow module is responsible for exposing all the functionalities of the Workflow Engine through a REST API, allowing other components to interact with the engine programmatically, without human interaction. The main interactions are with the Cloud provider Engine, which is responsible to orchestrate the deployment of the BPaaS bundle in the cloud environment, and the Adaptation Engine, which is responsible to modify the environments and the currently running workflow instance in order to cover the new conditions.
Editor Workflow module is responsible for the editing of the executable workflows at the design phase. A graphical user interface is used for editing, modifying and generating the executable workflows, while the involved actors are the technical designer, who can be contracted by the brokers to take care of the workflow design task. However, the module cannot interact directly with the customers and their companies; it is thus exploitable only by brokers. Nevertheless, this editor is necessary to align the definition of the concrete workflows with the technology adopted in the workflow engine in order to deploy and execute them correctly in the cloud environment.
Explorer Workflow module is responsible for exposing a graphical user interface in order to interact with the human actors, such as brokers and customers. Hence, through this exposed dashboard, the different actors can manage the complete lifecycle of the deployed workflows, allowing interacting with the platform in an easy way, increasing the quality of experience (QoE).

Back End Layer

Core Workflow Engine module is responsible for managing all the functionalities of the Workflow Engine. Hence, the complexity of the business logic of all these functionalities is delegated to this module and an interface is exposed to interact with them. It is also responsible to interact with the data layer and to persist the workflow, its instances and the rest of the entities.
Worflow Parser module is responsible for managing the functionalities related to workflow parsing, such as the introduction of the real endpoints of the software components and the automatic generation of the service task tags to invoke WS and RESTFul services.
Bind Proxy is a small module to facilitate the interaction with the database. It is responsible for managing the binding between service tasks and the associated services. It has been introduced to avoid using the Core Workflow Engine module as a proxy, to only connect with the database in order to manage the binding actions. In this manner, using this module, the Workflow Parser is decoupled from the Core Workflow Engine.

Data layer

Workflow Data Base module is responsible for persisting all the data in order to support all the functionalities. The model definition is based on an entity-relationship schema to represent all the entities, including tenants, roles, workflows, instances, jobs… It exposes a standard interface to connect with the data base; nevertheless it is not its responsibility to create an Object-relational mapping to interact with the entities such as JPA in java or SQLAlchemy in Python, since that is delegated to the Core_Workflow_Engine and the Bind_Proxy to provide it.

All the components expose different types of interfaces in order to cover nonfunctional requirements, such as scalability, modularity and replaceability. Nevertheless, some of them are more coupled than others, since they work to provide features together.

The REST Workflow, Explorer Workflow and Core Workflow Engine components are working jointly in order to arrange the workflow execution. Therefore, it is possible to replace these components with implementations such as Camunda or BonitaSoft; and re-implementing the adaptation and extension developed in these components based on Activiti.
The Editor Workflow is partially independent of the base line workflow engine as its main duty is to create the executable workflow to be deployed in the specific engine, which might include concrete extensions on the standard BPMN. In this sense, this component could also be extended in order to work for other workflow engines. In addition, it could also be replaced by another workflow editing component which could be coupled to a specific workflow engine like Activiti or the one which totally replaces the agglomeration of the previously referred components in the previous bullet.
The Parser Worflow Manager and Bind Proxy have isolated functionalities and expose a Restful interface. Hence, it is feasible to substitute them by other components, if they maintain the exposed APIs.
Finally, the Workflow Engine use a persistence framework with support for custom SQL, stored procedures and advanced mappings, this allow to substitute the Workflow Data Base module by other relational databases as long as the new option follows the standard connectors, since this persistence framework creates an abstract layer between the entities and their persistence in the data base.

Installation manual

The component is developed in java based on Activiti 5.18; several frameworks are used such as Vaadin, Spring and mybatis. A MySQL database is used.

As a build automation tool, the components have used Maven, which describes how they are built, and their dependencies. This allows building and generating automatically the artifacts for the different environments (development and production) and their configuration for example with Eclipse. Besides, the use of this artifact will facilitate the continuous integration, which will be covered in Task T4.5 CloudSocket Integration and Consolidation.

The installation manual takes advantage of these tools, facilitating the installation at the different environments and describing the necessary steps to install the component and its modules. The following figure indicates the generated artefacts and their dependencies.

Figure - Artefacts of the Workflow Engine

Development

Requirements

Oracle JDK 1.7.x
Tomcat 7.x
Maven tool for building applications.

Installation Download source code. The workflow engine comprises two projects:

Workflow Parser: https://omi-gitlab.e-technik.uni-ulm.de/cloudsocket/workflow-parser.
- Components:
  - parser-service is the war package that exposes the API web (WS/REST)
  - parser-manager is responsible for managing the deployment and execution adaptations in order to obtain the appropiated BPMN2.0 file
  - BPMN20Manager is responsible for generating the automatic code, which will be included in the BPMN 2.0 file, to call WS. It will be integrated into the parser-manager component.
  - bpmn-model is the bpmn model that allows to manage and modify the BPM2.0 files following the standar.
  - parser-client is the proxy to call the interfaces, exposed in the parser-service component. This can be used by other applications or components in order to call the workflow parser.
Workflow Engine: https://omi-gitlab.e-technik.uni-ulm.de/cloudsocket/workflow-engine
- Components Activiti v5.18 (customized/modified):
  - activiti-webapp-rest2 is the war package that exposes the API REST of Activiti. It has been customized to cover the deployment and execution adaptations actions.
  - activiti-webapp-explorer2 is the war package that exposes the GUI of Activiti. It has been customized to manage the different functionalitis such as integration Idm, multi-tenant approach, introduction of tokens and groups....
  - activiti-rest is the component that execute the actions of the activiti-webapp-rest2. It has been modied to cover the actions of the activiti-webapp-rest2 component.
  - activiti-explorer is the component that execute the actions of the activiti-webapp-explorer2. It has been modied to cover the actions of the activiti-webapp-explorer2.
  - activiti-engine is the core of the engine. It has been modified to cover our functionalities.
- Rest of components:
  - atos-compel is responsible for discovering and binding the services (atomic services, software components...) with the service tasks included in the business process. It wraps the BPMN web editor and store the binding into the data base.
  - atos-bind is responsible for storing the binding and the tokens in the data base. it can be used by other components to access and manage the data of the system.
  - atos-service-tasks manages the different kind of service tasks such as the RESTproxy (which invokes remote services), monitoring service tasks (which allow to send monitoring data)
  - atos-form manages the different kind of fields that can be included in the user tasks in the business process.
  - demo-app is responsible for providing the different atomic services and software components, which have been used in the BPaaS bundles.

Create the necessary artifacs executing the following instruction for all of components:

 ( cd workflow-parser && mvn install ) ( cd workflow-engine && bin/bootstrap.sh && mvn install )

Copy the war file generated in the WorkflowEngineService, activiti-webapp-rest2 and emo-app modules into the webapps folder Tomcat.
```
 <modulePath>/target 
```

Development environment

Create the eclipse project executing the following instruction for all necessary components:
```
 mvn eclipse:eclipse 
```

Production

Requirements

OpenJDK 1.7.x
MySql 5.5.x
Tomcat 7.x
Nginx

Installation

Validate that the version of Java is the correct one, if not install the version
```
 #java -version java version "1.7.0_85" 
```

Install the requeriments

 sudo aptitude install mysql-server sudo aptitude install tomcat7 sudo aptitude install nginx

Configure the schema and user of the Activiti (the password of the root has been introduced during the MySql installation).

 mysql -h localhost -u root -p create database activiti_cloudsocket; create user cloudsocket@localhost identified by 'cloudsocket'; grant all privileges on activiti_cloudsocket.* to cloudsocket@localhost;

Configure the modules of Tomcat (if you want to change the default password). Modify the file "<activiti-webapp-rest2>/WEB-INF/classes/db.properties" and "<activiti-webapp-explorer2>/WEB-INF/classes/db.properties" in order to introduce the new password.
```
 db=mysql jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/activiti_cloudsocket jdbc.username=cloudsocket jdbc.password=cloudsocket 
```

Configure the Nginx to redirect the 80 --> 8080. Modify the file (/etc/nginx/sites-available)

 server { listen 0.0.0.0:80; server_name localhost 134.60.64.132; client_max_body_size 4G; access_log /var/log/nginx/workflow_Engine.access.log; error_log /var/log/nginx/workflow_Engine.error.log; location /demo-app-1.0/ { # an HTTP header important enough to have its own Wikipedia entry: # http://en.wikipedia.org/wiki/X-Forwarded-For proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # enable this if and only if you use HTTPS, this helps Rack # set the proper protocol for doing redirects: # proxy_set_header X-Forwarded-Proto https; # pass the Host: header from the client right along so redirects # can be set properly within the Rack application proxy_set_header Host $http_host; # we don't want nginx trying to do something clever with # redirects, we set the Host: header above already. proxy_redirect off; proxy_pass http://localhost:8080/demo-app-1.0/; } location /activiti-webapp-rest2/ { # an HTTP header important enough to have its own Wikipedia entry: # http://en.wikipedia.org/wiki/X-Forwarded-For proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # enable this if and only if you use HTTPS, this helps Rack # set the proper protocol for doing redirects: # proxy_set_header X-Forwarded-Proto https; # pass the Host: header from the client right along so redirects # can be set properly within the Rack application proxy_set_header Host $http_host; # we don't want nginx trying to do something clever with # redirects, we set the Host: header above already. proxy_redirect off; proxy_pass http://localhost:8080/activiti-webapp-rest2/; } location /activiti-webapp-explorer2/ { # an HTTP header important enough to have its own Wikipedia entry: # http://en.wikipedia.org/wiki/X-Forwarded-For proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # enable this if and only if you use HTTPS, this helps Rack # set the proper protocol for doing redirects: # proxy_set_header X-Forwarded-Proto https; # pass the Host: header from the client right along so redirects # can be set properly within the Rack application proxy_set_header Host $http_host; # we don't want nginx trying to do something clever with # redirects, we set the Host: header above already. proxy_redirect off; proxy_pass http://localhost:8080/activiti-webapp-explorer2/; } }

Locate the war artifacts at the server:

 - WorkflowEngineService - activiti-webapp-rest2 - activiti-webapp-explorer2 - demo-app

Copy the war to the the tomcat folder (/var/lib/tomcat7/webapps)
```
 sudo cp * /var/lib/tomcat7/webapps 
```

Test the installation. Open a Navigator and test the following URLs:

 http://134.60.64.132/demo-app-1.0/services/ http://134.60.64.132/activiti-webapp-explorer2/ http://134.60.64.132/activiti-webapp-rest2/service/repository/deployments (basic authentication:kermit/kermit)

Test Cases

To execute the unit tests, we need to install the tool curl http://curl.haxx.se/ Optional: if you want to see the formatted response, the python library can be used. If not, you only need to remove this part: “| python -mjson.tool” of the command.

Create a new deployement:

It is needed to execute the following command:

 curl -X POST -F "file=@testCloudsocket.bpmn20.xml" -F "tenantId=ATOS" -F "endPointServiceList={\"workFlowId\":\"wf1\",\"endPointServices\":[{\"serviceId\":\"http://localhost:8080/demo-app-1.0/services/cardDesigner?wsdl\",\"serviceTaskId\":\"\",\"type\":\"WS\",\"ip\":\"127.0.0.1:8080\"},{\"serviceId\":\"http://localhost:8080/demo-app-1.0/services/email?wsdl\",\"serviceTaskId\":\"\",\"type\":\"WS\",\"ip\":\"127.0.0.1:8080\"}]}" --user kermit:kermit -H "content-type: multipart/form-data" http:// 134.60.64.132/activiti-webapp-rest2/service/repository/deployments | python -mjson.tool

Where the attributes are:

File is the bpm2.0 file (testCloudsocket.bpmn20.xml)
TenantId is the tenant of the organization (for the moment it is not used).

endPointServiceList is the list of the actual IP for the two services.

 Success response { "category": null, "deploymentTime": "2015-10-27T22:00:45.161Z", "id": "40", "name": "testCloudsocket.bpmn20.xml", "tenantId": "ATOS", "url": "http://134.60.64.132/activiti-webapp-rest2/service/repository/deployments/40" }

Detail of the deployement

 curl --user kermit:kermit http:// 134.60.64.132/activiti-webapp-rest2/service/repository/deployments/{deploymentId} | python -mjson.tool in our case deploymentId is 40: curl --user kermit:kermit http://134.60.64.132/activiti-webapp-rest2/service/repository/deployments/40 | python -mjson.tool

The description appears for your deployment.

 { "category": null, "deploymentTime": "2015-10-30T15:21:42.711+01:00", "id": "40", "name": "testCloudsocket.bpmn20.xml", "tenantId": "ATOS", "url": "http://127.0.0.1:8080/activiti-rest/service/repository/deployments/40" }

List of resources associated

 curl --user kermit:kermit http://134.60.64.132/activiti-webapp-rest2/service/repository/deployments/{deploymentId}/resources | python -mjson.tool in our case deploymentId is 40: curl --user kermit:kermit http://134.60.64.132/activiti-webapp-rest2/service/repository/deployments/40/resources | python -mjson.tool

List of resources appears.

 [ { "contentUrl": "http://134.60.64.132/activiti-webapp-rest2/service/repository/deployments/40/resourcedata/testCloudsocket.bpmn20.xml", "id": "testCloudsocket.bpmn20.xml", "mediaType": "text/xml", "type": "processDefinition", "url": "http://134.60.64.132/activiti-webapp-rest2/service/repository/deployments/40/resources/testCloudsocket.bpmn20.xml" }, { "contentUrl": "http://134.60.64.132/activiti-webapp-rest2/service/repository/deployments/40/resourcedata/testCloudsocket.testCloudsocket.png", "id": "testCloudsocket.testCloudsocket.png", "mediaType": "image/png", "type": "resource", "url": "http://134.60.64.132/activiti-webapp-rest2/service/repository/deployments/40/resources/testCloudsocket.testCloudsocket.png" } ]

Get the associated resource

 curl --user kermit:kermit http://134.60.64.132/activiti-webapp-rest2/service/repository/deployments/{deploymentId}/resourcedata/testCloudsocket.bpmn20.xml

In our case deploymentId is the id 40:

 curl --user kermit:kermit http://134.60.64.132/activiti-webapp-rest2/service/repository/deployments/40/resourcedata/testCloudsocket.bpmn20.xml

The BPMN file associated to our deployment:

 <?xml version='1.0' encoding='UTF-8'?> <definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:activiti="http://activiti.org/bpmn" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:omgdc="http://www.omg.org/spec/DD/20100524/DC" xmlns:omgdi="http://www.omg.org/spec/DD/20100524/DI" typeLanguage="http://www.w3.org/2001/XMLSchema" expressionLanguage="http://www.w3.org/1999/XPath" targetNamespace="http://www.activiti.org/processdef"> <import namespace="http://demo.seiplab.atosresearch.eu/" location="http://http://127.0.0.1:8080/demo-app-1.0/services/cardDesigner?wsdl" importType="http://schemas.xmlsoap.org/wsdl/"/> <import namespace="http://demo.seiplab.atosresearch.eu/" location="http://http://127.0.0.1:8080/demo-app-1.0/services/email?wsdl" importType="http://schemas.xmlsoap.org/wsdl/"/> <process id="testCloudsocket" name="testCloudsocket" isExecutable="true"> <userTask id="sid-9956FEED-377C-4C6D-81F5-1DF14EE36D56" name="test" activiti:candidateGroups="sales"/> <startEvent id="sid-AD365612-18DE-48F1-971F-944E51AB8804"/> <endEvent id="sid-F9B53F7F-5822-4653-BA91-CA88B3A026D3"/> <sequenceFlow id="sid-685E0C22-D2AD-4DF4-96C6-A435792C214A" sourceRef="sid-AD365612-18DE-48F1-971F-944E51AB8804" targetRef="sid-9956FEED-377C-4C6D-81F5-1DF14EE36D56"/> <sequenceFlow id="sid-541CE92A-8C33-4041-9359-693F38333D2F" sourceRef="sid-9956FEED-377C-4C6D-81F5-1DF14EE36D56" targetRef="sid-F9B53F7F-5822-4653-BA91-CA88B3A026D3"/> </process> <bpmndi:BPMNDiagram id="BPMNDiagram_testCloudsocket"> <bpmndi:BPMNPlane bpmnElement="testCloudsocket" id="BPMNPlane_testCloudsocket"> <bpmndi:BPMNShape bpmnElement="sid-9956FEED-377C-4C6D-81F5-1DF14EE36D56" id="BPMNShape_sid-9956FEED-377C-4C6D-81F5-1DF14EE36D56"> <omgdc:Bounds height="80.0" width="100.0" x="315.0" y="163.0"/> </bpmndi:BPMNShape> <bpmndi:BPMNShape bpmnElement="sid-AD365612-18DE-48F1-971F-944E51AB8804" id="BPMNShape_sid-AD365612-18DE-48F1-971F-944E51AB8804"> <omgdc:Bounds height="30.0" width="30.0" x="136.45001220703125" y="184.0"/> </bpmndi:BPMNShape> <bpmndi:BPMNShape bpmnElement="sid-F9B53F7F-5822-4653-BA91-CA88B3A026D3" id="BPMNShape_sid-F9B53F7F-5822-4653-BA91-CA88B3A026D3"> <omgdc:Bounds height="28.0" width="28.0" x="575.4500122070312" y="189.0"/> </bpmndi:BPMNShape> <bpmndi:BPMNEdge bpmnElement="sid-541CE92A-8C33-4041-9359-693F38333D2F" id="BPMNEdge_sid-541CE92A-8C33-4041-9359-693F38333D2F"> <omgdi:waypoint x="415.0" y="203.0"/> <omgdi:waypoint x="575.4500122070312" y="203.0"/> </bpmndi:BPMNEdge> <bpmndi:BPMNEdge bpmnElement="sid-685E0C22-D2AD-4DF4-96C6-A435792C214A" id="BPMNEdge_sid-685E0C22-D2AD-4DF4-96C6-A435792C214A"> <omgdi:waypoint x="166.44738152787627" y="199.2809153861509"/> <omgdi:waypoint x="315.0" y="202.06345112885748"/> </bpmndi:BPMNEdge> </bpmndi:BPMNPlane> </bpmndi:BPMNDiagram> </definitions>

Delete the deploment

 curl -X DELETE --user kermit:kermit http://127.0.0.1:8080/activiti-rest/service/repository/deployments/40

User Manual

API specification

HandBook

Handbook WFE

Developer manual

Synergic Cross-Layer Monitoring Framework 1.1

2017-02-14T15:31:40Z

Research Problem #

Various monitoring frameworks have been proposed and offered which usually cover only one or two
levels of abstraction. Moreover, such frameworks usually rely on level-independent mechanisms
which are able to support the individual assessment over the respective metrics. The latter
leads to the issue of measurability gaps: as adjacent levels are not able to cooperate,
then it is not possible to produce measurements of a high-level metric from measurements
of a lower-level metric. This issue leads to the fact that most of the monitoring frameworks
are able to support a rather limited and fixed set of metrics. Related to this issue is
the problem of metric computability: in particular, the frameworks are not able, based on the
high-level but complete description of a metric, to produce its measurements. They rather
stay on a quite technical mapping of the fixed description of the limited set of metrics
supported to the corresponding sensing or aggregation code needed for the metric measurement.

The above inabilities of the current monitoring frameworks highlight the need for introducing
a cross-layer monitoring framework which is able to measure metrics over different levels as
well as cover measurability gaps by being able to address the measurement of any kind of metric.
Such a framework should also rely on a flexible and complete high-level description of a metric
which is independent from any technical specificities.

Solution #

FORTH and University of ULM (UULM) have developed two separate monitoring frameworks which cover different
levels of abstraction. The monitoring framework of FORTH covers mainly the workflow and service level,
while the monitoring of UULM covers mainly the infrastructure and platform levels. As such, it
is apparent that the integration of these frameworks can result in the production of a synergic
framework which is able to cover the measurement of metrics at all possible levels. To this end,
a synergic framework has been designed and is currently developed which is able to capitalize over
the individual capabilities of the aforementioned monitoring frameworks. Each individual framework
is seen as a service which offers monitoring and evaluation capabilities. The cross-layer aggregation
of metric measurements between the two individual frameworks is facilitated by a publish-subscribe
mechanism: this means that one framework subscribes to those lower-level measurements that are needed in order to
aggregate a measurement for a higher-level. The combined framework also offers another publish-subscribe
mechanism in order to enable interested components, like an Adaptation Engine, to retrieve the SLO
evaluations produced and enact, in this case, respective adaptation actions.

Other interesting features of the combined framework which map to common features of the individual
frameworks are the following: recovery capability in case a monitoring component fails, data
redundancy to avoid important monitoring data loss as well as capability to monitor both domain-independent
and domain-specific metrics.

Architecture #

The architecture of the combined/synergic monitoring framework can be seen in the following figure. As
expected, the respective individual frameworks are included and they communicate via a publish-subscribe
mechanism. In addition, this mechanism is used in order to propagate measurements to the Evaluator
component which includes a CEP engine responsible for evaluating conditions over the propagated measurements.
The events produced are further propagated to interested components, such as Adaptation Engines.
The measurements can also be inspected in a programmatic or UI-based manner by two other components
which are part of the Collosseum cloud orchestration engine. The Collosseum API enables the
programmatic retrieval of measurements that are stored in the Evaluator while the Collosseum UI enables the
production of graphs over these measurements. Both components can rely on the measurements propagated
by the individual monitoring frameworks but in principle they could also require the further aggregation
of the stored measurements which is natively supported by the encompassing CEP Engine.

This innovation item will be made available at Gitlab.

References: #

Synergic Cross-Layer Adaptation Framework 1.1

2017-02-14T14:53:16Z

Research Problem #

BPaaS adaptation needs to be performed across different levels of abstraction. This is required
in order to avoid having different adaptation mechanisms being triggered
independently such that the effects of one mechanism can be undone by the other, thus resulting in
vicious adaptation cycles. Moreover, different levels need to be covered as one problematic
situation could be impossible to be addressed by just one level. For instance, the migration of
a software component from one cloud to another might also require adopting the workflow level in
order to perform a respective replacement of the service endpoint in the workflow description,
usually done in the context of service replacement.

Solution #

The cross-layer BPaaS adaptation solution comprises the integration of different adaptation
frameworks that have been developed by two academic partners of the CloudSocket project, namely
FORTH and University of ULM. By joining forces, current adaptation implementation gaps at
different levels are covered in the form of services which include methods mapping to the level-specific
adaptation actions. In addition, the respective individual features offered by
each framework can be capitalised and exploited to make them available for the combined framework.
As such, this solution looks ideal for realising or replacing the functionality of the
Adaptation Engine in the current CloudSocket implementation.

Architecture #

The architecture of the combined / synergic framework is depicted in the following figure.
As it can be seen, this framework comprises the following components: (a) the Transformer is responsible for mapping adaptation rules, which are
generated by the BPaaS Evaluation Environment, into two forms: one which is
suitable for storage in the Rule Base and another which is suitable for storage in the Adaptation
Engine; (b) the Rule Base is responsible for storing the adaptation rules provided by the
Transformer and discovering the one which is the most suitable to confront the current
problematic situation. The latter discovery is supported via the use of monitoring facts
communicated by the (BPaaS) Monitoring Framework. In case that an adaptation rule should be
triggered, then the Adaptation Engine is informed in order to enact the respective adaptation;
(c) the Adaptation UI is a UI enabling the expert to modify the rules automatically generated
by the BPaaS Evaluation Environment or to insert new rules to cover new adaptation situations;
(d) the Adaptation Engine is a normal workflow engine which is able to enact the adaptation
workflows needed while it is also responsible for storing the adaptation actions that have been
performed in the Adaptation DB; (e) the workflows executed by the Adaptation Engine map to
method calls of level-specific services: the service and workflow level is covered by the
cross-layer adaptation framework of FORTH while the infrastructure and platform level is
covered by the adaptation framework of UULM. As already indicated, the methods of these
services map to particular level-specific adaptation actions that are offered for
execution; (f) finally, the Adaptation Service enables the retrieval of adaptation history
information from the Adaptation DB, mostly for the analysis purposes of the BPaaS Evaluation
Environment, while it also enables the programmatic execution of adaptation workflows, in case
where manual intervention is needed, thus mapping to the case that the current situation is
not covered by the current set of adaptation rules modelled.

The source code will be available at the Gitlab.

References: #

PaaS Orchestration and Adaptation 1.7

2017-02-07T12:22:03Z

1 Problem Description
2 Solution Approach
3 Architecture
4 Usage
5 Video Presentation
6 References

Problem Description

PaaS abstraction is still an open and on-going topic in current research. It can drastically decrease costs, by e.g. sharing infrastructure of public PaaS providers to host an application. Therefore, the integration of a PaaS abstraction into the Cloud Provider Engine is of major interest for CloudSocket. See Deliverable D3.3 for a research on current Cloud Orchestration Tools and their state towards PaaS services and provider integration.

Solution Approach

Our solution for this is two-fold: (i) enhancing the application and component instance life-cycle by PaaS-specific activities, and (ii) integrating and developing the PaaS Unified Library (PUL) into the Cloud Provider Engine, which is powered by Colosseum.

Architecture

The communication to the cloud provider is ensured by the PaaS abstraction layer “Dagger”, which is the higher-level pendant to Sword, the IaaS abstraction layer. This layer unifies the API calls to different Cloud providers.

Usage

http://134.60.64.166/cloud-provider-engine-ui/#/login

Video Presentation

A video is available on YouTube.

References

For more details on this, please check the respective repositories:

Research branch of Cloudiator/Colosseum

Adaptation Management component repository

Also please refer to the wiki pages:

Adaptation Management

Unified PaaS component

Adaptation Management 1.4

2017-02-07T11:35:06Z

1 Description
2 Architecture
3 References
4 Link

Description

This component manages and processes adaptations plans. Those are the executable equivalent to the CAMEL definitions of Adaptation Rules and Adaptation Tasks.

Architecture

The current Adaptation Management component consists of a REST-interface connected to a server that stores the adaptation plans. A plan is a represented as connected steps of a workflow.

[Figure REST interface / example]

[Figure communication AM, AM-C, AM-Test]

References

Deliverable D3.3 Deliverable D3.4

Link

https://omi-gitlab.e-technik.uni-ulm.de/cloudsocket/adaptation-management https://omi-gitlab.e-technik.uni-ulm.de/cloudsocket/adaptation-management-test https://omi-gitlab.e-technik.uni-ulm.de/cloudsocket/adaptation-management-client

AXE Adaptation Framework 1.0

2017-02-07T08:37:28Z

1 Research Problem
2 Solution Approach
3 Architecture
4 References
5 Link

Research Problem

Current Cloud Orchestration Tools have either too simplistic or too verbose methods of adaptation descriptions. Commercial tools have mainly simple approaches of adaptation, such as container scaling, and research-driven tools suffer of too loosely described methods that are hardly usable for the average customer. An example for the latter is the BPMN integration into TOSCA to describe workflow, for which the user has to implement the classes on their own.

Solution Approach

We aim for an integrated component, that holds the CAMEL adaptation plans, which targets our requirements as described in D3.3. We are sure that we achieve a more useable approach than generic BPMN workflows, as our approach is very specific to the cloud. The Axe adaptation approach furthermore targets to be integrated as loosely coupled component that can be added to the Cloud Provider Engine / Cloudiator without changing internals.

Architecture

[Picture of Adaptation Management, Axe [MS] and how they communicate] The Adaptation Management component was integrated with the Axe component of the Cloudiator framework in a loosely coupled way. The figure above shows the integration into the components. As any other external component it uses the REST interface of Colosseum and changes the entities as described in the adaptation plans.

References

Deliverable D3.3 Deliverable D3.4

Link

Adaptation Management

OWL-Q Parser 2.0

2017-02-03T18:36:35Z

1 Research Problem
2 Solution Approach
3 References

Research Problem

Due to the heterogeneity, both structural and semantic, in QoS term description which is inherent in the service and cloud world, there is a need for introducing a semantic language which is able to cover the non-functional service description. As such, the use of such language will enable reaching better accuracy levels in service discovery and composition. Apart from non-functional service profiles and requests, this language should be able to specify SLAs in the way that extends the current state-of-the-art. This means that it should be complete enough in order to cover all information required for supporting the management of all service lifecycle activities.

The required language should be able to also specify KPIs as well as link them to goals in order to support BPaaS evaluation as well as goal analysis enabling broker to inspect whether their strategic, tactical and operational goals are satisfied. The current set of languages employed for this purposes suffer from the following drawbacks: (a) they are not rich or complete enough to cover the respective domain; (b) they are mapped to a quite technical level which is not suitable for business experts; (c) they are not able to exploit different information sources, even external to the respective BPaaS (management) system; (d) in some cases, they are not linked to goals.

Solution Approach

OWL-Q is a language which has been considered one of the most prominent non-functional service specification languages by survey papers in service quality description. This is due to its expressivity, richness and completeness (in terms of domain coverage) as well as to the fact that it relies on semantics and ontologies in particular. OWL-Q extends the W3C OWL standard and has been designed into several facets, each one focusing on different measurability aspects, including attribute, metric, unit (of measurement), and value type. It is also assorted by: (a) semantic rules specified in the SWRL language (W3C Submission) which enable the validation of OWL-Q models as well as the derivation of new knowledge that can take even the form of matches between quality terms. An overview of OWL-Q can be seen in the following two figures, where the first figure covers the 5 facets and the second the last one.

OWL-Q has been recently extended in order to also specify SLAs as well as cover the previously referred research gap in SLA description. In a nutshell, the OWL-Q SLA extension, named as Q-SLA, has the following capabilities: (a) it can specify both SLA and SLA templates; (b) it captures directly the notion of a Service Level (SL) to be delivered by a service which maps to a logical combination of Service Level Objectives (SLOs). The latter are simple constraints over quality terms; (c) it enables the transitioning from one SL to another in order to allow for flexibility in SLA management. In particular, such a SL transitioning can be beneficial for a signatory party as it enables the on-demand modification of the SL to be delivered without the need of performing a critical action, such as SLA re-negotiation. Such a modification might be required when specific party requirements are modified, e.g., due to increase in workload due to an increase of the party clientelle; (d) it associates an SLO to various important concepts, like qualifying conditions, dictating when the SLO should hold, as well as penalties and rewards to be supplied when the respective SLO is violated or surpassed, respectively; (e) it is able to specify service price models and connect then to the SLO penalties and rewards; (f) it enables the hierarchical specification of SLAs which is highly needed in the case of BPaaS services, which are cross-level agglomeration of cloud services; (g) finally it allows the definition of critical situations for settlement along with the respective actions that need to take place, such as SLA re-negotiation or cancelling. As Q-SLA builds on top of the OWL-Q specification facet, an overview of this extension is depicted in the following figure which uses different colours to characterise concepts which are original or new with respect to the OWL-Q language.

By again focusing on the respective research gap identified previously, another OWL-Q extension was developed in order to cover the modelling of KPIs and goals as well as their linkage. This extension is depicted in the following figure where different colours (red vs. other) are being used to denote extension or original OWL-Q concepts. In summary, the following features characterise this OWL-Q extension: (a) it specifies KPIs as extensions to simple constraints which are enhanced with the description of additional thresholds (warning apart from violation ones); (b) it enables issuing queries over databases or calling APIs and using the respective result as an input argument to a KPI metric formula; (c) it enables specifying direct relationships between KPIs (child-parent) in order to enable KPI drill-down to discover the root causes of a high-level KPI violation; (d) it covers the modelling of manual measurements as humans are usually another source of information apart from the automatic ones; (e) it allows the modelling of KPI evaluations which can assist in the checking of respective trends in BPaaS performance; (f) it covers the specification of goal hierarchies as well as the linking of goals to KPIs via goal contributions.

Both OWL-Q as well as its extensions are supported by a JAVA programmatic API which enables the parsing as well as the serialisation of OWL-Q models. This API can be used to construct non-functional service matchmaking and selection algorithms as well as customised OWL-Q editors. For the time being, the latter type of editor does not yet exist but is planned to be developed. In case the interested reader and possible adopter of OWL-Q desires to manually edit an OWL-Q model, then he/she can use well-known ontology editors, like Protege, for now.

The source code is publicly available at GitLab.

References

Smart Service Discovery and Composition Blueprint 2.0

2017-02-03T17:37:28Z

1 Research Problem
2 Solution Approach
3 Architecture
4 References

Research Problem

The Smart Service Discovery and Composition tool enables the automation of BPaaS allocation which is currently manually performed by the BPaaS broker. The BPaaS broker is currently faced with a two faced problem: (a) how to discover those services which are able to either realise the functionality of the BPaaS workflow service tasks or support the execution of the internal software components of these tasks; (b) how to select the best alternative from the service candidates of each task such that the user requirements at both the global and local level are optimised.

Concerning the first problem, the current state-of-the-art focuses on providing solutions on just one aspect, either the functional or the non-functional one. In many cases, the respective techniques do not exploit the service semantics. In addition, the alignment of QoS terms is usually not considered in non-functional service matchmaking. These two issues lead to low precision and recall in the service discovery process. Moreover, the execution time and the scalability of the respective discovery algorithms are usually not satisfactory due to the non-exploitation of smart techniques which attempt to cleverly organise the service advertisement space.

As far as the second problem is concerned, we need first to explicate that the service selection problem in BPaaS allocation is usually harder with respect to the selection of SaaS or IaaS services. This is due to the fact that both IaaS and SaaS selection are inter-dependent on each other. This means that the selection of an IaaS service can have an effect on the QoS at the SaaS level which can then influence the service selection at this latter level. As such, there is a need for an approach which is able to select both IaaS and SaaS services in conjunction by still taking into account all types of user requirements. Such an approach should also cater for the case where there are choices to be made even for the same service task in terms of selecting either an external SaaS to realise its functionality or an IaaS to support the execution of an internal software component (either owned or outsourced by the broker) that realises the functionality of this task.

Secondly, by focusing on individual level service selection, the proposed approaches usually exhibit various issues which include the following: (a) the dependencies between the different QoS terms are not considered; (b) pessimistic or average approach over service graph and available solution space is employed; (c) just a single value and not ranges of QoS values are considered to cater for the suitable service description in dynamic environments; (d) no solution is returned for over-constrained user requirements.

Solution Approach

The Smart Service Discovery and Composition tool enables both the semantic discovery of cloud services at different levels of abstraction as well as the concurrent selection of both SaaS & IaaS services for service-based workflow concretisation according to the broker functional and non-functional requirements.

The tool actually comprises two main modules dedicated to cloud service discovery and selection, respectively. As such, the respective feature presentation is done per each main module of this tool.

Concerning service discovery, the main features of the blueprint can be summarised as follows:

 - Supports both functional and non-functional semantic service discovery to cover all possible aspects in service description. The functional aspect is covered by OWL-S while the non-functional one by OWL-Q. - Smart service discovery is offered which enables boosting the service matchmaking time. Smartness is realised at two levels: (a) the transactional combination of aspect-specific matchmakers according to different composition semantics (currently parallel composition maps to the fastest implementation); (b) at the individual, aspect-specific level, each service matchmaker utilises smart structures in order to better organise the service advertisement space and accelerate the service matchmaking. - The tool enables not only the matchmaking but also the management (update, insertion, deletion) of the functional and non-functional service specifications. - A Java and REST API are offered to enable the service discovery and service specification management.

As far as service selection is concerned, the respective module exhibits the following features:

 - concurrent selection of both IaaS and SaaS services to deliver purely optimal selection solutions for the service-based BPaaS workflow. - catering also for different realisation alternatives for a SaaS service: (a) either an external SaaS service can be exploited or (b) an internal one which also requires being hosted in a public or private cloud. In the latter case, the internal service code would be either purchased or has been developed internally by the broker organisation. - consideration of a great variety of non-functional requirements, including performance and reliability ones (over, e.g., response time, throughput, availability and reliability), security ones at both a coarse (in terms of security controls) and a fine-grained level (in terms of security SLOs) and cost. - capability to map low-level non-functional capabilities to higher-level ones in the form of dependency functions to cover any dependency gap within the respective optimisation problem. - capability to handle both linear and non-linear constraints as well as both real and integer-based variables (mapping to the coverage of the previous functions as well as aggregation ones over non-functional metrics (from component/service to application/workflow level)). - in case that a specific time deadline has to be provided, the respective solver can be configured to take it into consideration, thus being able to more rapidly produce solutions with a potential penalty over solution optimality. - parts of the problem can be fixed according to knowledge derived by a Knowledge Base by applying rules over the BPaaS execution history.

Architecture

This architecture of this tool, depicted in the following figure, includes three main levels: UI, business logic and database, while it certainly embraces service-orientation. It comprises the following components at the highest level:

 - The UI component offers the respective visualisation and editing means to enable the initialisation of service discovery and workflow concretisation interactions. At the background, it performs REST calls over the next component, the REST SDS service. - The REST SDS (Service Discovery and Selection) service encapsulates the whole functionality of the blueprint and enables its programmatic access via REST function calls. This functionality is offered via two different modules which focus on the two main parts of service discovery and selection. - The Service Discovery Module enables performing functional and non-functional service discovery via the supply of a combined OWL-S and OWL-Q request. - The Service Selection Module actually realises the service-based workflow concretisation functionality. As service discovery is a prerequisite for service-based workflow concretisation, this module is actually able to invoke the Service Discovery Module in order to obtain all possible (service) alternatives for each BPaaS workflow task.

This high-level architecture is further elaborated by concentrating on the internal architecture of the latter two modules. The latter architecture is also able to unveil the third level which was not apparent in the high-level architecture.

The architecture of the Service Discovery Module is depicted in the following figure. As it can be seen, the Specification Processor is the component which takes the user/broker input and attempts to validate it both syntactically, semantically as well as in a constraint-based manner. Once user input is validated, its non-functional part is also aligned according to a specific non-functional alignment algorithm operating over a (non-functional) term store. Both the aligned non-functional specification and the functional one are passed to the Compositor which then issues them to the respective aspect-specific matchmakers, which are named as Functional Matchmaking Module and NonFunctional Matchmaking Module. Depending on the type of functionality requested, different actions are actually performed. In case of service registration / updating / deletion, the corresponding matchmaker performs the required update and then informs the Compositor for its main result. For service registration and deletion, transactionality is guaranteed by the latter component. This means that if for some reason, an aspect-specific registration / deletion fails, then the other aspect-specific registration is also rolled back to maintain a consistent state in the whole system. To assist in transactionality enforcement, a Combined Registry can be consulted and managed by the Compositor which enables storing the mappings between functional and non-functional specifications of services.

In case of service matchmaking, the Compositor realises the service discovery's composition logic by being able to execute different orchestration algorithms, such as sequential and parallel ones. In any case, the facilities of the respective matchmaking modules are exploited in order to support the required aspect-specific discovery functionality. Once both aspect-specific discovery results are obtained, then these are relayed back from the Compositor to the Specification Processor.

The Functional Matchmaking Module is a slight modification of the service matchmaker that has been developed in the Alive European project. Apart from being semantic, this matchmaker employs a smart structure and respective dynamic encoding scheme for domain ontologies that enables discovering concept ancestors or descendants in O(1) time, thus greatly speeding up the functional service matchmaking time where such ontology-based functions are highly needed and used. For simplification reasons, the internal architecture of this module can be seen as a combination of two main components: (a) the functional matchmaking algorithm and (b) the Functional Store as the storage medium for the functional specification of services.

The Non-Functional Matchmaking Module is an agglomeration of different non-functional matchmaking algorithms which are able to exploit two different techniques to perform the matchmaking: (a) constraint programming / solving and (b) ontology subsumption. The respective internal architecture of this module can be seen in the following figure. As it can be seen, it comprises 6 main components. The Broker is responsible for orchestrating the appropriate actions towards conducting the service matchmaking. It actually realises internally the service matchmaking logic and exploits the facilities of other components in order to realise part of the needed functionality. In particular, in case of constraint-based service matchmaking, the respective service request needs to be transformed into a constraint (satisfaction) problem (CSP) via the Transformer. This CSP is then exploited in order to realise a corresponding matchmaking metric which also takes into account the CSP model of the corresponding non-functional service specification by exploiting the facilities of the Constraint Solver. In case of ontology-based service matchmaking, an Ontology Reasoner is exploited in order to infer the subsumption hierarchy between a pair of service request and offer or between the service request and all the non-functional offers, depending on the respective ontology-based non-functional service matchmaking algorithm to be exploited.

The Service Selection Module follows a simplified architecture, depicted in the following figure, which comprises three main components: (a) the Service Selection Controller is responsible for the orchestration of the components involved in the service-based workflow concretisation. This component first invokes the Input Processor in order to construct the appropriate input for the actual optimisation problem construction. This means that based on the respective semantically-annotated service-based BPaaS workflow, the Input Processor performs service discovery for all the tasks involved according to both task-based functional and non-functional broker requirements provided in the form of annotations. This also means that this component takes into account the BPaaS CAMEL model in order to discover those IaaS offerings which satisfy the respective requirements posed for the BPaaS internal service components. Once all input has been gathered and extended, the Service Selection Controller invokes the Optimisation Problem Constructor with it in order to transform it into a constraint optimisation problem. The later problem is finally sent by the Service Selection Controller to the Constraint Solver for solving.

The source code is publicly available at GitLab.

References

DMN-to-CAMEL Mapper 2.1

2017-02-02T08:38:40Z

1 Research Problem
2 Solution Approach
3 Architecture
4 References

Research Problem

The DMN-to-CAMEL-Mapper prototype reduces the technical complexity of the software component allocation by mapping high-level business requirements to the low-level cloud-specific description.

As business experts still require technical assistance for consuming cloud services and allocating the software components, the DMN-to-CAMEL-Mapper aims to create a way to semi-automatically handle the software component allocation and configuration based on high-level parameters. In this respect the Decision Model and Notation (DMN) is applied.

DMN is an industry standard for modeling and executing decisions that are determined by business rules. The DMN standard provides a human-readable common notation for modelling and automating decisions. We choose decision tables (DTs) to represent decisions as these are well known to business experts.

Solution Approach

The DMN-to-CAMEL approach enables the modelling of cloud applications by using non-technical business values relating to business requirements, which will be mapped to the technical CAMEL model.

In terms of a running example, the DMN-to-CAMEL-Mapper can be used for creating different kind of deployment models for the ChristmasCardDesigner service. An example scenario, which can be solved with the prototype, is the following: The CAMEL deployment model fragment should be generated based on the desired cloud provider and the customer level bronze, silver and gold, where the business values are mapped to the respective virtual machine flavours. Therefore, the required DMN tables need to defined, which can be edited via the web-based editors offered by ADOxx or Camunda DMN Editor

Defined DMN tables are registered at the DMN-to-CAMEL-Mapper and are executed via the provided REST API. The result of an exemplary call to get the deployment CAMEL fragment for the parameters cloud provider = UULM and customer level = gold can executed with the online instance.

A more complex example with connected DMN tables could be used to determine the placement of the ChristmasCardDesigner software component based on the following business values: software state, customer level, privacy, and scalability. A first table can determine if the software component should be deployed on IaaS if the software state is final while PaaS is selected when the software state is development as PaaS supports the easy integration of continuous delivery of new software versions. Based on the decision connected tables can select the actual cloud provider, either a IaaS or a PaaS provider, based on the customer level and privacy values. Finally, is also possible to derive adaptation actions based on the scalability values, e.g. expected amount of users. In the end, a CAMEL model is returned, comprising the model fragment for the selected cloud provider and a model fragment with adaptation actions.

Architecture

A high-level overview of the DMN-to-CAMEL-Mapper architecture is provided in following figure. To execute a mapping, the prototype provides a REST interface as well as a web-based UI. Due to the use of the Swagger REST API description, it is possible to auto-generate also clients for all common programming languages that eases the integration in existing systems.

The source code is publicly available at GitLab.

Try out the first version of the prototype by yourself: DMN-to-CAMEL-Mapper service

References

D3.3 - BPaaS Allocation and Execution Environment Blueprints
D3.4 - BPaaS Allocation and Execution Environment Prototypes
Griesinger, Frank; Seybold, Daniel; Domaschka, Jörg; Kritikos, Kyriakos und Woitsch, Robert,A DMN-based Approach for Dynamic Deployment Modelling of Cloud Applications, ESOCC 2016

Service Replacement 1.0

2016-12-24T04:24:33Z

<?xml version="1.0" encoding="ASCII"?> <camel:CamelModel

 xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:adaptation="http://www.cloudsocket.eu/2016/05/camel/adaptation" xmlns:camel="http://www.cloudsocket.eu/2016/05/camel" xmlns:deployment="http://www.cloudsocket.eu/2016/05/camel/deployment" xmlns:metric="http://www.cloudsocket.eu/2016/05/camel/metric" xmlns:provider="http://www.cloudsocket.eu/2016/05/camel/provider" xmlns:requirement="http://www.cloudsocket.eu/2016/05/camel/requirement" xmlns:type="http://www.cloudsocket.eu/2016/05/camel/type" xmlns:unit="http://www.cloudsocket.eu/2016/05/camel/unit" xsi:schemaLocation="http://www.cloudsocket.eu/2016/05/camel/adaptation camel.ecore#//adaptation http://www.cloudsocket.eu/2016/05/camel camel.ecore http://www.cloudsocket.eu/2016/05/camel/deployment camel.ecore#//deployment http://www.cloudsocket.eu/2016/05/camel/metric camel.ecore#//metric http://www.cloudsocket.eu/2016/05/camel/provider camel.ecore#//provider http://www.cloudsocket.eu/2016/05/camel/requirement camel.ecore#//requirement http://www.cloudsocket.eu/2016/05/camel/type camel.ecore#//type http://www.cloudsocket.eu/2016/05/camel/unit camel.ecore#//unit" name="ChristmasCardSendingModel"> <applications name="ChristmasCardSending" version="1.0" owner="//@organisationModels.0/@organisation"/> <deploymentModels name="ChristmasCardSendingDeployment" globalVMRequirementSet="//@deploymentModels.0/@vmRequirementSets.1"> <internalComponents xsi:type="deployment:InternalServiceComponent" name="CardDesigner" type="SERVLET" serviceType="REST"> <configurations xsi:type="deployment:ScriptConfiguration" name="CardDesignerConfiguration" downloadCommand="'sudo apt-get install -y curl'" installCommand="'curl -o demoapp_install_ubuntu.sh https://omi-gitlab.e-technik.uni-ulm.de/cloudsocket/prototype_v1_files/raw/master/demoapp_install_ubuntu.sh && chmod +x demoapp_install_ubuntu.sh && ./demoapp_install_ubuntu.sh'" startCommand="'/apache-tomcat-7.0.65/bin/catalina.sh run'" os="Ubuntu"/> <requiredHost name="CardDesignerRequiredHost"/> <workflowTaskIDs>sid-1C5E88D8-C7E3-4FAC-85E5-FAD80099C28B</workflowTaskIDs> <workflowTaskIDs>sid-D891CCD3-40B6-4555-9C84-81BECCDCB1C2</workflowTaskIDs> <workflowTaskIDs>sid-B99151C2-9914-4E71-9540-9DFE38334B7B</workflowTaskIDs> </internalComponents> <internalComponents xsi:type="deployment:InternalServiceComponent" name="EmailService" type="SERVLET"> <requiredHost name="EmailServiceRequiredHost"/> <workflowTaskIDs>sid-A952A4DD-CED9-440F-82FC-A6DE0568780A</workflowTaskIDs> </internalComponents> <internalComponentInstances xsi:type="deployment:InternalServiceComponentInstance" name="CardDesignerInstance" type="//@deploymentModels.0/@internalComponents.0" endpoint="http://localhost:8080/demo-app-1.0/services/cardDesigner"> <requiredHostInstance name="CardDesignerInstanceRequiredHost" type="//@deploymentModels.0/@internalComponents.0/@requiredHost"/> </internalComponentInstances> <internalComponentInstances xsi:type="deployment:InternalServiceComponentInstance" name="EmailServiceInstance" type="//@deploymentModels.0/@internalComponents.1" endpoint="http://localhost:8080/service/wsdl/ZimbraService.wsdl"> <requiredHostInstance name="EmailInstanceRequiredHost" type="//@deploymentModels.0/@internalComponents.1/@requiredHost"/> </internalComponentInstances> <vms name="CardDesignerVM" vmRequirementSet="//@deploymentModels.0/@vmRequirementSets.0"> <providedHosts name="CardDesignerVMProvidedHost"/> </vms> <vms name="EmailServiceVM"> <providedHosts name="EmailServiceProvidedHost"/> </vms> <vmInstances name="CardDesignerVMInstance" type="//@deploymentModels.0/@vms.0" vmType="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" vmTypeValue="//@providerModels.0/@constraints.12/@attributeConstraints.0/@fromValue"> <providedHostInstances name="CardDesignerVMInstanceProvidedHost" type="//@deploymentModels.0/@vms.0/@providedHosts.0"/> </vmInstances> <vmInstances name="EmailServicePrivateVMInstance" type="//@deploymentModels.0/@vms.1" vmType="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" vmTypeValue="//@typeModels.0/@dataTypes.10/@values.1"> <providedHostInstances name="EmailServicePrivateVMInstanceProvidedHost" type="//@deploymentModels.0/@vms.1/@providedHosts.0"/> </vmInstances> <hostings name="CardDesignerToVM" providedHost="//@deploymentModels.0/@vms.0/@providedHosts.0" requiredHost="//@deploymentModels.0/@internalComponents.0/@requiredHost"/> <hostings name="EmailServiceToVM" providedHost="//@deploymentModels.0/@vms.1/@providedHosts.0" requiredHost="//@deploymentModels.0/@internalComponents.1/@requiredHost"/> <hostingInstances name="CardDesignerInstanceToVMInstance" type="//@deploymentModels.0/@hostings.0" providedHostInstance="//@deploymentModels.0/@vmInstances.0/@providedHostInstances.0" requiredHostInstance="//@deploymentModels.0/@internalComponentInstances.0/@requiredHostInstance"/> <hostingInstances name="EmailServiceInstanceToVMInstance" type="//@deploymentModels.0/@hostings.1" providedHostInstance="//@deploymentModels.0/@vmInstances.1/@providedHostInstances.0" requiredHostInstance="//@deploymentModels.0/@internalComponentInstances.1/@requiredHostInstance"/> <vmRequirementSets name="CardDesignerVMRequirementSet" quantitativeHardwareRequirement="//@requirementModels.0/@requirements.3"/> <vmRequirementSets name="GlobalVMRequirementSet" locationRequirement="//@requirementModels.0/@requirements.4" osOrImageRequirement="//@requirementModels.0/@requirements.2"/> <vmRequirementSets name="EmailServiceVMRequirementSet" quantitativeHardwareRequirement="//@requirementModels.0/@requirements.5"/> </deploymentModels> <locationModels name="ChristmasCardSendingLocation"> <regions id="EU" name="Europe"/> </locationModels> <metricModels name="ChristmasCardSendingMetric"> <contexts xsi:type="metric:RawMetricContext" name="RawResponseTimeContext" component="//@deploymentModels.0/@internalComponents.1" application="//@applications.0" metric="//@metricModels.0/@metrics.0" sensor="//@metricModels.0/@sensors.0"/> <metrics xsi:type="metric:RawMetric" name="RawResponseTime" unit="//@unitModels.0/@units.0" property="//@metricModels.0/@properties.0"/> <conditions xsi:type="metric:MetricCondition" name="RTLeqSixty" comparisonOperator="LESS_EQUAL_THAN" threshold="60.0" metricContext="//@metricModels.0/@contexts.0"/> <properties name="ResponseTime" type="MEASURABLE"/> <sensors name="ResponseTimeSensor"/> </metricModels> <organisationModels name="BrokerOrganisation"> <organisation name="Broker" email="info@broker.com"/> </organisationModels> <providerModels name="OmistackProvider"> <constraints xsi:type="provider:Implies" name="M1.SMALL_Constraint_Mapping" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.0"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.2"> <fromValue xsi:type="type:EnumerateValue" name="m1.small"/> <toValue xsi:type="type:IntegerValue" value="2048"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.3"> <fromValue xsi:type="type:EnumerateValue" name="m1.small"/> <toValue xsi:type="type:IntegerValue" value="1"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.5"> <fromValue xsi:type="type:EnumerateValue" name="m1.small"/> <toValue xsi:type="type:IntegerValue" value="20"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.8"> <fromValue xsi:type="type:EnumerateValue" name="m1.small"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne/2"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.LARGE_Constraint_Mapping" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.0"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.2"> <fromValue xsi:type="type:EnumerateValue" name="m1.large" value="1"/> <toValue xsi:type="type:IntegerValue" value="8192"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.3"> <fromValue xsi:type="type:EnumerateValue" name="m1.large" value="1"/> <toValue xsi:type="type:IntegerValue" value="4"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.5"> <fromValue xsi:type="type:EnumerateValue" name="m1.large" value="1"/> <toValue xsi:type="type:IntegerValue" value="80"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.8"> <fromValue xsi:type="type:EnumerateValue" name="m1.large" value="1"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne/4" value="1"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="RegionOne/9c154d9a-fab9-4507-a3d7-21b72d31de97_Constraint_Mapping_OS_CREDENTIALS" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.0"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.1"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/9c154d9a-fab9-4507-a3d7-21b72d31de97" value="1"/> <toValue xsi:type="type:EnumerateValue" name="Ubuntu Server 14.04.2 AMD64 LTS"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.6"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/9c154d9a-fab9-4507-a3d7-21b72d31de97" value="1"/> <toValue xsi:type="type:EnumerateValue" name="UNIX" value="1"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.7"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/9c154d9a-fab9-4507-a3d7-21b72d31de97" value="1"/> <toValue xsi:type="type:EnumerateValue" name="AMD64"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.10"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/9c154d9a-fab9-4507-a3d7-21b72d31de97" value="1"/> <toValue xsi:type="type:StringsValue" value="ubuntu"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="RegionOne/9c154d9a-fab9-4507-a3d7-21b72d31de97_Constraint_Mapping_LOCATION" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.1"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.1/@attributes.0"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/9c154d9a-fab9-4507-a3d7-21b72d31de97" value="1"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938_Constraint_Mapping_OS_CREDENTIALS" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.0"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.1"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938"/> <toValue xsi:type="type:EnumerateValue" name="Windows2012R2_PW_No_Firewall_0.2"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.6"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938"/> <toValue xsi:type="type:EnumerateValue" name="WINDOWS"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.7"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938"/> <toValue xsi:type="type:EnumerateValue" name="AMD64"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.10"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938"/> <toValue xsi:type="type:StringsValue" value="Administrator"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.11"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938"/> <toValue xsi:type="type:StringsValue" value="Admin1"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938_Constraint_Mapping_LOCATION" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.1"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.1/@attributes.0"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.TINY_Constraint_Mapping" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.0"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.2"> <fromValue xsi:type="type:EnumerateValue" name="m1.tiny" value="2"/> <toValue xsi:type="type:IntegerValue" value="512"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.3"> <fromValue xsi:type="type:EnumerateValue" name="m1.tiny" value="2"/> <toValue xsi:type="type:IntegerValue" value="1"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.5"> <fromValue xsi:type="type:EnumerateValue" name="m1.tiny" value="2"/> <toValue xsi:type="type:IntegerValue" value="1"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.8"> <fromValue xsi:type="type:EnumerateValue" name="m1.tiny" value="2"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne/1" value="2"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.MEDIUM_Constraint_Mapping" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.0"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.2"> <fromValue xsi:type="type:EnumerateValue" name="m1.medium" value="3"/> <toValue xsi:type="type:IntegerValue" value="4096"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.3"> <fromValue xsi:type="type:EnumerateValue" name="m1.medium" value="3"/> <toValue xsi:type="type:IntegerValue" value="2"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.5"> <fromValue xsi:type="type:EnumerateValue" name="m1.medium" value="3"/> <toValue xsi:type="type:IntegerValue" value="40"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.8"> <fromValue xsi:type="type:EnumerateValue" name="m1.medium" value="3"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne/3" value="3"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.XLARGE_Constraint_Mapping" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.0"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.2"> <fromValue xsi:type="type:EnumerateValue" name="m1.xlarge" value="4"/> <toValue xsi:type="type:IntegerValue" value="16384"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.3"> <fromValue xsi:type="type:EnumerateValue" name="m1.xlarge" value="4"/> <toValue xsi:type="type:IntegerValue" value="8"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.5"> <fromValue xsi:type="type:EnumerateValue" name="m1.xlarge" value="4"/> <toValue xsi:type="type:IntegerValue" value="160"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.8"> <fromValue xsi:type="type:EnumerateValue" name="m1.xlarge" value="4"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne/5" value="4"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.SMALL_Constraint_Mapping_LOCATION" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.1"> <attributeConstraints name="" from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.1/@attributes.0"> <fromValue xsi:type="type:EnumerateValue" name="m1.small"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.LARGE_Constraint_Mapping_LOCATION" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.1"> <attributeConstraints name="" from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.1/@attributes.0"> <fromValue xsi:type="type:EnumerateValue" name="m1.large" value="1"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.TINY_Constraint_Mapping_LOCATION" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.1"> <attributeConstraints name="" from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.1/@attributes.0"> <fromValue xsi:type="type:EnumerateValue" name="m1.tiny" value="2"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.MEDIUM_Constraint_Mapping_LOCATION" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.1"> <attributeConstraints name="" from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.1/@attributes.0"> <fromValue xsi:type="type:EnumerateValue" name="m1.medium" value="3"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.XLARGE_Constraint_Mapping_LOCATION" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.1"> <attributeConstraints name="" from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.1/@attributes.0"> <fromValue xsi:type="type:EnumerateValue" name="m1.xlarge" value="4"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne"/> </attributeConstraints> </constraints> <rootFeature name="Omistack"> <attributes name="DeploymentModel" valueType="//@typeModels.0/@dataTypes.4"> <value xsi:type="type:StringsValue" value="Private"/> </attributes> <attributes name="ServiceModel" valueType="//@typeModels.0/@dataTypes.4"> <value xsi:type="type:StringsValue" value="IaaS"/> </attributes> <attributes name="Availability" valueType="//@typeModels.0/@dataTypes.4" unitType="PERCENTAGE"> <value xsi:type="type:StringsValue" value="95"/> </attributes> <attributes name="Driver" valueType="//@typeModels.0/@dataTypes.4"> <value xsi:type="type:StringsValue" value="openstack-nova"/> </attributes> <attributes name="EndPoint" valueType="//@typeModels.0/@dataTypes.4"> <value xsi:type="type:StringsValue" value="http://omistack-beta.e-technik.uni-ulm.de:5000/v2.0"/> </attributes> <attributes name="Name" valueType="//@typeModels.0/@dataTypes.4"> <value xsi:type="type:StringsValue" value="omistack"/> </attributes> <subFeatures name="VM"> <attributes name="VMType" valueType="//@typeModels.0/@dataTypes.10"/> <attributes name="VMOS" valueType="//@typeModels.0/@dataTypes.1"/> <attributes name="VMMemory" valueType="//@typeModels.0/@dataTypes.6" unitType="MEGABYTES"/> <attributes name="VMCores" valueType="//@typeModels.0/@dataTypes.11"/> <attributes name="CostPerHour" valueType="//@typeModels.0/@dataTypes.3"/> <attributes name="VMStorage" valueType="//@typeModels.0/@dataTypes.5" unitType="GIGABYTES"/> <attributes name="OSVendorType" valueType="//@typeModels.0/@dataTypes.7"/> <attributes name="OSArchitecture" valueType="//@typeModels.0/@dataTypes.8"/> <attributes name="VMTypeCloudProviderId" valueType="//@typeModels.0/@dataTypes.0"/> <attributes name="VMImageId" valueType="//@typeModels.0/@dataTypes.2"/> <attributes name="DefaultLoginName" valueType="//@typeModels.0/@dataTypes.12"/> <attributes name="DefaultLoginPassword" valueType="//@typeModels.0/@dataTypes.13"/> <featureCardinality cardinalityMin="1" cardinalityMax="8"/> </subFeatures> <subFeatures name="Location"> <attributes name="LocationId" valueType="//@typeModels.0/@dataTypes.9"/> <attributes name="Longitude"> <value xsi:type="type:FloatsValue" value="9.96291"/> </attributes> <attributes name="Latitude"> <value xsi:type="type:FloatsValue" value="48.42599"/> </attributes> <subFeatures name="EU"> <subFeatures name="Germany"> <subFeatures name="Ulm"> <featureCardinality cardinalityMin="1" cardinalityMax="1"/> </subFeatures> <featureCardinality cardinalityMin="1" cardinalityMax="1"/> </subFeatures> <featureCardinality cardinalityMin="1" cardinalityMax="1"/> </subFeatures> <featureCardinality cardinalityMin="1" cardinalityMax="1" value="1"/> </subFeatures> <featureCardinality cardinalityMin="1" cardinalityMax="1"/> </rootFeature> </providerModels> <requirementModels name="ChristmasCardSendingRequirement"> <requirements xsi:type="requirement:InternalComponentRequirement" name="TomcatBetweenSevenAndEight" minVersion="7.0" minVersionIncluded="true" maxVersion="8.0" maxVersionIncluded="true"/> <requirements xsi:type="requirement:PaaSRequirement" name="CardDesignerPaaSRequirement"> <pricingTypes>METERED</pricingTypes> <statusTypes>PRODUCTION</statusTypes> <runtimeTypes>JAVA</runtimeTypes> </requirements> <requirements xsi:type="requirement:OSRequirement" name="UbuntuRequirement" os="ubuntu"/> <requirements xsi:type="requirement:QuantitativeHardwareRequirement" name="CardDesignerHWRequirement" minCPU="1.0" minCores="2" minRAM="4096" minStorage="20"/> <requirements xsi:type="requirement:LocationRequirement" name="EuropeLocationRequirement" locations="//@locationModels.0/@regions.0"/> <requirements xsi:type="requirement:QuantitativeHardwareRequirement" name="EmailServiceHWRequirement" minCPU="1.0" minCores="4" minRAM="8192" minStorage="40"/> <requirements xsi:type="requirement:ServiceLevelObjective" name="RTLeqSixtySLO" customServiceLevel="//@metricModels.0/@conditions.0"/> </requirementModels> <adaptationModels name="ChristmasCardSendingAdaptation"> <rules name="Replace" event="//@adaptationModels.0/@events.0" task="//@adaptationModels.0/@tasks.0" entity="//@organisationModels.0/@organisation"/> <events xsi:type="adaptation:NonFunctionalEvent" name="ViolRTCondition" metricCondition="//@metricModels.0/@conditions.0" isViolation="true"/> <tasks xsi:type="adaptation:ServiceReplacement" name="ReplaceEmailService" previousService="//@deploymentModels.0/@internalComponents.1"/> </adaptationModels> <typeModels name="OmistackType"> <dataTypes xsi:type="type:Enumeration" name="VMTypeCloudProviderIdEnum"> <values name="RegionOne/2"/> <values name="RegionOne/4" value="1"/> <values name="RegionOne/1" value="2"/> <values name="RegionOne/3" value="3"/> <values name="RegionOne/5" value="4"/> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="VMOsEnum"> <values name="Ubuntu Server 14.04.2 AMD64 LTS"/> <values name="Windows2012R2_PW_No_Firewall_0.2" value="1"/> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="VMImageIdEnum"> <values name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938"/> <values name="RegionOne/9c154d9a-fab9-4507-a3d7-21b72d31de97" value="1"/> </dataTypes> <dataTypes xsi:type="type:Range" name="CostRange" primitiveType="DoubleType"> <lowerLimit included="true"> <value xsi:type="type:DoublePrecisionValue" value="0.054"/> </lowerLimit> <upperLimit included="true"> <value xsi:type="type:DoublePrecisionValue" value="0.095"/> </upperLimit> </dataTypes> <dataTypes xsi:type="type:StringValueType" name="StringValueType" primitiveType="StringType"/> <dataTypes xsi:type="type:List" name="StorageList"> <values xsi:type="type:IntegerValue" value="20"/> <values xsi:type="type:IntegerValue" value="80"/> <values xsi:type="type:IntegerValue" value="1"/> <values xsi:type="type:IntegerValue" value="40"/> <values xsi:type="type:IntegerValue" value="160"/> </dataTypes> <dataTypes xsi:type="type:List" name="MemoryList"> <values xsi:type="type:IntegerValue" value="2048"/> <values xsi:type="type:IntegerValue" value="8192"/> <values xsi:type="type:IntegerValue" value="512"/> <values xsi:type="type:IntegerValue" value="4096"/> <values xsi:type="type:IntegerValue" value="16384"/> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="OSVendorType"> <values name="WINDOWS"/> <values name="UNIX" value="1"/> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="OSArchitectureType"> <values name="AMD64"/> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="LocationIdType"> <values name="RegionOne"/> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="VMTypeEnumeration"> <values name="m1.small"/> <values name="m1.large" value="1"/> <values name="m1.tiny" value="2"/> <values name="m1.medium" value="3"/> <values name="m1.xlarge" value="4"/> </dataTypes> <dataTypes xsi:type="type:List" name="CoresList"> <values xsi:type="type:IntegerValue" value="1"/> <values xsi:type="type:IntegerValue" value="2"/> <values xsi:type="type:IntegerValue" value="4"/> <values xsi:type="type:IntegerValue" value="8"/> </dataTypes> <dataTypes xsi:type="type:List" name="LoginNameList" primitiveType="StringType"> <values xsi:type="type:StringsValue" value="Administrator"/> <values xsi:type="type:StringsValue" value="ubuntu"/> </dataTypes> <dataTypes xsi:type="type:List" name="LoginPasswordList" primitiveType="StringType"> <values xsi:type="type:StringsValue" value="Admin1"/> </dataTypes> </typeModels> <unitModels name="ChristmasCardSendingUnit"> <units xsi:type="unit:TimeIntervalUnit" name="Seconds" unit="SECONDS"/> <units xsi:type="unit:TransactionUnit" name="CapacityUnit" unit="TRANSACTIONS"/> </unitModels>

</camel:CamelModel>

Cloud Bursting 1.0

2016-12-24T04:23:53Z

<?xml version="1.0" encoding="ASCII"?> <camel:CamelModel

 xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:adaptation="http://www.cloudsocket.eu/2016/05/camel/adaptation" xmlns:camel="http://www.cloudsocket.eu/2016/05/camel" xmlns:deployment="http://www.cloudsocket.eu/2016/05/camel/deployment" xmlns:metric="http://www.cloudsocket.eu/2016/05/camel/metric" xmlns:provider="http://www.cloudsocket.eu/2016/05/camel/provider" xmlns:requirement="http://www.cloudsocket.eu/2016/05/camel/requirement" xmlns:type="http://www.cloudsocket.eu/2016/05/camel/type" xmlns:unit="http://www.cloudsocket.eu/2016/05/camel/unit" xsi:schemaLocation="http://www.cloudsocket.eu/2016/05/camel/adaptation camel.ecore#//adaptation http://www.cloudsocket.eu/2016/05/camel camel.ecore http://www.cloudsocket.eu/2016/05/camel/deployment camel.ecore#//deployment http://www.cloudsocket.eu/2016/05/camel/metric camel.ecore#//metric http://www.cloudsocket.eu/2016/05/camel/provider camel.ecore#//provider http://www.cloudsocket.eu/2016/05/camel/requirement camel.ecore#//requirement http://www.cloudsocket.eu/2016/05/camel/type camel.ecore#//type http://www.cloudsocket.eu/2016/05/camel/unit camel.ecore#//unit" name="ChristmasCardSendingModel"> <applications name="ChristmasCardSending" version="1.0" owner="//@organisationModels.0/@organisation"/> <deploymentModels name="ChristmasCardSendingDeployment" globalVMRequirementSet="//@deploymentModels.0/@vmRequirementSets.1"> <internalComponents xsi:type="deployment:InternalServiceComponent" name="CardDesigner" type="SERVLET" serviceType="REST"> <configurations xsi:type="deployment:ScriptConfiguration" name="CardDesignerConfiguration" downloadCommand="'sudo apt-get install -y curl'" installCommand="'curl -o demoapp_install_ubuntu.sh https://omi-gitlab.e-technik.uni-ulm.de/cloudsocket/prototype_v1_files/raw/master/demoapp_install_ubuntu.sh && chmod +x demoapp_install_ubuntu.sh && ./demoapp_install_ubuntu.sh'" startCommand="'/apache-tomcat-7.0.65/bin/catalina.sh run'" os="Ubuntu"/> <requiredHost name="CardDesignerRequiredHost"/> <workflowTaskIDs>sid-1C5E88D8-C7E3-4FAC-85E5-FAD80099C28B</workflowTaskIDs> <workflowTaskIDs>sid-D891CCD3-40B6-4555-9C84-81BECCDCB1C2</workflowTaskIDs> <workflowTaskIDs>sid-B99151C2-9914-4E71-9540-9DFE38334B7B</workflowTaskIDs> </internalComponents> <internalComponents xsi:type="deployment:InternalServiceComponent" name="EmailService" type="SERVLET"> <requiredHost name="EmailServiceRequiredHost"/> <workflowTaskIDs>sid-A952A4DD-CED9-440F-82FC-A6DE0568780A</workflowTaskIDs> </internalComponents> <internalComponentInstances xsi:type="deployment:InternalServiceComponentInstance" name="CardDesignerInstance" type="//@deploymentModels.0/@internalComponents.0" endpoint="http://localhost:8080/demo-app-1.0/services/cardDesigner"> <requiredHostInstance name="CardDesignerInstanceRequiredHost" type="//@deploymentModels.0/@internalComponents.0/@requiredHost"/> </internalComponentInstances> <internalComponentInstances xsi:type="deployment:InternalServiceComponentInstance" name="EmailServiceInstance" type="//@deploymentModels.0/@internalComponents.1" endpoint="http://localhost:8080/service/wsdl/ZimbraService.wsdl"> <requiredHostInstance name="EmailInstanceRequiredHost" type="//@deploymentModels.0/@internalComponents.1/@requiredHost"/> </internalComponentInstances> <vms name="CardDesignerVM" vmRequirementSet="//@deploymentModels.0/@vmRequirementSets.0"> <providedHosts name="CardDesignerVMProvidedHost"/> </vms> <vms name="EmailServiceVM"> <providedHosts name="EmailServiceProvidedHost"/> </vms> <vms name="EmailServicePublicVM" vmRequirementSet="//@deploymentModels.0/@vmRequirementSets.3"> <providedHosts name="EmailServicePublicVMProvidedHost"/> </vms> <vmInstances name="CardDesignerVMInstance" type="//@deploymentModels.0/@vms.0" vmType="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" vmTypeValue="//@typeModels.0/@dataTypes.10/@values.3"> <providedHostInstances name="CardDesignerVMInstanceProvidedHost" type="//@deploymentModels.0/@vms.0/@providedHosts.0"/> </vmInstances> <vmInstances name="EmailServicePrivateVMInstance" type="//@deploymentModels.0/@vms.1" vmType="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" vmTypeValue="//@typeModels.0/@dataTypes.10/@values.1"> <providedHostInstances name="EmailServicePrivateVMInstanceProvidedHost" type="//@deploymentModels.0/@vms.1/@providedHosts.0"/> </vmInstances> <hostings name="CardDesignerToVM" providedHost="//@deploymentModels.0/@vms.0/@providedHosts.0" requiredHost="//@deploymentModels.0/@internalComponents.0/@requiredHost"/> <hostings name="EmailServiceToVM" providedHost="//@deploymentModels.0/@vms.1/@providedHosts.0" requiredHost="//@deploymentModels.0/@internalComponents.1/@requiredHost"/> <hostingInstances name="CardDesignerInstanceToVMInstance" type="//@deploymentModels.0/@hostings.0" providedHostInstance="//@deploymentModels.0/@vmInstances.0/@providedHostInstances.0" requiredHostInstance="//@deploymentModels.0/@internalComponentInstances.0/@requiredHostInstance"/> <hostingInstances name="EmailServiceInstanceToVMInstance" type="//@deploymentModels.0/@hostings.1" providedHostInstance="//@deploymentModels.0/@vmInstances.1/@providedHostInstances.0" requiredHostInstance="//@deploymentModels.0/@internalComponentInstances.1/@requiredHostInstance"/> <vmRequirementSets name="CardDesignerVMRequirementSet" quantitativeHardwareRequirement="//@requirementModels.0/@requirements.3"/> <vmRequirementSets name="GlobalVMRequirementSet" locationRequirement="//@requirementModels.0/@requirements.4" osOrImageRequirement="//@requirementModels.0/@requirements.2"/> <vmRequirementSets name="EmailServiceVMRequirementSet" quantitativeHardwareRequirement="//@requirementModels.0/@requirements.5"/> <vmRequirementSets name="EmailServicePublicVMRequirementSet" providerRequirement="//@requirementModels.0/@requirements.6" quantitativeHardwareRequirement="//@requirementModels.0/@requirements.5"/> </deploymentModels> <locationModels name="ChristmasCardSendingLocation"> <regions id="EU" name="Europe"/> </locationModels> <metricModels name="ChristmasCardSendingMetric"> <contexts xsi:type="metric:RawMetricContext" name="RawResponseTimeContext" component="//@deploymentModels.0/@internalComponents.1" application="//@applications.0" metric="//@metricModels.0/@metrics.0" sensor="//@metricModels.0/@sensors.0"/> <contexts xsi:type="metric:RawMetricContext" name="CapacityContext" application="//@applications.0" metric="//@metricModels.0/@metrics.1" sensor="//@metricModels.0/@sensors.1"/> <metrics xsi:type="metric:RawMetric" name="RawResponseTime" unit="//@unitModels.0/@units.0" property="//@metricModels.0/@properties.0"/> <metrics xsi:type="metric:RawMetric" name="CapacityMetric" unit="//@unitModels.0/@units.1" layer="IaaS" property="//@metricModels.0/@properties.1"/> <conditions xsi:type="metric:MetricCondition" name="RTLeqTwenty" comparisonOperator="LESS_EQUAL_THAN" threshold="20.0" metricContext="//@metricModels.0/@contexts.0"/> <conditions xsi:type="metric:MetricCondition" name="CapacityEqZero" comparisonOperator="EQUAL" metricContext="//@metricModels.0/@contexts.1"/> <properties name="ResponseTime" type="MEASURABLE"/> <properties name="Capacity" type="MEASURABLE"/> <sensors name="ResponseTimeSensor"/> <sensors name="CapacitySensor"/> </metricModels> <organisationModels name="BrokerOrganisation"> <organisation name="Broker" email="info@broker.com"/> </organisationModels> <providerModels name="OmistackProvider"> <constraints xsi:type="provider:Implies" name="M1.SMALL_Constraint_Mapping" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.0"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.2"> <fromValue xsi:type="type:EnumerateValue" name="m1.small"/> <toValue xsi:type="type:IntegerValue" value="2048"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.3"> <fromValue xsi:type="type:EnumerateValue" name="m1.small"/> <toValue xsi:type="type:IntegerValue" value="1"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.5"> <fromValue xsi:type="type:EnumerateValue" name="m1.small"/> <toValue xsi:type="type:IntegerValue" value="20"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.8"> <fromValue xsi:type="type:EnumerateValue" name="m1.small"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne/2"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.LARGE_Constraint_Mapping" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.0"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.2"> <fromValue xsi:type="type:EnumerateValue" name="m1.large" value="1"/> <toValue xsi:type="type:IntegerValue" value="8192"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.3"> <fromValue xsi:type="type:EnumerateValue" name="m1.large" value="1"/> <toValue xsi:type="type:IntegerValue" value="4"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.5"> <fromValue xsi:type="type:EnumerateValue" name="m1.large" value="1"/> <toValue xsi:type="type:IntegerValue" value="80"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.8"> <fromValue xsi:type="type:EnumerateValue" name="m1.large" value="1"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne/4" value="1"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="RegionOne/9c154d9a-fab9-4507-a3d7-21b72d31de97_Constraint_Mapping_OS_CREDENTIALS" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.0"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.1"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/9c154d9a-fab9-4507-a3d7-21b72d31de97" value="1"/> <toValue xsi:type="type:EnumerateValue" name="Ubuntu Server 14.04.2 AMD64 LTS"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.6"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/9c154d9a-fab9-4507-a3d7-21b72d31de97" value="1"/> <toValue xsi:type="type:EnumerateValue" name="UNIX" value="1"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.7"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/9c154d9a-fab9-4507-a3d7-21b72d31de97" value="1"/> <toValue xsi:type="type:EnumerateValue" name="AMD64"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.10"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/9c154d9a-fab9-4507-a3d7-21b72d31de97" value="1"/> <toValue xsi:type="type:StringsValue" value="ubuntu"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="RegionOne/9c154d9a-fab9-4507-a3d7-21b72d31de97_Constraint_Mapping_LOCATION" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.1"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.1/@attributes.0"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/9c154d9a-fab9-4507-a3d7-21b72d31de97" value="1"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938_Constraint_Mapping_OS_CREDENTIALS" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.0"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.1"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938"/> <toValue xsi:type="type:EnumerateValue" name="Windows2012R2_PW_No_Firewall_0.2"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.6"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938"/> <toValue xsi:type="type:EnumerateValue" name="WINDOWS"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.7"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938"/> <toValue xsi:type="type:EnumerateValue" name="AMD64"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.10"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938"/> <toValue xsi:type="type:StringsValue" value="Administrator"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.11"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938"/> <toValue xsi:type="type:StringsValue" value="Admin1"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938_Constraint_Mapping_LOCATION" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.1"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.9" to="//@providerModels.0/@rootFeature/@subFeatures.1/@attributes.0"> <fromValue xsi:type="type:EnumerateValue" name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.TINY_Constraint_Mapping" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.0"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.2"> <fromValue xsi:type="type:EnumerateValue" name="m1.tiny" value="2"/> <toValue xsi:type="type:IntegerValue" value="512"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.3"> <fromValue xsi:type="type:EnumerateValue" name="m1.tiny" value="2"/> <toValue xsi:type="type:IntegerValue" value="1"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.5"> <fromValue xsi:type="type:EnumerateValue" name="m1.tiny" value="2"/> <toValue xsi:type="type:IntegerValue" value="1"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.8"> <fromValue xsi:type="type:EnumerateValue" name="m1.tiny" value="2"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne/1" value="2"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.MEDIUM_Constraint_Mapping" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.0"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.2"> <fromValue xsi:type="type:EnumerateValue" name="m1.medium" value="3"/> <toValue xsi:type="type:IntegerValue" value="4096"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.3"> <fromValue xsi:type="type:EnumerateValue" name="m1.medium" value="3"/> <toValue xsi:type="type:IntegerValue" value="2"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.5"> <fromValue xsi:type="type:EnumerateValue" name="m1.medium" value="3"/> <toValue xsi:type="type:IntegerValue" value="40"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.8"> <fromValue xsi:type="type:EnumerateValue" name="m1.medium" value="3"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne/3" value="3"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.XLARGE_Constraint_Mapping" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.0"> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.2"> <fromValue xsi:type="type:EnumerateValue" name="m1.xlarge" value="4"/> <toValue xsi:type="type:IntegerValue" value="16384"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.3"> <fromValue xsi:type="type:EnumerateValue" name="m1.xlarge" value="4"/> <toValue xsi:type="type:IntegerValue" value="8"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.5"> <fromValue xsi:type="type:EnumerateValue" name="m1.xlarge" value="4"/> <toValue xsi:type="type:IntegerValue" value="160"/> </attributeConstraints> <attributeConstraints from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.8"> <fromValue xsi:type="type:EnumerateValue" name="m1.xlarge" value="4"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne/5" value="4"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.SMALL_Constraint_Mapping_LOCATION" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.1"> <attributeConstraints name="" from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.1/@attributes.0"> <fromValue xsi:type="type:EnumerateValue" name="m1.small"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.LARGE_Constraint_Mapping_LOCATION" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.1"> <attributeConstraints name="" from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.1/@attributes.0"> <fromValue xsi:type="type:EnumerateValue" name="m1.large" value="1"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.TINY_Constraint_Mapping_LOCATION" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.1"> <attributeConstraints name="" from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.1/@attributes.0"> <fromValue xsi:type="type:EnumerateValue" name="m1.tiny" value="2"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.MEDIUM_Constraint_Mapping_LOCATION" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.1"> <attributeConstraints name="" from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.1/@attributes.0"> <fromValue xsi:type="type:EnumerateValue" name="m1.medium" value="3"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne"/> </attributeConstraints> </constraints> <constraints xsi:type="provider:Implies" name="M1.XLARGE_Constraint_Mapping_LOCATION" from="//@providerModels.0/@rootFeature/@subFeatures.0" to="//@providerModels.0/@rootFeature/@subFeatures.1"> <attributeConstraints name="" from="//@providerModels.0/@rootFeature/@subFeatures.0/@attributes.0" to="//@providerModels.0/@rootFeature/@subFeatures.1/@attributes.0"> <fromValue xsi:type="type:EnumerateValue" name="m1.xlarge" value="4"/> <toValue xsi:type="type:EnumerateValue" name="RegionOne"/> </attributeConstraints> </constraints> <rootFeature name="Omistack"> <attributes name="DeploymentModel" valueType="//@typeModels.0/@dataTypes.4"> <value xsi:type="type:StringsValue" value="Private"/> </attributes> <attributes name="ServiceModel" valueType="//@typeModels.0/@dataTypes.4"> <value xsi:type="type:StringsValue" value="IaaS"/> </attributes> <attributes name="Availability" valueType="//@typeModels.0/@dataTypes.4" unitType="PERCENTAGE"> <value xsi:type="type:StringsValue" value="95"/> </attributes> <attributes name="Driver" valueType="//@typeModels.0/@dataTypes.4"> <value xsi:type="type:StringsValue" value="openstack-nova"/> </attributes> <attributes name="EndPoint" valueType="//@typeModels.0/@dataTypes.4"> <value xsi:type="type:StringsValue" value="http://omistack-beta.e-technik.uni-ulm.de:5000/v2.0"/> </attributes> <attributes name="Name" valueType="//@typeModels.0/@dataTypes.4"> <value xsi:type="type:StringsValue" value="omistack"/> </attributes> <subFeatures name="VM"> <attributes name="VMType" valueType="//@typeModels.0/@dataTypes.10"/> <attributes name="VMOS" valueType="//@typeModels.0/@dataTypes.1"/> <attributes name="VMMemory" valueType="//@typeModels.0/@dataTypes.6" unitType="MEGABYTES"/> <attributes name="VMCores" valueType="//@typeModels.0/@dataTypes.11"/> <attributes name="CostPerHour" valueType="//@typeModels.0/@dataTypes.3"/> <attributes name="VMStorage" valueType="//@typeModels.0/@dataTypes.5" unitType="GIGABYTES"/> <attributes name="OSVendorType" valueType="//@typeModels.0/@dataTypes.7"/> <attributes name="OSArchitecture" valueType="//@typeModels.0/@dataTypes.8"/> <attributes name="VMTypeCloudProviderId" valueType="//@typeModels.0/@dataTypes.0"/> <attributes name="VMImageId" valueType="//@typeModels.0/@dataTypes.2"/> <attributes name="DefaultLoginName" valueType="//@typeModels.0/@dataTypes.12"/> <attributes name="DefaultLoginPassword" valueType="//@typeModels.0/@dataTypes.13"/> <featureCardinality cardinalityMin="1" cardinalityMax="8"/> </subFeatures> <subFeatures name="Location"> <attributes name="LocationId" valueType="//@typeModels.0/@dataTypes.9"/> <attributes name="Longitude"> <value xsi:type="type:FloatsValue" value="9.96291"/> </attributes> <attributes name="Latitude"> <value xsi:type="type:FloatsValue" value="48.42599"/> </attributes> <subFeatures name="EU"> <subFeatures name="Germany"> <subFeatures name="Ulm"> <featureCardinality cardinalityMin="1" cardinalityMax="1"/> </subFeatures> <featureCardinality cardinalityMin="1" cardinalityMax="1"/> </subFeatures> <featureCardinality cardinalityMin="1" cardinalityMax="1"/> </subFeatures> <featureCardinality cardinalityMin="1" cardinalityMax="1" value="1"/> </subFeatures> <featureCardinality cardinalityMin="1" cardinalityMax="1"/> </rootFeature> </providerModels> <requirementModels name="ChristmasCardSendingRequirement"> <requirements xsi:type="requirement:InternalComponentRequirement" name="TomcatBetweenSevenAndEight" minVersion="7.0" minVersionIncluded="true" maxVersion="8.0" maxVersionIncluded="true"/> <requirements xsi:type="requirement:PaaSRequirement" name="CardDesignerPaaSRequirement"> <pricingTypes>METERED</pricingTypes> <statusTypes>PRODUCTION</statusTypes> <runtimeTypes>JAVA</runtimeTypes> </requirements> <requirements xsi:type="requirement:OSRequirement" name="UbuntuRequirement" os="ubuntu"/> <requirements xsi:type="requirement:QuantitativeHardwareRequirement" name="CardDesignerHWRequirement" minCPU="1.0" minCores="2" minRAM="4096" minStorage="20"/> <requirements xsi:type="requirement:LocationRequirement" name="EuropeLocationRequirement" locations="//@locationModels.0/@regions.0"/> <requirements xsi:type="requirement:QuantitativeHardwareRequirement" name="EmailServiceHWRequirement" minCPU="1.0" minCores="4" minRAM="8192" minStorage="40"/> <requirements xsi:type="requirement:ProviderRequirement" name="PublicProvider"/> <requirements xsi:type="requirement:ServiceLevelObjective" name="RTLeqTwentySLO" customServiceLevel="//@metricModels.0/@conditions.0"/> </requirementModels> <adaptationModels name="ChristmasCardSendingAdaptation"> <rules name="BURST" event="//@adaptationModels.0/@events.2" task="//@adaptationModels.0/@tasks.0" entity="//@organisationModels.0/@organisation"/> <events xsi:type="adaptation:NonFunctionalEvent" name="ViolRTCondition" metricCondition="//@metricModels.0/@conditions.0" isViolation="true"/> <events xsi:type="adaptation:NonFunctionalEvent" name="ViolCapacityCondition" metricCondition="//@metricModels.0/@conditions.1" isViolation="true"/> <events xsi:type="adaptation:BinaryEventPattern" name="BurstEventPattern" leftEvent="//@adaptationModels.0/@events.0" rightEvent="//@adaptationModels.0/@events.1"/> <tasks xsi:type="adaptation:ComponentDeployment" name="EmailServiceOnPublicCloud" components="//@deploymentModels.0/@internalComponents.1" vm="//@deploymentModels.0/@vms.2"/> </adaptationModels> <typeModels name="OmistackType"> <dataTypes xsi:type="type:Enumeration" name="VMTypeCloudProviderIdEnum"> <values name="RegionOne/2"/> <values name="RegionOne/4" value="1"/> <values name="RegionOne/1" value="2"/> <values name="RegionOne/3" value="3"/> <values name="RegionOne/5" value="4"/> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="VMOsEnum"> <values name="Ubuntu Server 14.04.2 AMD64 LTS"/> <values name="Windows2012R2_PW_No_Firewall_0.2" value="1"/> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="VMImageIdEnum"> <values name="RegionOne/11a845d0-7ed3-48c8-a36a-9a76a2fe4938"/> <values name="RegionOne/9c154d9a-fab9-4507-a3d7-21b72d31de97" value="1"/> </dataTypes> <dataTypes xsi:type="type:Range" name="CostRange" primitiveType="DoubleType"> <lowerLimit included="true"> <value xsi:type="type:DoublePrecisionValue" value="0.054"/> </lowerLimit> <upperLimit included="true"> <value xsi:type="type:DoublePrecisionValue" value="0.095"/> </upperLimit> </dataTypes> <dataTypes xsi:type="type:StringValueType" name="StringValueType" primitiveType="StringType"/> <dataTypes xsi:type="type:List" name="StorageList"> <values xsi:type="type:IntegerValue" value="20"/> <values xsi:type="type:IntegerValue" value="80"/> <values xsi:type="type:IntegerValue" value="1"/> <values xsi:type="type:IntegerValue" value="40"/> <values xsi:type="type:IntegerValue" value="160"/> </dataTypes> <dataTypes xsi:type="type:List" name="MemoryList"> <values xsi:type="type:IntegerValue" value="2048"/> <values xsi:type="type:IntegerValue" value="8192"/> <values xsi:type="type:IntegerValue" value="512"/> <values xsi:type="type:IntegerValue" value="4096"/> <values xsi:type="type:IntegerValue" value="16384"/> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="OSVendorType"> <values name="WINDOWS"/> <values name="UNIX" value="1"/> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="OSArchitectureType"> <values name="AMD64"/> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="LocationIdType"> <values name="RegionOne"/> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="VMTypeEnumeration"> <values name="m1.small"/> <values name="m1.large" value="1"/> <values name="m1.tiny" value="2"/> <values name="m1.medium" value="3"/> <values name="m1.xlarge" value="4"/> </dataTypes> <dataTypes xsi:type="type:List" name="CoresList"> <values xsi:type="type:IntegerValue" value="1"/> <values xsi:type="type:IntegerValue" value="2"/> <values xsi:type="type:IntegerValue" value="4"/> <values xsi:type="type:IntegerValue" value="8"/> </dataTypes> <dataTypes xsi:type="type:List" name="LoginNameList" primitiveType="StringType"> <values xsi:type="type:StringsValue" value="Administrator"/> <values xsi:type="type:StringsValue" value="ubuntu"/> </dataTypes> <dataTypes xsi:type="type:List" name="LoginPasswordList" primitiveType="StringType"> <values xsi:type="type:StringsValue" value="Admin1"/> </dataTypes> </typeModels> <unitModels name="ChristmasCardSendingUnit"> <units xsi:type="unit:TimeIntervalUnit" name="Seconds" unit="SECONDS"/> <units xsi:type="unit:TransactionUnit" name="CapacityUnit" unit="TRANSACTIONS"/> </unitModels>

</camel:CamelModel>

PaaS Deployment 1.0

2016-12-24T01:45:01Z

<?xml version="1.0" encoding="ASCII"?>

<camel:CamelModel

xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:camel="http://www.cloudsocket.eu/2016/05/camel" xmlns:deployment="http://www.cloudsocket.eu/2016/05/camel/deployment" xmlns:provider="http://www.cloudsocket.eu/2016/05/camel/provider" xmlns:requirement="http://www.cloudsocket.eu/2016/05/camel/requirement" xmlns:type="http://www.cloudsocket.eu/2016/05/camel/type" xsi:schemaLocation="http://www.cloudsocket.eu/2016/05/camel camel.ecore http://www.cloudsocket.eu/2016/05/camel/deployment camel.ecore#deployment http://www.cloudsocket.eu/2016/05/camel/provider camel.ecore#provider http://www.cloudsocket.eu/2016/05/camel/requirement camel.ecore#requirement http://www.cloudsocket.eu/2016/05/camel/type camel.ecore#type" name="ChristmasCardSendingModel"> <applications name="ChristmasCardSending" version="1.0" owner="@organisationModels.0/@organisation"/> <deploymentModels name="ChristmasCardSendingDeployment"> <internalComponents xsi:type="deployment:InternalServiceComponent" name="CardDesigner" type="SERVLET" serviceType="REST"> <configurations xsi:type="deployment:PaaSConfiguration" name="CardDesignerPaaSConfiguration" api="PUL" version="1.0" endpoint=""/> <requiredHost name="CardDesignerRequiredHost"/> <workflowTaskIDs>sid-1C5E88D8-C7E3-4FAC-85E5-FAD80099C28B</workflowTaskIDs> <workflowTaskIDs>sid-D891CCD3-40B6-4555-9C84-81BECCDCB1C2</workflowTaskIDs> <workflowTaskIDs>sid-B99151C2-9914-4E71-9540-9DFE38334B7B</workflowTaskIDs> </internalComponents> <internalComponents name="tomcat" type="SERVLET_CONTAINER" internalComponentRequirement="@requirementModels.0/@requirements.0"> <providedHosts name="TomcatProvidedHost"/> <requiredHost name="TomcatRequiredHost"/> </internalComponents> <internalComponentInstances xsi:type="deployment:InternalServiceComponentInstance" name="CardDesignerInstance" type="@deploymentModels.0/@internalComponents.0" endpoint="http://localhost:8080/demo-app-1.0/services/cardDesigner"> <requiredHostInstance name="CardDesignerInstanceRequiredHost" type="@deploymentModels.0/@internalComponents.0/@requiredHost"/> </internalComponentInstances> <internalComponentInstances name="TomcatInstance" type="@deploymentModels.0/@internalComponents.1"> <providedHostInstances name="TomcatInstanceProvidedHost" type="@deploymentModels.0/@internalComponents.1/@providedHosts.0"/> <requiredHostInstance name="TomcatInstanceRequiredHost" type="@deploymentModels.0/@internalComponents.1/@requiredHost"/> </internalComponentInstances> <hostings name="TomcatToCardDesigner" providedHost="@deploymentModels.0/@internalComponents.1/@providedHosts.0" requiredHost="@deploymentModels.0/@internalComponents.0/@requiredHost"/> <hostings name="PaaSToTomcat" providedHost="@deploymentModels.0/@paas.0/@providedHosts.0" requiredHost="@deploymentModels.0/@internalComponents.1/@requiredHost"/> <hostingInstances name="PaaSInstanceToTomcatInstance" type="@deploymentModels.0/@hostings.1" providedHostInstance="@deploymentModels.0/@paasInstances.0/@providedHostInstances.0" requiredHostInstance="@deploymentModels.0/@internalComponentInstances.1/@requiredHostInstance"/> <hostingInstances name="TomcatInstanceToCardDesignerInstance" type="@deploymentModels.0/@hostings.0" providedHostInstance="@deploymentModels.0/@internalComponentInstances.1/@providedHostInstances.0" requiredHostInstance="@deploymentModels.0/@internalComponentInstances.0/@requiredHostInstance"/> <vmRequirementSets name="CardDesignerPaaSVMRequirementSet" locationRequirement="@requirementModels.0/@requirements.5" providerRequirement="@requirementModels.0/@requirements.3" quantitativeHardwareRequirement="@requirementModels.0/@requirements.4" osOrImageRequirement="@requirementModels.0/@requirements.2"/> <saas name="EmailService" registryID=""> <workflowTaskIDs>sid-A952A4DD-CED9-440F-82FC-A6DE0568780A</workflowTaskIDs> </saas> <saasInstances name="EmailServiceInstance" type="@deploymentModels.0/@saas.0" serviceType="REST"> <endpoints>https://api.sendgrid.com/api/mail.send.json</endpoints> </saasInstances> <paas name="CardDesignerPaaS" paasRequirementSet="@deploymentModels.0/@paasRequirementSets.0"> <providedHosts name="CardDesignerPaaSHost"/> </paas> <paasInstances name="AtosPaaSInstance" type="@deploymentModels.0/@paas.0" paasFeature="@providerModels.0/@rootFeature/@subFeatures.0"> <providedHostInstances name="AtosPaaSProvidedHost" type="@deploymentModels.0/@paas.0/@providedHosts.0"/> </paasInstances> <paasRequirementSets name="CardDesignerPaaSRequirementSet" vmRequirementSet="@deploymentModels.0/@vmRequirementSets.0" paasRequirement="@requirementModels.0/@requirements.1"/> </deploymentModels> <locationModels name="ChristmasCardSendingLocation"> <regions id="EU" name="Europe"/> </locationModels> <organisationModels name="BrokerOrganisation"> <organisation name="Broker" email="info@broker.com"/> </organisationModels> <providerModels name="ATOSCloudFoundry"> <rootFeature name="ATOSCloud"> <attributes name="DeploymentModel" valueType="@typeModels.0/@dataTypes.0"/> <attributes name="ServiceModel"> <value xsi:type="type:StringsValue" value="PaaS"/> </attributes> <attributes name="Availability" valueType="@typeModels.0/@dataTypes.1" unitType="PERCENTAGE"/> <subFeatures name="PaaS"> <attributes name="Pricing" valueType="@typeModels.0/@dataTypes.6"/> <attributes name="Scaling" valueType="@typeModels.0/@dataTypes.7"/> <attributes name="Location" valueType="@typeModels.0/@dataTypes.8"/> <subFeatures xsi:type="provider:Alternative" name="AddOns"> <featureCardinality cardinalityMax="-1"/> <variants name="CanopyComposeServiceBroker"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <attributes name="addOnType" valueType="@typeModels.0/@dataTypes.5"> <value xsi:type="type:EnumerateValue" name="BROKER"/> </attributes> <featureCardinality cardinalityMax="1"/> </variants> <variants name="DatabaseAdminApp"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <subFeatures name="DatabaseAdminApp"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </subFeatures> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Datadog"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <attributes name="addOnType" valueType="@typeModels.0/@dataTypes.5"> <value xsi:type="type:EnumerateValue" name="MONITORING" value="1"/> </attributes> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Dynatrace"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <attributes name="addOnType" valueType="@typeModels.0/@dataTypes.5"> <value xsi:type="type:EnumerateValue" name="ANALYTICS" value="2"/> </attributes> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Nagios"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <attributes name="addOnType" valueType="@typeModels.0/@dataTypes.5"> <value xsi:type="type:EnumerateValue" name="MONITORING" value="1"/> </attributes> <featureCardinality cardinalityMax="1"/> </variants> <variants name="NewRelic"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <attributes name="addOnType" valueType="@typeModels.0/@dataTypes.5"> <value xsi:type="type:EnumerateValue" name="MONITORING" value="1"/> </attributes> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Pingdom"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <attributes name="addOnType" valueType="@typeModels.0/@dataTypes.5"> <value xsi:type="type:EnumerateValue" name="MONITORING" value="1"/> </attributes> <featureCardinality cardinalityMax="1"/> </variants> </subFeatures> <subFeatures xsi:type="provider:Alternative" name="Services"> <featureCardinality cardinalityMax="-1"/> <variants name="Neo4j"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <attributes name="serviceType" valueType="@typeModels.0/@dataTypes.4"> <value xsi:type="type:EnumerateValue" name="DB"/> </attributes> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Abacus"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <attributes name="serviceType" valueType="@typeModels.0/@dataTypes.4"> <value xsi:type="type:EnumerateValue" name="METERING" value="3"/> </attributes> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Cassandra"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <attributes name="serviceType" valueType="@typeModels.0/@dataTypes.4"> <value xsi:type="type:EnumerateValue" name="DB"/> </attributes> <featureCardinality cardinalityMax="1"/> </variants> <variants name="CouchDB"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <attributes name="serviceType" valueType="@typeModels.0/@dataTypes.4"> <value xsi:type="type:EnumerateValue" name="DB"/> </attributes> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Dingo-postgresql"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <attributes name="serviceType" valueType="@typeModels.0/@dataTypes.4"> <value xsi:type="type:EnumerateValue" name="DB"/> </attributes> <featureCardinality cardinalityMax="1"/> </variants> <variants name="ElasticSearch"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <attributes name="serviceType" valueType="@typeModels.0/@dataTypes.4"> <value xsi:type="type:EnumerateValue" name="SEARCH" value="2"/> </attributes> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Mongodb"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <attributes name="serviceType" valueType="@typeModels.0/@dataTypes.4"> <value xsi:type="type:EnumerateValue" name="DB"/> </attributes> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Mysql"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <attributes name="serviceType" valueType="@typeModels.0/@dataTypes.4"> <value xsi:type="type:EnumerateValue" name="DB"/> </attributes> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Postgresql"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <attributes name="serviceType" valueType="@typeModels.0/@dataTypes.4"> <value xsi:type="type:EnumerateValue" name="DB"/> </attributes> <featureCardinality cardinalityMax="1"/> </variants> <variants name="RabbitMQ"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <attributes name="serviceType" valueType="@typeModels.0/@dataTypes.4"> <value xsi:type="type:EnumerateValue" name="MESSAGE_QUEUE"/> </attributes> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Redis"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <attributes name="serviceType" valueType="@typeModels.0/@dataTypes.4"> <value xsi:type="type:EnumerateValue" name="DB"/> </attributes> <featureCardinality cardinalityMax="1"/> </variants> </subFeatures> <subFeatures xsi:type="provider:Alternative" name="Middleware"> <featureCardinality cardinalityMax="-1"/> <variants name="JBoss"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Tomcat"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Tomee"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> </subFeatures> <subFeatures xsi:type="provider:Alternative" name="Runtimes"> <featureCardinality cardinalityMax="-1"/> <variants name="Java"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Clojure"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="DotNet"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Go"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Groovy"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Node"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="PhP"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Python"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Ruby"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Scala"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Swift"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> </subFeatures> <subFeatures xsi:type="provider:Alternative" name="Frameworks"> <featureCardinality cardinalityMax="-1"/> <variants name="Django"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Grails"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Hhvm"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Play"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Rack"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Sails"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Sinatra"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> <variants name="Spring"> <attributes name="version" valueType="@typeModels.0/@dataTypes.3"/> <featureCardinality cardinalityMax="1"/> </variants> </subFeatures> <featureCardinality cardinalityMin="1" cardinalityMax="1"/> </subFeatures> <featureCardinality cardinalityMin="1" cardinalityMax="1"/> </rootFeature> </providerModels> <requirementModels name="ChristmasCardSendingRequirement"> <requirements xsi:type="requirement:InternalComponentRequirement" name="TomcatBetweenSevenAndEight" minVersion="7.0" minVersionIncluded="true" maxVersion="8.0" maxVersionIncluded="true"/> <requirements xsi:type="requirement:PaaSRequirement" name="CardDesignerPaaSRequirement"> <pricingTypes>METERED</pricingTypes> <statusTypes>PRODUCTION</statusTypes> <runtimeTypes>JAVA</runtimeTypes> </requirements> <requirements xsi:type="requirement:OSRequirement" name="UbuntuRequirement" os="ubuntu"/> <requirements xsi:type="requirement:ProviderRequirement" name="PublicProviderRequirement"/> <requirements xsi:type="requirement:QuantitativeHardwareRequirement" name="CardDesignerHWRequirement" minCPU="1.0" minCores="2" minRAM="4096" minStorage="20"/> <requirements xsi:type="requirement:LocationRequirement" name="EuropeLocationRequirement" locations="@locationModels.0/@regions.0"/> </requirementModels> <typeModels name="ChristmasCardSendingType"> <dataTypes xsi:type="type:Enumeration" name="DeploymentModel"> <values name="PUBLIC"/> <values name="PRIVATE" value="1"/> </dataTypes> <dataTypes xsi:type="type:Range" name="AvailabilityRange" primitiveType="DoubleType"> <lowerLimit included="true"> <value xsi:type="type:DoublePrecisionValue" value="99.9"/> </lowerLimit> <upperLimit> <value xsi:type="type:DoublePrecisionValue" value="100.0"/> </upperLimit> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="RuntimeType"> <values name="JAVA"/> <values name="CLOJURE" value="1"/> <values name="DOTNET" value="2"/> <values name="GO" value="3"/> <values name="GROOVY" value="4"/> <values name="NODE" value="5"/> <values name="PHP" value="6"/> <values name="PYTHON" value="7"/> <values name="RUBY" value="8"/> <values name="SCALA" value="9"/> <values name="SWIFT" value="10"/> </dataTypes> <dataTypes xsi:type="type:List" name="VersionList" primitiveType="StringType"> <values xsi:type="type:StringsValue" value="0."/> <values xsi:type="type:StringsValue" value="."/> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="ServiceType"> <values name="DB"/> <values name="MESSAGE_QUEUE" value="1"/> <values name="SEARCH" value="2"/> <values name="METERING" value="3"/> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="AddOnType"> <values name="BROKER"/> <values name="MONITORING" value="1"/> <values name="ANALYTICS" value="2"/> <values name="APP" value="3"/> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="PricingType"> <values name="METERED"/> <values name="FIXED" value="1"/> <values name="FREE" value="2"/> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="ScalingType"> <values name="HORIZONTAL"/> <values name="VERTICAL" value="1"/> <values name="AUTO" value="2"/> </dataTypes> <dataTypes xsi:type="type:Enumeration" name="LocationType"> <values name="EUROPE"/> <values name="NORTH_AMERICA" value="1"/> <values name="SOUTH_AMERICA" value="2"/> <values name="ASIA" value="3"/> <values name="OCEANIA" value="4"/> </dataTypes> </typeModels>

</camel:CamelModel>

Examples 1.1

2016-12-24T01:43:43Z

This is a collection of example files we use throughout the testing and alignment of components.

CAMEL

PaaS Deployment

Cloud Bursting

Service Replacement

Bundles

Components 1.5

2016-12-24T01:41:22Z

All components will be documented with the following template.

Description Template

Description of the different components included in the environments. Unless the documentation is hosted externally, the components should follow up the next structure:

**Summary**
**Architecture design**
**Installation manual**
- Development
- Production
**Test Cases**
**User Manual**
- API specification
- HandBook

Components by Environment

Design Environment

Allocation Environment

Execution Environment

Evaluation Environment

Marketplace Environment

General Documentation

Source management and branching

Continuous Delivery and Integration Documentation

Examples

Cloud Provider Engine Component 1.4

2016-12-15T11:58:17Z

We use the Cloudiator framework for deploying applications in the Cloud, which is orchestrated by an CAMEL-to-Colosseum-adapter that gets involved when calling the Execution Environment Entrypoint.

Colosseum

This is the entrypoint and API of the Cloudiator suite.

Axe

This component handles aggregation of monitoring data and scaling with respect to scaling rules defined in Colosseum

Lance

Lance is the life-cycle agent that gets installed on every machine and handles the orchestration of component instances and the execution of their respective life-cycle actions.

Visor

Visor is the monitoring agent installed on every machine and capable of executing probes.

Sword

Sword is an abstraction-layer heavily based on jclouds to access each and any cloud infrastructure in a normalized way.

Adaptation Management

The Adaptation Management is the first implementation of the CAMEL-specific enhancements towards describing more complex adaptation plans.

Execution Environment Components 2.2

2016-12-02T13:25:45Z

Overall

The CloudSocket Execution Environment enables managing, monitoring and adapting the execution of the BPaaS bundles generated during the allocation phase, which have been published via the Marketplace. The environment covers the whole steps of execution phase: i) deploy and configure all components required to execute the bundles, which comprise the workflow, SLA, adaptation rules, and details of the third-party services involved; ii) allow to manage the end-user's workflow instances, when a BPaaS workflow bundle has been deployed; iii) visualize the conformance levels to associated agreements and the respective monitoring data; iv) generate and manage the violations incurred as well as trigger the respective BPaaS bundle adaptation rules, allowing the environment to adapt the BPaaS instances to maintain the promised service level.

In order to support the aforementioned capabilities, the BPaaS Execution Environment comprises several components. These components are the following:

Workflow Engine is responsible for deploying the executable workflows and executing the different workflow instances at the execution phase.
Cloud Provider Engine is responsible for the complete deployment and lifecycle management of all the required components of the BPaaS, including software components and VMs across multiple clouds, with transactional semantics (at least for the deployment part).
Monitoring Engine is responsible for cross-level monitoring a BPaaS and correlate/aggregate monitoring data from different levels, from infrastructure and software services up to the level of the workflow.
Adaptation Engine is responsible for the reconfiguration of the BPaaS deployment (e.g., different services, service configurations and workflow structure modification) to resolve the problematic situations identified by adaptation rules.
SLA Engine is responsible for generating, storing and observing the formal documents describing electronic service-level agreements (SLAs) between the parties involved in CloudSocket.
Process Data Mediator is offered as a service to the Adaptation Engine in order to cover the cases where services are substituted and their replacements need to communicate properly with the rest of the services in the execution order of the current BPaaS workflow.

The following figure shows the detailed scheme of the CloudSocket Reference Architecture and the location of the different components.

Internal architecture for the execution environment.

The architecture differentiates between two main levels: (a) one covering the components that have an interaction with the actors through a GUI, such as Web interface for the Workflow Engine, SLA dashboard and Monitoring dashboard and (b) another including the core engines to cover these functionalities. There is another hidden level, the data one which is covered internally by the internal architecture of its component but due to complexity reasons it is not shown in above figure.

The components in each level interact with each other in order to properly deliver and visualise the functionalities of the environment. More information about how these interactions are performed and what are the respective scenarios covered can be found at the following URL:

https://www.cloudsocket.eu/uml/3-ExecutionEnvironment/remotedocu/modeldocu/27012016104208/modelContentHTML in which the corresponding UML diagrams can be viewed. This information was also covered in the D4.1 deliverable. However not all components have been developed, yet. So in the following, the documentation is only available for those components, that are currently available.

Unified PaaS component 1.1

2016-12-02T13:22:58Z

1 Summary
2 Component responsible
3 Architecture design
4 Installation manual
- 4.1 Development
- 4.2 Production
5 User manual
- 5.1 API Specification

Summary

[description]

This component will expose:

REST API
Library

The main functionalities are:

Unified application deployment on Heroku, OpenShift, CloudFoundry
...

Type of ownership	Extension & Adaptation
Original tool	Unified PaaS Library
Planned OS license	Apache License Version 2.0.
Reference community	None

Consist of

Library
REST Service
REST Client

Depends on

External PaaS providers

Component responsible

Developer	Email	Company
Roman Sosa Gonzalez	roman.sosa@atos.net	Atos
Joaquin Iranzo	Joaquin.iranzo@atos.net	Atos

Architecture design

[architecture]

Figure: General architecture for Unified PaaS component

Installation manual

Development

Requirements

Oracle JDK >= 1.7
Maven >= 3.2

Installation

Download source code from gitlab

 git clone https://omi-gitlab.e-technik.uni-ulm.de/cloudsocket/unified-paas.git cd unified-paas

Compile
```
 mvn clean install 
```
Execute server. The following command will start a server in port 8002.
```
 cd service; bin/runserver.sh 
```

Configuration file (port, logging, etc) in service/conf/config.yml.

Production

Requirements

Oracle JRE >= 1.7

Installation

The script `dist/bin/make-dist.sh` creates an archive file with the necessary scripts and artifacts to run the Unified PaaS service in a server.

 dist/bin/make-dist.sh scp dist/target/paas-unified.zip server: # replace 'server' with the ip/name of server ssh server: unzip paas-unified.zip -d paas-unified-server cd paas-unified-pserver bin/start-paas-unified-service.sh

To stop the service:

 bin/stop-paas-unified-service.sh

To update an instance, just copy the unified-paas-service.jar to paas-unified-server/bin directory.