Analysis of the State of the Art and Definition of Requirements … · 2017-04-20 · contained in the blueprint repository Scenario Evaluation results / feedback Plans for future

Copyright © SAP and all other members of the 4CaaSt consortium 2010 Page 1

Building the PaaS Cloud of the Future

Analysis of the State of the Art and Definition of Requirements

D1.1.3 (b)

Version 1.0

WP1 – Definition of Requirements, Conceptual Model and Reference Architecture and Integration

Dissemination Level: Public

Lead Editor: Christof Momm

27/07/2012

Status: Final

The research leading to these results has received funding from the European Union's Seventh Framework Programme (FP7/2007-2013) under grant agreement n° 258862

Seventh Framework Programme

FP7-ICT-2009-5

Service and Software Architectures, Infrastructures and Engineering


This is a public deliverable that is provided to the community under a Creative Commons Attribution 3.0 Unported License: http://creativecommons.org/licenses/by/3.0/

You are free:

to Share — to copy, distribute and transmit the work

to Remix — to adapt the work

Under the following conditions:

Attribution — You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).

With the understanding that:

Waiver — Any of the above conditions can be waived if you get permission from the copyright holder.

Public Domain — Where the work or any of its elements is in the public domain under applicable law, that status is in no way affected by the license.

Other Rights — In no way are any of the following rights affected by the license:

Your fair dealing or fair use rights, or other applicable copyright exceptions and limitations;

The author's moral rights;

Rights other persons may have either in the work itself or in how the work is used, such as publicity or privacy rights.

Notice — For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do this is with a link to this Web page.

For a full description of the license legal terms, please refer to:

http://creativecommons.org/licenses/by/3.0/legalcode


Contributors:

Vasilios Andrikopoulos (USTUTT)

Pablo Arozarena (TID)

József Bíró (NSN)

Andrea Giessmann (SAP,HSG)

François Exertier (BULL)

Miguel Jimenez (UPM)

Nico Kruber (ZIB)

Francesco Lelli (ERISS)

Henar Muñoz Frutos (TID)

Boris Moltchanov (TI)

Christof Momm (SAP)

Steve Strauch (USTUTT)

José Luis Vázquez-Poletti (UCM)

Internal Reviewer(s):

Frederic Junker, HSG

Nico Kruber, ZIB

Version History

Version Date Authors Sections Affected

0.1 04/06/12 Christof Momm (SAP) Initial draft.

0.11 05/06/12 Christof Momm (SAP) Added WP4 information. Draft state.

0.12 06/06/12 Christof Momm (SAP) Architecture mapping removed, will be done in WP1 architecture deliverable.

0.12 06/06/12 Christof Momm (SAP) Updated WP4 according to now structure


0.15 13/06/12 Christof Momm (SAP) Added status report for SAP-led features

0.16 19/06/12 Jose Luis Vazquez-Poletti (UCM) Added advanced IaaS features (OpenNebula)

0.17 05/07/12 Henar Muñoz Frutos (TID), József Bíró (NSN)

Added status report for TID and NSN-led features

0.2 18/07/12 Christof Momm (SAP) Added contribution of WP3, WP5 and WP6

0.3 18/07/12 Christof Momm (SAP) Added WP2 contribution

0.4 25/07/12 Vasilios Andrikopoulos, Steve Strauch, USTUTT

Added WP7 contribution

0.5 25/07/12 Christof Momm (SAP) Added intro/conclusion.

0.6 27/07/12 Christof Momm (SAP) Included review comments + final editing


Table of Contents

Executive Summary .............................................................................................................. 9

1. Technical Feature Implementation and Evaluation Status – Release 1 .........................10

1.1. WP 2 – Service Engineering and Lifecycle Management ......................................10

1.1. WP 3 – Marketplace ..............................................................................................13

1.1.1. Information Phase .........................................................................................13

1.1.2. Negotiation Phase .........................................................................................17

1.1.3. Contracting Phase .........................................................................................20

1.1.4. Delivery Phase ..............................................................................................21

1.1.5. Marketplace Analytics ...................................................................................22

1.1.6. Marketplace Management .............................................................................23

1.2. WP 4 – Resource Deployment and Management ..................................................25

1.3. WP 5 – Administration, Accounting, Monitoring and Analytics ...............................29

1.4. WP 6 – Native PaaS Technologies .......................................................................32

1.5. WP 7 – Immigrant PaaS Technologies ..................................................................37

2. Technical Feature Planning – Release 2 .....................................................................46

2.1. WP 2 – Service Engineering and Lifecycle Management ......................................46

2.1.1. Change Overview ..........................................................................................46

2.1.2. New Technical Features ................................................................................47

2.2. WP 3 – Marketplace ..............................................................................................47

2.2.1. Change Overview ..........................................................................................47


2.3. WP 4 – Resource Deployment and Management ..................................................50

2.3.1. Change Overview ..........................................................................................50


2.4. WP 5 – Administration, Accounting, Monitoring and Analytics ...............................53

2.4.1. Change Overview ..........................................................................................53


2.5. WP 6 – Native PaaS Technologies .......................................................................54

2.5.1. Change Overview ..........................................................................................54


2.6. WP 7 – Immigrant PaaS Technologies ..................................................................56

2.6.1. Change Overview ..........................................................................................56


3. Conclusion ....................................................................................................................67

4. References ...................................................................................................................68


Annex A. Requirements Elicitation Approach ...................................................................69

Annex B. Use Case / WP Features Mapping ....................................................................70

B.1. Scenario Use Cases .............................................................................................70

4.1. Scenario 8.1 – eMarketplace.................................................................................70

4.2. Scenario 8.2 – Mass Market..................................................................................70

4.3. Scenario 8.3 – Public/Private Cloud ......................................................................70

B.2. Mapping to Work Package Features .....................................................................71


List of Figures

Figure 1: Requirements Elicitation Process ..........................................................................69


Abbreviations

4CaaSt Building the PaaS Cloud of the future

ARB Abstract Resolved Blueprint

AC Application Component

API Application Programming Interface

ARB Abstract Resolved Blueprint

B2B Business to Business

B2C Business to Consumer

BAC Business Advisory Committee

BPEL Business Process Execution Language

CMS Context Management System

DBMS Database Management System

DMTF Distributed Management Task Force

ESB Enterprise Service Bus

HTTP Hypertext Transfer Protocol

IaaS Infrastructure as a Service

NaaS Network as a Service

NEaaS Network Enablers as a Service

JMS Java Messaging System

OVF Open Virtualization Format

OPEX Operational expenditure

PaaS Platform as a Service

PIC Product Instance Component

POI Points of Interest

QoS Quality of Service

REC Runtime Execution Container

SaaS Software as a Service

SLA Service Level Agreement

VM Virtual Machine

WP Work Package

XaaS Anything as a Service: SaaS, PaaS, IaaS level services, but also Native or Immigrant APIs exposed as a Service


Executive Summary

Just like the previous version, this deliverable is divided into two parts: part D1.1.3a describes the ―State of the Art‖, while user and technical requirements are discussed in D1.1.3b (this document). This deliverable represents the third and final iteration and comprises two major parts:

Part 1 – Status Update (section 1): For each work package, a report on the status of all features defined in deliverable D1.1.2b [2], including a brief recap of the implementation status up to release 1, a summary of the experimentation feedback from the use cases regarding release 1 and a brief description of the plans for release 2, which take into account the feedback.

Part 2 – Revised Feature Planning (section 2): For each work package, a delta update on the plans for the technical features for the upcoming release 2 considering the received feedback from the scenarios and use cases. This comprises a feature change overview as well as a full specification of new WP features (if available).

However, since the WP 8 experimentation reports are not available at present, this report only represents a preliminary version with the following limitations:

The status update does not include feedback from the use cases and the corresponding release 2 planning.

The feature planning is complete but does not reflect changes implied by the feedback. As a result, there might be additional changes due to the experimentation feedback. So far, the changes are based on WP-specific plans and initial (informal) feedback from the use cases.

As soon as the experimentation reports are available, we will provide a resubmission of this deliverable, covering

Full status update with feedback summary, a final plan for release 2 and an update on the progress of release 2.

Final technical feature planning for release 2, as far as necessary.

Since this is the last iteration of this deliverable, we will continue the status reporting and feature planning as part of the upcoming WP 1 integration reports (D1.3.2 and D1.3.3).


1. Technical Feature Implementation and Evaluation Status – Release 1

This chapter provides an overview of the status of the technical features that have been defined for each work package, according to the requirements elicitation process (see Annex A) described in D1.1.2 (resubmission) [2].

The status update for each feature includes

1. A brief report on the implementation progress. This progress report is limited to the feature implementation subject to the use case integration and evaluation, which is the release 1 documented in D1.3.1 [3].

2. A brief summary of the feedback from the use cases as documented in the corresponding experimentation reports D8.x.5. The respective feature/use case mapping can be found in Annex B.

3. Plans for future releases based on the feedback along with an update on the status of release 2, which is currently being developed.

As aforementioned, this is a preliminary version of the report, which does not include point 2 and 3 due to a delay of the experimentation reports. Once the experimentation reports are available we will provide the missing content as part of a resubmission.

1.1. WP 2 – Service Engineering and Lifecycle Management

This section provides an overview of the status of the technical features planned for the 4CaaSt Service Engineering and Lifecycle Management.

In particular this work package focuses on the following aspects:

Supporting the design of a cloud enabled solution

Empowering cloud developers

Breaking up the Monolithic Cloud and avoiding vendor lock-in

Resolution of service requirements

Cloud offering orchestration

Details of each feature are reported in the following table:

F#WP2.01 Support the design of a cloud enabled solution Major

Prototype tools that leverage the blueprinting approach for improving the reusability of existing cloud solutions. The feature addresses software architects as target audience.

Responsible Partner

ERISS Feature Status

In Progress

Progress (Release 1 status)

-XML definition of the blueprint has been provided. The language provides a mechanism for describing a service in an abstract way in order to capture its capability and information needed for its deployment.

-A visualisation tool for displaying Abstract Resolved Blueprints has been developed


Scenario Evaluation results / feedback

Plans for future releases / Implementation status release 2

F#WP2.02 Empower cloud Developers Major

The blueprint should serve as reference entry point for cloud developers. In particular it should contain all necessary information about the service for composing, deploying an operating it. This feature also includes tools supporting the development of cloud based solutions. The feature addresses software developers as target audience.

Responsible Partner


In Progress


-A visualisation tool for displaying Abstract Resolved Blueprints has been implemented. Developers can access detailed information by looking at specific placeholders which contain references to the included blueprints.

- APIs for manipulating existing blueprints as a service are offered. In particular, the possibility to build programs that update information contained in the blueprint repository



F#WP2.03 Break the Monolithic Cloud and avoid vendor lock-in Major

The blueprints should be able to abstract PaaS, SaaS and IaaS in a way that is independent from a particular vendor.

Responsible Partner


In Progress


- An XML definition of the blueprint has been provided. The goal of reaching independency from particular vendors is achieved by providing a matching mechanism between offerings and requirements.

- APIs combining blueprints coming from different vendors have been provided.

Scenario Evaluation


results / feedback


F#WP2.04 Resolution of Service Requirements Major

Requirements of services should be analysed and matched against potential offerings coming from other available services in the marketplace.

Responsible Partner

ERIC Feature Status

In Progress


A component that leverages the existing XML description and performs a match-making between offerings and requirements of the various blueprints in order to provide a complete solution composed of different offerings.



F#WP2.05 Cloud Offering Orchestration Major

Cloud based services should be able to be combined in order to have different offerings or to partially resolve potential requirements of a cloud service

Responsible Partner

ERIC Feature Status

In Progress


- A repository has been implemented in order to store, update and access available services. These services are operated by the resolution engine in order to offer a composition of services that deliver the desired solution.

- A WS-I compliant interface for accessing this information has been provided.




1.1. WP 3 – Marketplace

This section provides an overview of the status of the technical features planned for the 4CaaSt marketplace. The features are structured along the phases of market transactions, namely:

Information Phase

Negotiation Phase

Contracting Phase

Delivery Phase

Additionally, two other categories are considered which are relevant for the marketplace:

Marketplace Analytics

Marketplace Management

1.1.1. Information Phase

F#WP3.01 Product Definition Blocker

The electronic marketplace (eMP) allows a Service Provider to define a product at least through a textual description. A product is composed of a technical part (blueprint) and a business part. Defining a product therefore requires the following steps:

Register Blueprint: The marketplace accesses a blueprint repository to get relevant information

Define business properties such as SLA, price, etc.

The marketplace allows a Service Consumer to get a clear idea of the features of a particular product. Additionally, he can get a clear idea of how the added-value of a particular service covers a part of his business needs.

Responsible Partner

TID Feature Status

In Progress


The marketplace allows Service Providers to define products including the technical part (blueprint).

The marketplace links to the Price Editor (see feature F#WP3.024), which allows a Service Provider to define a price model for a product.

The marketplace allows a Service Consumer to get a clear idea of the features of a particular product by browsing the Product Repository.




F#WP3.02 Product Search Blocker

The marketplace allows any of its stakeholders to search the product catalogue for services. Ideally it should support as many different search methods as possible. The customer typically gets a smaller subset of services based on a free text search query or by filtering the catalogue using categories or keywords. The marketplace can also get a list of the most relevant products for a customer.

Supported search types:

Free text search: Any user can search for product offerings in the marketplace by free textual search

Search by formal specification: Any user can search for product offerings in the marketplace using the marketplace‘s specific format and the blueprints format.

Search by browsing: Any user can browse the product repository by categories, providers, etc.

History based search: Any user can search for product offerings in the marketplace, taking into account previous results, contracts, etc.

User profile based search: The user profile will be taken into account when searching for products on the marketplace, giving more priority to the most appropriate one based on the user‘s previous behaviour or his user profile in general.

Responsible Partner

TID Feature Status

In Progress


The marketplace allows all stakeholders to search the product catalogue for services. Types of search supported:

Free Text Search



F#WP3.03 Bid search Minor

The marketplace allows a Service Consumer who did not find a product covering one of his particular business needs to post a bid to attract the attention of providers. If a similar proposal was already expressed by another user he can instead vote to support it.

Responsible Partner

TID / SAP Feature Status

Closed


At the time of writing this deliverable, there are no plans to work on this feature. This decision may change in the future based on the requirements brought in by the application scenarios defined by the project.




F#WP3.04 Related Products Minor

Given a particular product, the marketplace gives access to a subset of the product catalogue made up of related services.

Responsible Partner

TID Feature Status

In Progress


The marketplace repository implements a service taxonomy that allows finding products of the same category and type.

Products can be assigned one of the following types: 'SaaS', 'IaaS', 'PaaS', 'CaaS', 'NaaS' and ‗NEaaS‘. Additionally, products can be assigned one of the following categories: 'Operating System', 'Middleware', 'Database', 'Telco', 'SOA', 'Application', 'ERP' and 'Web'. These product types and categories can be extended and modified by the marketplace administrator.



F#WP3.05 Recommendation Normal

Service consumers receive product recommendations from the marketplace. The marketplace assembles these recommendations based on the Service Consumer‘s user profile, purchase history and social data (also see F#WP3.008).

Responsible Partner

HSG Feature Status

In Progress


Theoretical research has been done and is being continued.

Scenario Evaluation results /


feedback


F#WP3.06 Advertising Minor

The marketplace allows a Service Provider to promote his products through informative and persuasive interactive banners. These impersonal messages are displayed to users during the different phases of any of their transactions.

Responsible Partner

HSG/SAP Feature Status

Open


Not available in release 1



F#WP3.07 Community Rating & Comments Normal

The marketplace allows a Service Customer to sort a subset of products based on other users‘ ratings. He can also access their comments about a particular service.

Responsible Partner

TID/HSG Feature Status

In Progress


Not available in release 1.




F#WP3.08 Social Graph Analysis Major

The marketplace allows part of its stakeholders, depending on their role, to have a visual insight about social relationships between its users based on all their transactions.

Responsible Partner

HSG Feature Status

In Progress


Theoretical research has been done and is being continued. Topics: 1. Topology and properties of social graph in business environments, 2. Applications of social data in electronic marketplaces.



F#WP3.024 Price Model Management Blocker

The 4CaaSt marketplace enables service providers to manage (i.e. define and update) the price models of their products and services. Price models are saved in machine-readable USDL documents, so 1) the payment is charged to the service consumer, depending on the quantitative consumption, and 2) the price models of composite services can be computed automatically.

Responsible Partner

SAP Feature Status

In Progress


The Service Provider can choose from several price assessment metrics (e.g. Subscription, PayPerUseTime) and billing units (e.g. per month, per minute, per document). The Price Editor saves the price model in the machine-readable USDL format for automated processing.



1.1.2. Negotiation Phase

F#WP3.09 Product Resolution and Selection Blocker

The marketplace allows a Service Customer to check the constituting components of a


particular product before he purchases it.

Service resolution: The marketplace supports the selection of the most appropriate service for composite applications.

SLA resolution: The marketplace supports the selection of blueprints according to some constraints specified in the SLA terms

Price resolution: The marketplace supports the selection of blueprints according to some constraints specified in the price model.

Responsible Partner

NTUA Feature Status

In Progress


Resolution of a customer request into products or product compositions, identification of the characteristics of each final product and selection of the most appropriate product.



F#WP3.10 Product Specification Blocker

The marketplace allows a Service Provider to define several variants of his product. For example, different plans can vary in terms of price model, consumption threshold, advertisement-free user interface, etc.

Responsible Partner

TID Feature Status

In Progress


The 4CaaSt marketplace allows the definition of product variants by combining different parameters like price models and SLA terms (availability and security).



F#WP3.11 Product Customisation Blocker

The marketplace allows a Service Customer to choose among several variants of the negotiated service.


There are several ways to make this choice happen:

It could be chosen automatically based on the type of account of the Service Customer (delegated by the Service Provider to the marketplace).

The marketplace could also allow the negotiating partners to communicate through dedicated channels like email or chat.

Responsible Partner

NTUA Feature Status

In Progress


The marketplace supports the selection of services according to some customer constraints like price, security and availability.



F#WP3.12 Bid to Product Minor

The marketplace allows a Service Provider to access the detailed description of an open bid. The marketplace supports the Service Provider in his inquiry to clarify the pending request in order to answer this particular business need.

Responsible Partner

TID/SAP Feature Status

Closed





F#WP3.13 Basket Management Minor

The marketplace allows a Service Customer to manage the products inside his current purchase basket in order to control the negotiation phase.

Responsible TID Feature Closed


Partner Status





1.1.3. Contracting Phase

F#WP3.14 Contract Management Minor

Contract management implies managing the lifecycle of the contract and transferring the result of the negotiation and customisation of the product to a formal specification that represents the agreement of customer and provider about the service to be delivered and the terms and conditions under which it will happen.

Contract Generation: The marketplace allows a Service Provider to instantiate the targeted business model of a particular product into a contract with rules like Service Level Agreements (SLA) or price models.

Display Management: The marketplace allows a Service Provider to manage all its ongoing contracted business relations to handle, for example, contracts renewal, extension or cancellation.

Contract Signature: The marketplace allows the Service Customer and the Service Provider to formally accept a detailed contract. The marketplace fires an event that serves as a legal base to initiate the settlement phase.

Contract State Management: The contracts will pass through different phases that will be tracked by the marketplace.

Responsible Partner

TID Feature Status

In Progress


The 4CaaSt marketplace keeps record of relevant information related to established contracts. This information is stored in a contract repository.


Plans for future releases / Implementation


status release 2

1.1.4. Delivery Phase

F#WP3.15 Delivery Support Blocker

The marketplace allows the Service Provider to inform the Service Customer of the delivery of the product.

Deployment feedback: The customer and the provider have to know the exact details of the services and resources actually deployed for delivering a service.

Monitoring Data: The marketplace will report the most important monitoring data, the status and the usage of the services and resources deployed.

Responsible Partner

TID Feature Status

In Progress


Whenever a product is contracted, the 4CaaSt marketplace triggers its deployment in the 4CaaSt cloud. The 4CaaSt marketplace informs the customer about the status of the deployment.



F#WP3.16 Payment Support Minor

The marketplace supports the billing process of the Service Customer according to the product‘s price model.

Responsible Partner

TID Feature Status

Closed






status release 2

F#WP3.17 Charging Blocker

The marketplace supports pricing and charging in complex product graphs (service value networks) consisting of (multiple) cloud service consumer – provider relations. Charging is responsible for calculating the concrete amount of money a 4CaaSt marketplace customer has to pay during a certain settlement period.

Responsible Partner

SAP Feature Status

In Progress


Two components have been developed:

the Price Editor for defining formalised price models (following the USDL specification) with customisable pricing options;

the Price Aggregator for calculating the overall price model (following the USDL specification) for a product that consumes multiple third party services.



1.1.5. Marketplace Analytics

F#WP3.18 Show Competitive Products Minor

The marketplace allows a Service Consumer to compare two or more products in terms of capabilities, price model or conditions.

Responsible Partner

NTUA Feature Status

In Progress


After having resolved the business attributes of the products, product candidates, among which the selection will take place, may be shown to the customer.




status release 2

F#WP3.19 Reporting on products, incomes, etc Major

The marketplace allows a Service Provider to get figures about the business performance of his products based on statistical analysis of all marketplace transactions.

Responsible Partner

TID Feature Status

In Progress





F#WP3.20 Simulations Major

Service providers will be able to simulate and analyse their basic business model and their revenue streams according to different pricing options. The simulation functionality allows them to foresee how the marketplace will react under different conditions.

Responsible Partner

SAP/HSG Feature Status

In Progress





1.1.6. Marketplace Management

F#WP3.21 User Management Blocker


All users interacting with the marketplace are users of the platform and have to be managed (creation, edition, etc.).

User accounts: The accounts of the users are managed by a manager, but can be edited by the users (payment options, preferences, etc.).

Parties management: The different users of the marketplace will be ascribed to different parties (e.g. companies), and these parties are also managed.

Roles management: The interactions of the different parties and the users with the marketplace will be governed by their role in the platform.

Responsible Partner

TID Feature Status

In Progress


Administration of the marketplace (management of users, parties and roles) is supported. Only authorised users have access to this functionality.



F#WP3.22 Business Management Blocker

The business models available for the marketplace are managed by a Marketplace Manager that defines what business models can be used in the platform, and configures them, especially in relation to user and provider profiles.

Responsible Partner

TID Feature Status

In Progress


Feature implementation has not started yet.



.


1.2. WP 4 – Resource Deployment and Management

This section provides an overview of the status of WP 4 features as part of the platform release 1. Please note that some of the core WP4 features have not been addressed by this release, in particular F#WP4.02 (Elasticity) and F#WP4.07 (NaaS). Nevertheless, there has been significant progress on these features since the last release, which, however, is not subject of this deliverable. Please refer to the most recent scientific report D4.1.2 [4] for more information on this.

F#WP4.01 Deployment of applications over a platform Blocker

Applications composed of application components, potentially using different cloud services (XaaS) will be automatically deployed, configured, executed and terminated by the platform. The deployment mechanism thereby ensures that the final deployments adhere to the SLA and QoS requirements defined by the Developers/Engineers, Service Providers and Customers in the Application Blueprint. Deployment includes (semi-)automated generation of different deployment options based on templates and configuration of elasticity and resource constraints. All this meta-information can be defined using a 4CaaSt deployment design language.

Responsible Partner

SAP Feature Status

In Progress


- Initial deployment model for distributed heterogeneous deployments, but without elasticity support.

- Deployment Manager component that performs a simplified mapping of deployment model to OVF and is integrated with Service Manager, which handles the actual deployment execution.

- Deployment of images by Claudia working



F#WP4.02 Automated Application Elasticity Blocker

The platform will have the ability to scale application components and the underlying platform up/down/out and in depending on different mechanisms:

Using elasticity rules (provided by application developers), or non-default third party elasticity app based on KPIs (possibly defined by customers).

SLA enforcement.

Analysis of KPI traces (via monitor)

Responsible Partner

TID Feature Status

In Progress

Progress (Release 1

Not implemented in release 1


status)



F#WP4.03 PaaS API Blocker

The Platform Resource Manager will expose an API that will allow performing different actions and queries over the platform.

This API has to support a wide range of operations, with special focus on interoperability and standards:

Deployment of applications in the platform.

Configuration of PICs and ACs

Access to deployment status and monitoring information of any of the resources of the application: from ACs, PICs, RECs, and Cloud Services.

Termination of applications.

The API should provide means for reconfiguration and performing individual actions over specific resources (for administration purposes).

Responsible Partner

TID Feature Status

In Progress





F#WP4.04 IaaS Aggregated API Major

To facilitate the interoperability with different IaaS Providers, and prevent a lock-in effect, the 4CaaSt Platform will use an Aggregated API that will provide an abstract layer over the concrete IaaS API being used.

Responsible Partner

TID Feature Status

In Progress



- TCloud API as the IaaS Aggregated API implementation

- Flexiscale driver in the aggregated API implementation for the management of VMs and networks.


The Aggregated API has been used in release 1 as the Cloud provider invoked by the service manager used for deploying virtual machines in the Cloud. Release 1 contains a Flexiscale driver for accessing the Flexiscale Cloud provider.


- OpenNebula driver in the aggregated API implementation for the management of VMs and networks.

F#WP4.05 REC Creation & Virtual Machine Template (or base virtual appliance)

Major

The REC creation approach of 4CaaSt is based on state-of-the art client/server system for software deployment/installation, i.e. the REC contains a deployment agent (responsible for PIC and AC lifecycle control) and a deployment server (responsible for storing necessary artefacts and configuration information. (Note that the actual technology integrated with 4CaaSt is the Chef Framework.) This results in the following requirements for the Service Manager and REC Manager interacting with the deployment (Chef) server:

Store/forward software artefacts (i.e. AC,PIC see #144)

Store/forward Chef cookbooks (provided as artefacts within a Blueprint)

Store/forward the required configuration information (nodes, roles, ...?)

(Virtual Machine) Agent component (Chef client) is required to

Start automatically after the virtual machine template or Base REC is instantiated

Connect to the deployment server to get its configuration

Install all required software artefacts (i.e. AC,PIC)

The Deployment Design Component is required to

Extract the required Cookbooks and artefacts and send them to the Chef server.

This also implies Blueprint artefacts to at least contain one Chef Cookbook.

Responsible Partner

NSN Feature Status

In Progress


REC manager implementation based on Chef, supporting the model conversion of 4CaaSt (i.e. RECs, PICs and ACs) to Chef artefacts (nodes, cookbooks, recipes, etc.)

Chef cookbook support, which allows configuration of arbitrary software stacks on VMs

Chef cookbook(s) written for 4CaaSt demo (Taxi application: 8.1 scenario), note that AC and PIC management not yet separated in cookbooks.



feedback


F#WP4.06 OVF Extensions (required) Major

Since the deployment of virtual appliances is done using the OVF standard with extensions from the Reservoir project, that standard needs to be extended to support the required properties:

number of vCPUs (supported in current OVF)

amount of RAM (supported in current OVF)

number of network interfaces, Persistent Network Addresses (some support but extensions may be required to support all proposed NaaS features of 4CaaSt)

amount of intrinsic storage space (supported in current OVF)

The OVF Generator needs to generate the appropriate OVF descriptions (including extensions from the Abstract Resolved Blueprints.

Responsible Partner

TID Feature Status

In Progress


The OVF has been used to specify different 4CaaSt features used in a PaaS. Currently, DMTF OVF standard objective is IaaS service management. Any feature related to PaaS is out of the scope of that standard. Anyway, 4CaaSt is using it for specifying deployment information for environment (PICs and VMs) and applications.

Changes in the OVF used in release 1 involved:

PIC and ACs information (name, version, cookbooks…)

Balancer support

Scalability information



F#WP4.07 Improved network configuration for applications Major

The platform will have the ability to configure external and internal networks for complex applications as an extension to the 4CaaSt IaaS functionality. The NaaS extension is based on the following requirements:


Basic NaaS functions

o Add NICs to RECs (more than 1!)

o Add Network Address to NIC

o Create Virtual Network (add NIC/Network Address to Virtual Network)

Layer2 / Layer3 (IP range)

Attributes: Open/private, geographic scope

Quality of Service control

o Performance (throughput, latency, etc.)

o Availability (max. outage)

Monitoring

QoS parameters

Other parameters: health status, data transferred

Responsible Partner

NSN Feature Status

In Progress





1.3. WP 5 – Administration, Accounting, Monitoring and Analytics

In the following, we provide an overview of the status of WP 5 features as part of the platform release 1.

F#WP5.01 Runtime PIC Administration Blocker

Provide means to operate the product instances (PICs) installed in the running RECs, including:

• stop/start a product instance;

• deploy/remove Application Component on a product instance;

• migrate Application Components from a PIC in a REC to another PIC in another REC;

• [re]configure a PIC

Responsible Partner

Bull Feature Status

In Progress



JASMINe agent re-engineering to administrate JOnAS instances.


The feature was not integrated to be evaluated in the first scenario / prototype.


F#WP5.02 Monitoring infrastructure: Set up and configure probes Blocker

Setting up and configuring probes on product instances. Graphical tools to manage probes.

REST interface to dynamically configure probes.

Responsible Partner

Bull Feature Status

In Progress


* JASMINe probe framework has been refactored (implementation not completed) to support dynamic deployment and configuration of probes.

* Recipes to install and configure probes inside VMs have been developed to be used by the REC Manager.



F#WP5.03 Monitoring infrastructure: product and platform monitoring

Blocker

Monitoring the product and infrastructure where the probes have been deployed, and storing metrics in the monitoring database

Responsible Partner

TID Feature Status

In Progress


* Development of monitoring framework based on collectd

* Integration of monitoring from different sources using Pub/Sub services

* Monitoring interface based on Mashups as a Service

Scenario Evaluation


results / feedback


F#WP5.04 Metering Capabilities Major

Provide a metering infrastructure that is able to compile usage report on application server side as well as usage reports on the storage and management on monitoring infrastructure side

Responsible Partner

TID Feature Status

closed


N/A


N/A


F#WP5.05 Monitoring Analysis Major

Provide means to obtain deep insights from monitored metrics, using data mining, and prediction/forecasting algorithms. Offer results via the monitoring API.

Responsible Partner

TID Feature Status

In Progress


* Prototype of monitoring analysis engine, providing metrics forecasting




F#WP5.06 Accounting framework Blocker

Provide accounting facilities, based on monitoring, for usage inside the Marketplace provided by WP3.

Responsible Partner

TID Feature Status

Open





1.4. WP 6 – Native PaaS Technologies

F#WP6.01 Pub/Sub communication channel Major

Communication mechanism that decouples sender(s) from receiver(s) in time, space and synchronisation. This mechanism must allow publishers to publish information regardless of the component(s) that might consume it and must provide subscribers with a mechanism to discover and subscribe to desired information, even if it has not been published yet, or if the subscriber has no knowledge of the possible publisher(s). Syntax of the published/consumed information must be simple to allow easy and efficient distribution of data, as well as the programmatic API.

Responsible Partner

UPM Feature Status

In Progress


The SilboPS component is the implementation of the defined interface. It was released early as a prototype for integration purposes.



F#WP6.02 Mashups catalogue Major


Catalogue of building blocks (individual gadgets or configured workspaces) must be integrated in the marketplace where future users or service aggregators can search and purchase building blocks based on comments and previous experiences of other users. The catalogue must also provide registering capabilities for developers.

Responsible Partner

UPM Feature Status

In Progress


Catalogue that is internal to mashup platform Wirecloud is available



F#WP6.03 Mashup platform Major

Mashup platform must be able to serve applications made up from small building blocks (gadgets and mashups). These building blocks ought to be based on Web standards and focused on traditional browsers as their execution platform, whereas they are connected to backend services and also to one another to offer a better user experience. The mashup platform must provide compositing features, to enable an easy redefinition of applications choosing different building blocks according to certain situations, and modify the existing compositions.

Responsible Partner

UPM Feature Status

In Progress


Initial integration of Wirecloud into 4CaaSt has been performed. Integration with Pub/Sub service has started



F#WP6.04 Mashups as building blocks Major

Support for the definition, registering, discovery and purchase of pre-configured sets of gadgets as building blocks for creating composite applications.

Responsible UPM Feature In Progress


Partner Status


Creation of a Gadget Definition Language (GDL) and a Mashup Definition Language (MDL), representing a widget (a.k.a. gadget) and a mashup (a configured layout of widgets), respectively. These descriptions represent the standard description used by the mashup platform Wirecloud for deploying widgets/mashups. An initial approach to describing widgets and mashups with blueprints has been developed, indicating requirements and relations among them.



F#WP6.05 Location Context Provider Normal|

This provider solution consists of three components: location context provider for Android phone, location simulator with GUI and location simulator in the context manager cache

Responsible Partner

TI Feature Status

In Progress


The context simulation injection into the context cache of the CMS is ready and already used for the demo scenario 1 (taxi application). A draft version of the location simulation is provided as well. It is not yet exhaustively tested and is planned to be used in the second demo scenario (tourist application). A draft version of the location agent for Andoid terminals is provided.



F#WP6.06 Context Manager Major|

The central brokering node handling the context information between consumers and providers

Responsible Partner

TI Feature Status

In Progress

Progress (Release 1

The SW implementing the CMS is provided, up and running in the testbed. However the integration of CMS components into non-functional interfaces (provisioning, monitoring, charging) is not yet


status) ready and under development.



F#WP6.07 Context Consumer API Major|

The API that shall be integrated into the cloud infrastructure as a Service Enabler and handling the context data from the Context Manager to the context consuming applications.

Responsible Partner

TI Feature Status

closed


The APIs are provided and documented and providing all the required functionalities for the demo scenarios. Their integration with non-functional interfaces is missing as mentioned in the F#WP6.06 above. This will be addressed as part of F#WP6.06.



F#WP6.08 Scalability of Data Store as a Service Normal

The Data Store as a service component must be able to scale out, i.e. increasing the amount of resources to improve performance, as well as scale in, i.e. reducing the amount of resources to save computing power and thus money. For simple data stores like Scalaris, storage load is typically spread over several nodes participating in the system. Also each stored value is typically replicated among several nodes to ensure availability. A scale-out operation thus involves adding new nodes to the system which requires data migration between nodes. Similarly, on scale-in operations data on a node which is to be removed needs to be migrated to the remaining nodes before the node is shut down. These two operations must be suitable for execution during live operation even under heavy use of the data store. They also need to ensure consistency among the different replicas of each item.

Responsible Partner

ZIB Feature Status

In Progress


Support for Scale-out operations was added, i.e. adding additional Scalaris instances joining an existing Scalaris ring (even under heavy load) by simply adding additional VMs with an appropriate configuration.




F#WP6.09 Simple API for Data Store as a Service Normal

The Data Store as a service component must provide a simple API for the Software Designer to use. This API can be proprietary and can thus make use of all platform features offered by the Data Store. It should provide convenience methods to easily access often-used features such as connection pools and should allow the user to monitor the distributed Data Store service. Since Cloud applications can be written in a variety of different languages, this API should be exposed to some of them, e.g. Java, Python, Ruby.

Responsible Partner

ZIB Feature Status

In Progress


The first release includes an initial version of the Scalaris APIs for Java, Python, Ruby and JSON with interoperable value types, i.e. values written from one API can be (natively) read from any other API if a supported type is used.



F#WP6.10 Standardised API for Data Store as a Service Normal

The Data Store as a Service component must provide a standardised API like JDO to access data (almost) the same way as traditional data stores like RDBMS. This eases application development for developers coming from different data stores at the cost of probably not being able to use every feature offered by the platform. It does however allow for data back-ends to be exchanged for one another thus preventing vendor lock-in.

Responsible Partner

FT-ORANGE Feature Status

In Progress


We have tried different scenarios that allow reusing existing code bases. Our first attempt was to try to refactor the Google App Engine NoSQL connector. Although very promising, this approach appears to be not viable due to too many dependencies to untie and an intermediate library not distributed under an appropriate licence.

Scenario


Evaluation results / feedback


F#WP6.11 Integrated telco services Normal

Provide telco services integrated into 4CaaSt, without integration cost for service provider.

Responsible Partner

FT-ORANGE Feature Status

In Progress


* Running telco server (acting as a gateway to Orange network) deployable as DEBIAN package and controlled remotely by a chef recipe.

* Running client library available as maven archetype.



1.5. WP 7 – Immigrant PaaS Technologies

F#WP7.01 Support for Various Communication Protocols Blocker

The extended ESB Apache ServiceMix has to support several communication protocols and provide multi-tenant aware communication. Thus, integration of potentially multi-tenant aware services and applications is enabled.

Responsible Partner

USTUTT Feature Status

Closed


Delivered (see D1.3.1)




status release 2

F#WP7.02 Support for non-tenant-specific Service Requests and Responses (Backward Compatibility)

Blocker

Incoming and out-going messages without any tenant context information have to be supported as before, e.g. transformation and routing.

Responsible Partner


Closed





F#WP7.03 Message transformations for ESB normalised format Blocker

Message Transformation from Incoming Message Format into Internal Normalized Message Format and vice versa by considering tenant information in case it is available in the messages.

Responsible Partner


Closed





F#WP7.04 Tenant-aware Routing Blocker

The normalised message router has to do the potential tenant-specific routing based on the tenant-context information contained in the normalised message that is used internally.

Responsible USTUTT Feature Closed


Partner Status





F#WP7.05 Support for multiple, different Context Provisioning Systems

Blocker

The integration of a wide range of Context Provision Systems into CIF must be possible. This allows CIF to be used in as many scenarios as possible, which may require a diverse set of context information.

Responsible Partner


Closed





F#WP7.06 Abstraction from the Context Provisioning Systems Blocker

CIF must abstract the different Context Provisioning Systems‘ technology, communication protocol, data format, and so on. Inside CIF it must be ensured that all context information can be used and aggregated in a common way.

Responsible Partner


Closed





feedback


F#WP7.07 Encapsulation and Reuse of Higher Level Domain-specific Functionality

Blocker

CIF must enable the creation of reusable building blocks, offering domain-specific functionality by aggregating different types of context information in a way which is suitable to the specific application domain.

Responsible Partner


Closed





F#WP7.08 Support for BPMN2 Correlation Blocker

Bonita Open Solution has to support BPMN2 Correlation mechanism to allow messages between process instances to be correlated to the right process instances.

Responsible Partner

BonitaSoft Feature Status

In progress


Initial steps have been taken; results have to be refined, extended and tested for production readiness (see D1.3.1)



(see D1.3.1)


F#WP7.09 Dynamic Reload of Dependencies Blocker

API to allow dynamic reload of process dependencies like jar files, contexts, etc.

Responsible Partner

BonitaSoft Feature Status

In progress


Initial steps have been taken; results have to be refined, extended and tested for production readiness (see D1.3.1)



F#WP7.10 Right Sized and Incremental Application Server Platform

Blocker

JOnAS assemblies should be available to fit the needs of an application (in term of technical services). Some JOnAS profiles will be available, but ―à la carte‖ assemblies could also be built to exactly fit the needs of an application. In addition, an assembly can be enhanced on the fly, when an application requires a service, which is not installed already.

Responsible Partner

Bull Feature Status

In progress


First prototyping of the feature was designed to enhance the JOnAS OSGi-based architecture by introducing the concept of add-ons to support modularity in terms of configuration and packaging (see D1.3.1)



Complete the add-on implementation to support configuration and packaging modularity (see D1.3.1)

F#WP7.11 Application Server Deployment Features Blocker

Application server should provide capabilities to deploy JOnAS and Apache (load balancer) instances and applications into REC. Support of a cloud artefact (with associated deployment descriptor) for multi-modules application deployment (OSGi, WAB, EAR, WAR or EJBJAR), taking into account dependencies, configuration, SLA and QoS.

Responsible Partner

Bull Feature Status

In progress



Providing a REST interface to the deployment agent (cluster daemon) that allows to remotely control JOnAS instances (see D1.3.1)



Remote deployment and configuration of JOnAS (app server) and Apache (load balancer) instances.

Remote deployment of applications. Support of a cloud artefact (with associated deployment descriptor) for multi-module application deployment (OSGi, WAB, EAR, WAR or EJBJAR), taking into account dependencies, configuration, SLA and QoS.

REST interfaces to support all features above

(see D1.3.1)

F#WP7.12 Database Scalability Blocker

The database should be able handle loads higher than the ones a single node can handle by aggregating the computing power of multiple nodes.

Responsible Partner

UPM Feature Status

Closed


A PgCloud JDBC driver, an extended PostgreSQL RDBMS with improved write-set handling capabilities and the required deployment and configuration scripts has been delivered. (see D1.3.1)



F#WP7.13 Synchronous replication Blocker

Production quality implementation of synchronous replication is available at DMBS level. Synchronous replication is implemented within the database to allow user-specified control of durability.

Responsible Partner

2ndQ Feature Status

Closed


Production quality implementation of synchronous replication delivered into PostgreSQL 9.1, beta May 2011, full release September of 2011. (see D1.3.1)




F#WP7.14 Power reduction Blocker

Solution has to provide environmentally friendly features by allowing reduced power consumption when there is no user activity. Power save mode should be entered within 5 minutes of zero activity for that component, and wake immediately when activity starts again so that no loss of performance is suffered, only a reduction in power.

Responsible Partner

2ndQ Feature Status

In progress


Delivered basic "latch" infrastructure to allow power reduction code and made it portable to all platforms. Included into the development stream for PostgreSQL 9.2 in June 2011. (see D1.3.1)



Complete task of making all parts of PostgreSQL sleep on latch code, so full sleep is achievable when no user activity is detected. (see D1.3.1)

F#WP7.15 Database-independent scalability API Blocker

Solution must provide an API for managing the scalability of DBs, independent of the implementation of the DB.

Responsible Partner

2ndQ Feature Status

In progress


Initial implementation of a scalable DB API, called Saladdin was delivered in RP1. (see D1.3.1)



(see D1.3.1)


F#WP7.16 Built on standards Blocker

Components must be built on standard technologies, like BPEL, Web services, HTTP, JMS, XSLT, JDBC, etc. to enable the use of standard composition engines and standard protocols, without custom extensions that would dramatically reduce portability.

Responsible Partner

USTUTT, UPM, 2ndQ, Bull, BonitaSoft

Feature Status

In progress


Extended Apache ServiceMix, Context Integration Framework, PgCloud, Saladdin (PostgreSQL), Orchestra, JOnAS to support this feature. (see D1.3.1)



All components in WP7 must support this feature in following releases. (see D1.3.1)

F#WP7.17 Multi-tenancy support Blocker

The solution must allow the management and handling of multiple tenants for the same instance.

Responsible Partner

USTUTT, BonitaSoft, Bull

Feature Status

In progress


Extended Apache ServiceMix, Bonita Open Solution, JOnAS to support this feature. (see D1.3.1)




F#WP7.18 Monitoring capabilities (solution specific) Blocker

The solution must offer user and application monitoring capabilities; integration with the 4CaaSt platform monitoring capabilities (WP5) will be done in RP2 and RP3.

Responsible Partner

BonitaSoft, Bull Feature Status

In progress

Progress (Release 1

Bonita Open Solution, JOnAS, Orchestra support this feature. (see


status) D1.3.1)




F#WP7.19 Horizontal scalability support Blocker

Scale out/in by adding/removing a new/running instance or a new/running application instance.

Responsible Partner

Bull Feature Status

In progress


JOnAS, Orchestra have been extended to support this feature. (see D1.3.1)





2. Technical Feature Planning – Release 2

This chapter provides an update on the technical feature planning based on the use case and WP-internal feedback. For each work package this includes:

A change overview table summarising all changes to the features planning such as closed features, new features or change of scope for features in progress.

A full specification of newly introduced features based on the feature template introduced in D1.1.2b [2].

Note that due to the delay of the experimentation reports this plan does not reflect all the use case feedback and may therefore change again. The resubmission of this deliverable will include the final plan.

2.1. WP 2 – Service Engineering and Lifecycle Management

2.1.1. Change Overview

Feature Id

Feature Name Status Remarks

F#WP2.01 Support the design of a cloud enabled solution

In Progress Implemented by the following components:

Blueprint repository

Blueprint composition engine,

blueprint template,

front end API,

BlueprintExe

F#WP2.02 Empower cloud Developers


Blueprint repository,

Blueprint composition engine,

Blueprint template,

Front end API

F#WP2.03 Break the Monolithic Cloud and avoid vendor lock-in


blueprint template,

front end APIs

F#WP2.04 Resolution of Service Requirements


Blueprint template,

Blueprint Composition engine

F#WP2.05 Cloud Offering Orchestration


Blueprint template,

Blueprint composition engine


2.1.2. New Technical Features

None.

2.2. WP 3 – Marketplace


Feature Id Feature Name

Partner Status Remarks

F#WP3.01 Product Definition

TID In Progress

The functionality of price model management has been moved from the old feature F#WP3.001 and F#WP3.022 to F#WP3.024 for a clean separation of concerns.

F#WP3.02 Product Search

TID In Progress

Community based search and social search are no longer addressed.

F#WP3.03 Bid Search TID / SAP

Closed


F#WP3.04 Related Products

TID In Progress

No changes.

F#WP3.05 Recommendation

HSG In Progress

No changes.

F#WP3.06 Advertising HSG / SAP

Open No changes.

F#WP3.07 Community Rating & Comments

HSG / TID

In Progress

No changes.

F#WP3.08 Social Graph Analysis

HSG In Progress

No changes.

F#WP3.09

Product Resolution and Selection

NTUA In Progress

This feature has been renamed from ―Product Resolution‖ to ―Product Resolution and Selection‖ to better illustrate its scope.

F#WP3.10 Product Specification

TID Open No changes.

F#WP3.11 Product Customisation

NTUA In Progress

This feature was formerly lead by TID and is now lead by NTUA.


F#WP3.12 Bid to Product

TID / SAP

Closed


F#WP3.13 Basket Management

TID Closed


F#WP3.14 Contract Management

TID In Progress

No changes.

F#WP3.15 Delivery Support

TID In Progress

No changes.

F#WP3.16 Payment Support

TID Closed


F#WP3.17 Charging SAP In Progress

Scope has been redefined to handling of pricing only while settlement and revenue sharing has been moved to the new feature F#WP3.023; assigned to SAP.

F#WP3.18 Show Competitive Products

NTUA In Progress

No changes.

F#WP3.19

Reporting on products, incomes, etc

TID In Progress

No changes.

F#WP3.20 Simulations SAP & HSG

In Progress

Assigned to SAP & HSG

F#WP3.21 User Management

TID In Progress

No changes.

F#WP3.22 Business Management

TID In Progress

Price models are no longer handled as part of this feature. They are part of feature F#WP3.024 now, for a clean separation of concerns.

F#WP3.23 Settlement & Revenue Sharing

TID In Progress

The functionality of settlement and revenue sharing has been moved from the old feature F#WP3.017 to F#WP3.023 for a clean separation of concerns; assigned to TID.


F#WP3.24 Price Model Management

SAP In Progress

The functionality of price model management has been moved from the old feature F#WP3.001 and F#WP3.022 to F#WP3.024 for a clean separation of concerns.


F#WP3.23 Settlement & Revenue Sharing Blocker

The marketplace supports complex billing processes like bi-directional money transactions between partners or automatic revenue sharing in the case where multiple providers are involved. Since different providers may participate in a service delivery, their incomes have to be distributed among them, including revenue sharing policies if they have been defined.

Related Use Cases

UC.8-1.004: Revenue sharing

UC.8-1.009: Distribute revenue shares

Responsible Partner

TID

Implementing Components

Settlement Engine

Dependencies to other features

F#WP3.17: Charging

F#WP5.06: Accounting framework

Boundary Conditions or Assumptions

Accounting information must be available from WP5.

Charging information must be generated by the Business Charging Component based on accounting information and existing price models.

Risks The implementation of this feature fully depends on the availability of features F#WP3.17 and F#WP5.06 since without detailed charging information it is not possible to perform settlement.

Effort Medium

F#WP3.24 Price Model Management

The 4CaaSt marketplace enables service providers to manage (i.e. define and update) the price models of their products and services. Price models are saved in machine-readable USDL documents, so 1) the payment is charged to the service consumer, depending on the quantitative consumption, and 2) the price models of composite services can be computed automatically.

Related Use Cases

UC.8-1.005

Responsible Partner

SAP



Price Editor



Metering extension of blueprint format

API of blueprint repository

Risks None known at present

Effort Medium

2.3. WP 4 – Resource Deployment and Management


Feature Id

Feature Name

Status Remarks

F#WP4.01 Deployment of applications over a platform

In Progress

Implementation continues as planned with new components of release 2 architecture described in D1.2.3

F#WP4.02 Automated Application Elasticity

In Progress

No changes.

F#WP4.03 PaaS API In Progress

Will be implemented by the PaaS Manager, which is a new component of the WP 4 architecture.

F#WP4.04 IaaS Aggregated API

In Progress

Lead changes from NSN to TID.


In Progress

Implementation continues as planned with new features of release 2 architecture described in D1.2.3

F#WP4.06 OVF Extensions (required)

In Progress

PaaS Manager API will be based on this extended OVF (OVF++).

F#WP4.07 Improved network configuration for applications

In Progress

Implementation started with features of release 2 architecture described in D1.2.3


F#WP4.08 Automated monitoring configuration

New We need support for an automated configuration of the monitoring system as an additional step in the software stack configuration. Since this functionality is self-containing we will address it as an independent feature and not as part of the REC Manager feature.

F#WP4.09 OpenNebula Cluster support

New To enforce high availability, which might be offered as an SLA, we need clustering support from the IaaS. 4CaaSt develops and demonstrates such a feature for OpenNebula.

F#WP4.10 Resource requirement calculation (SLA translation)

New To give an estimate on the required resources for enforcing certain performance SLAs, a translation of resource requirements is used. This feature will address the resource requirements calculation across the software/services stack reusing SLA@SOI and IRMOS results.


F#WP4.08 Automated monitoring configuration Major

Blueprints may contain KPI definitions for VMs, PICs, and ACs. The REC Manager will be in charge of deploying and configuring the corresponding probes in the RECs. Two kinds of probes are handled in the project, JASMINe probes for all Java/JMX components, Collectd probes for other components. Both kinds of probes are installed using Chef recipes. Probes may be installed by the REC Manager or are embedded in the RECs. The advantages of the first solution are threefold: 1) a composite probe can be defined to aggregate monitoring events coming from a cluster of RECs, 2) the probes‘ execution does not impact the RECs resources, 3) it does not require a direct link between the REC and the monitoring DB. At runtime, monitoring data is published in the Monitoring DB for advanced analysis, in the mashup console, and towards the PaaS Manager in charge of applying the elasticity rules.

Related Use Cases

UC.8-1.007: Deploy Service (and operate Service);

UC.8-3.003: Solution Provisioning & Operation for private/public components

Responsible Partner

Bull


PaaS Manager, REC Manager, JASMINe Probe, Collectd


F#WP5.02, F#WP5.03


Will make use of mechanisms developed in WP5.

Risks


Effort High

F#WP4.09 OpenNebula Cluster support Normal

Cluster support is a new feature recently implemented in OpenNebula, and included in the last release (OpenNebula 3.4). Clusters are pools of hosts that share datastores and virtual networks. Clusters can be used within the 4CaaSt project to implement load balancing, high availability, and quality of service at IaaS level.

Clusters in OpenNebula can be used to implement different 4CaaSt-related scenarios. For example, to implement quality of service, we can configure different clusters (e.g. Golden cluster, Silver cluster, etc.) offering different guarantees (e.g. different levels of availability, different deployment times, etc.), so that, when a new application must be deployed, depending on the quality of service parameters defined in the application blueprint, the most suitable cluster is selected. Another possible scenario is the implementation of high-availability (HA) features. We can define two or more separated clusters of servers for HA purposes, so that, when a given application component requires high availability, the different PIC artefacts can be replicated in various clusters, guaranteeing that in case of a cluster failure the application is not disrupted.

Related Use Cases

TBD

Responsible Partner

UCM


OpenNebula Clusters Manager


F#WP4.01


None, it‘s a separate component.

Risks None, it‘s a separate component.

Effort High

F#WP4.10 Resource requirement calculation (SLA translation) Normal

The Resource Requirement Calculation is a new feature that will conduct the F#WP4.1 so as to achieve an optimum initial resource allocation of the newly deployed application. It will take as an input the hints that the application provider has previously defined in the blueprint, and based on the selections of the customer it will calculate the resources needed for an initial deployment.

The feature is provided with the deployment graph through F#WP4.1 and decides on the number of Virtual Machine instances to be deployed and the type and size for each one of them and finally, sends the results back to F#WP.4.1. This process is based on one hand


on the business parameters that are defined in the resolved blueprint (i.e. cost, availability) and on the other hand, on the technical hints that are defined by the application developer. The calculation mechanism will initially support a basic set of hints functions and requirement to resource mappings, and it is expected to be further enhanced with more sophisticated methods, based on IRMOS approach, SLA@SOI outcomes and meta-heuristic algorithms as the project processes.

Related Use Cases

UC.8-1.002 Contract service

Responsible Partner

NTUA


Resource Requirement Calculator, Deployment Design Manager


F#WP4.1 – Deployment

WP3 Marketplace (customer contract parameterisation)

WP 2 Service Development


The parameterisation is done with a discrete set of options encoded as a list of strings. No explicit parameter setting is done (e.g. availability := 0.937)

The resource assignment assumes that IaaS providers have uniform resource description.

Risks Base functionality (indexed resolutions) is achievable. Advanced functionality can be run as a command line hints generator if not integrated.

Effort High

2.4. WP 5 – Administration, Accounting, Monitoring and Analytics


Feature Id

Feature Name

Status Remarks

F#WP5.01 PIC Administration

In Progress

No changes.

F#WP5.02 Monitoring infrastructure: Set up and configure probes

In Progress

Some results already demonstrated



In Progress

Some results already demonstrated

F#WP5.04 Metering Capabilities

Closed It is covered by F#WP5.06

F#WP5.05 Monitoring Analysis

In Progress

No changes.

F#WP5.06 Accounting framework

In Progress

No changes.


None.

2.5. WP 6 – Native PaaS Technologies


Feature Id

Feature Name Status Remarks

F#WP6.01 Pub/Sub communication channel

In Progress Advertise messages, Efficient matching/routing engine, Robust brokers implementation, Multi-node routing algorithm have been addressed.

F#WP6.02 Mashups catalogue

In Progress Decoupled use of externally stored resources (widgets/mashups)

F#WP6.03 Mashup platform In Progress User interface adapted to support Wirecloud as an execution environment

New module support. Pub/Sub reworked as a module

F#WP6.04 Mashups as building blocks

In Progress Ability to deploy external gadgets into local catalogue


F#WP6.05 Location Context Provider

In Progress The context simulation injection into the context cache of the CMS is ready and already used for the demo scenario 1 (taxi application). A Draft version of the location simulation is provided as well. It is planned to use it in the second demo scenario (tourist application). A draft version of the location agent for the Andoid terminals is provided.

F#WP6.06 Context Manager In Progress The SW implementing the CMS is provided, up and running in the testbed. However the integration of CMS components into the non-functional interfaces (provisioning, monitoring, charging) is not yet ready and under development.

F#WP6.07 Context Consumer API

Closed The APIs are provided and documented and providing all the required functionalities for the demo scenarios. Their integration with non-functional interfaces is missing and will be addressed by F#WP6.06 from now on.

F#WP6.08 Scalability of Data Store as a Service

In Progress Added Scalaris monitoring for measuring load and allowing better decisions on how and when to scale in or out.

Support for scale-in operations, i.e. gracefully removing Scalaris instances from a Scalaris ring (even under heavy load).

F#WP6.09 Simple API for Data Store as a Service

In Progress Added APIs to scale in/out.

Added APIs to retrieve monitoring information.

F#WP6.10 Standardised API for Data Store as a Service

In Progress Study of Google app engine code reuse.

Implementation from Datanucleus codebase

F#WP6.11 Integrated telco services

In Progress Client code available as maven archetype

Server library deployable as a Debian package wrapped into chef installation scripts.

F#WP6.12 Enabler interfaces

New Defined set of operations for services provisioning and building blocks deployment. Defined monitoring probes to be implemented. Preliminary works on accounting probes for each component.


F#WP6.12 Enabler interfaces Normal

The different components have to implement a set of enabler interfaces, designed for the


integration with several work packages (WPs 3, 4 and 5). These enabler interfaces are designed to provide a common and homogeneous interface so as the core of the platform can manage and make use of the heterogeneous components in a common way. These enabler interfaces have to provide several features, namely: deployment for installable building blocks, provisioning interfaces for components offered as services, accounting probes for components able to apply charges for their usage, and monitoring mechanisms so as to expose different KPIs relevant for the execution of the service and, in some cases, the application components inside it.

Related Use Cases

UC.8-1.003: Rating and Charging;


UC.8-2.003: Commercialise Service provided by Software

UC.8-2.005: Buy service from the marketplace

UC.8-2.006: Enforce SLA

UC.8-2.007: Enforce metering

UC.8-3.003: Solution Provisioning and Operation

Responsible Partner

UPM, TI, ZIB, FT and TID


Context Consumer, SilboPS, Scalaris, Wirecloud, Network Enablers


F#WP6.01, F#WP6.3, F#WP6.07, F#WP6.08, F#WP6.09, F#WP6.11


Will make use of accounting interface

Will make use of monitoring infrastructure

Will be invoked by PaaS manager in a uniform way, irrespectively of the technology of the PIC (Java Application Server, database, mashup platform …)

Risks Creating a common interface for a wide variety of technologies from WP6 and WP7, some component might not get seamlessly integrated because of too high efforts needed to assure everything is possible

Interfaces with WP3, WP4 and WP5 components do not match

Effort High

2.6. WP 7 – Immigrant PaaS Technologies


Feature Id Feature Name Status Remarks


F#WP7.01 Support for Various Communication Protocols

Closed Delivered.

F#WP7.02 Support for non-tenant-specific Service Requests and Responses (Backward Compatibility)

Closed Delivered.

F#WP7.03 Message transformations for ESB normalized format

Closed Delivered.

F#WP7.04 Tenant-aware Routing

Closed Delivered.


Closed Delivered.

F#WP7.06 Abstraction from the Context Provisioning Systems

Closed Delivered.


Closed Delivered.

F#WP7.08 Support for BPMN2 Correlation

In Progress No Changes.

F#WP7.09 Dynamic Reload of Dependencies




F#WP7.11 Application Server Deployment Features



F#WP7.12 Database Scalability

Closed Delivered.

F#WP7.13 Synchronous replication

Closed Delivered.

F#WP7.14 Power reduction In Progress No Changes.

F#WP7.15 Database-independent scalability API


F#WP7.16 Built on standards

In Progress This is required for all prototypical implementations of WP7 components.

F#WP7.17 Multi-tenancy support


F#WP7.18 Monitoring capabilities (solution specific)

In Progress This is required for at least all prototypical implementations of WP7 components delivered within the scope of 4CaaSt.

F#WP7.19 Horizontal scalability support


F#WP7.20 Automatic Load Balancing


F#WP7.21 Error Handling in Presence of Replica Failures


F#WP7.22 Enhanced Group Commits


F#WP7.23 Accessibility to Multiple Nodes


F#WP7.24 Measurement of Tenant-Based Performance Isolation



F#WP7.25 Benchmark Portability


F#WP7.26 Benchmark Adaptability


F#WP7.27 Clustering Capabilities


F#WP7.28 Tenant-Based Deployment and Configuration


F#WP7.29 Tenant Isolation and Security


F#WP7.30 Deployment and Provisioning Support (based on Chef scripts)


F#WP7.31 Marketplace Support (based on Blueprint Language and USDL)



This section provides an overview of new features planned to be implemented for the second release of WP7 prototypes. These features are based on and have been derived from the specification and design of extensions of WP7 components for release two contained in WP7 deliverable D7.2.2 [11]. Thus, the features provided in the following table are consistent with the content of D7.2.2.

F#WP7.20 Automatic Load Balancing Major

This requirement states that the system shall be able to benefit from the addition of new VM replicas to improve performance by changing connections to the new PgCloud instances. For example, if 4CaaSt platform detects that a PgCloud cluster is overloaded the Resource Manager could instantiate new replicas that will join the cluster. In order to improve performance some connections should be changed to point to the new replicas. However, clients will not change their connections by themselves (they are not even aware of which replica they are connected to). This must be done automatically and transparently.

Related Use Cases




Responsible Partner

UPM


PgCloud, Resource Manager


n/a


n/a

Risks n/a

Effort High

F#WP7.21 Error Handling in Presence of Replica Failures Major

Given that a PgCluster will have several replicas, high availability can be achieved by changing the connections pointing to failed replicas (e.g., because the virtualization software crashed, due to a hardware failure, etc.). However, it is required that client operations should not be interrupted. Failures must be addressed by PgCloud software automatically without clients noticing that one or more replicas have failed.

Related Use Cases



Responsible Partner

UPM


PgCloud


F#WP7.12


n/a

Risks n/a

Effort High

F#WP7.22 Enhanced Group Commit Major

Group commit will be enhanced specifically to increase performance when using cheaper


disks, as are common in cloud environments. Performance increases dramatically when bursts of activity occur on the database.

Related Use Cases



Responsible Partner

2ndQ


PostgreSQL


n/a


n/a

Risks n/a

Effort High

F#WP7.23 Accessibility to Multiple Nodes Major

The capability to access multiple nodes from one client will be added, using a hashed data distribution in order to scale to many nodes.

Related Use Cases



Responsible Partner

2ndQ


Saladdin


n/a


n/a

Risks n/a

Effort High


F#WP7.24 Measurement of Tenant-Based Performance Isolation Major

The methodology how to measure the isolation, and at which workload profiles is an important step towards benchmarking. A response time for example doesn‘t provide sufficient knowledge about the systems performance if the workload for the measurements was chosen without respect to the actual usage.

Related Use Cases


Responsible Partner

SAP


Performance Isolation Benchmarking


n/a


n/a

Risks n/a

Effort High

F#WP7.25 Benchmark Portability Major

A benchmark that can only run on one system is not helpful to compare systems. Therefore the benchmark should provide measures to be easily adapted to different platforms.

Related Use Cases

UC.8-3.003 Solution Provisioning & Operation for private/public components

Responsible Partner

SAP




n/a


n/a

Risks n/a

Effort High


F#WP7.26 Benchmark Adaptability Major

The implementation should be ready to be easily adapted to measure different scenarios in which performance isolation is important. In an ideal case the implementation of the methodology is decoupled from the actual technical domain.

Related Use Cases


Responsible Partner

SAP




n/a


n/a

Risks n/a

Effort High

F#WP7.27 Clustering Capabilities Major

BOS engine is managing two kinds of executions: synchronous and asynchronous. Asynchronous executions are activated using an embedded scheduler. So far, v5.x engine was using a home-made scheduling system which is not working in a clustering environment.

In addition to the scheduling system, current implementations (both v5 and v6 series) are using in-memory storage for some kind of objects and this is not compliant with a clustering architecture. We work on keeping this in-memory strategy (performance goal), but make it compliant with a clustering architecture.

Related Use Cases



Responsible Partner

BONITASOFT


BONITA OPEN SOLUTION (BOS)

Dependencies to other

n/a


features


n/a

Risks n/a

Effort High

F#WP7.28 Tenant-Based Deployment and Configuration Major

The deployment and configuration of the ESB and the services available for a certain tenant should be managed in a transparent manner by the ESB.

Related Use Cases



Responsible Partner

USTUTT


Apache ServiceMix


F#WP7.17, F#WP7.29


n/a

Risks n/a

Effort High

F#WP7.29 Tenant Isolation and Security Major

Tenants must be isolated to prevent them from gaining access to other tenants‘ data (i.e., data isolation) and computing resources (i.e., performance isolation). Data isolation can be further decomposed into communication isolation, referring to keeping the message exchanges for each tenant separate, and application isolation, referring to preventing applications and services of one tenant from accessing data of another tenant‘s applications or services.

The necessary authorisation, authentication, integrity, and confidentiality mechanisms must consider and enforce tenant- and user-wide security policies when required.

Related Use Cases


UC.8-3.003: Solution Provisioning & Operation for private/public


components

Responsible Partner

Bull, BONITASOFT, USTUTT


JOnAS, BOS, Apache ServiceMix


F#WP7.17, F#WP7.28


n/a

Risks n/a

Effort High

F#WP7.30 Deployment and Provisioning Support (based on Chef scripts)

Major

All WP7 components will be provisioned and configured by Chef scripts closely following the approach and outcomes of WP4. Two types of Chef scripts have to be distinguished. On the one hand for basic provisioning of a component and on the other hand for the configuration and wiring of the provisioned component.

Related Use Cases



Responsible Partner

UPM, 2ndQ, Bull, BONITASOFT, USTUTT, Resource Manager


PgCloud, PostgreSQL, Saladdin, JOnAS, BOS, Apache ServiceMix, Context Integration Framework (CIF)


F#WP4.*


The realisation is based on the features and outcomes of WP4. Thus, these have to be in place.

Risks n/a

Effort High

F#WP7.31 Marketplace Support (based on Blueprint Language and Major


USDL)

All WP7 components will be offered in the 4CaaSt Marketplace. Thus, the technical aspects as well as business aspects have to be specified according to the outcomes of WP2 and WP3. Therefore, the technical aspects have to be described per WP7 component in a Blueprint document and the business aspects have to be described per WP7 component in a USDL document.

Related Use Cases

UC.8-1.005: Service Specification;

UC.8-2-004: Choose service in the marketplace;

UC.8-2-005: Buy service from the marketplace

Responsible Partner

UPM, 2ndQ, Bull, BONITASOFT, USTUTT


PgCloud, PostgreSQL, Saladdin, JOnAS, BOS, Apache ServiceMix, Context Integration Framework (CIF)


F#WP2.* and F#WP3.*


The realisation is based on the features and outcomes of WP2 and WP3. Thus, these have to be in place.

Risks n/a

Effort High


3. Conclusion

In this document, we first provided an overview of the implementation status of the requirements defined in the second iteration of the requirements elicitation as documented in the resubmission of D1.1.2b [2]. In addition to this, we gave an update on the feature planning for the next release. Since this is the last iteration of this deliverable, this constitutes the final set of features planed for implementation by the corresponding work packages. The progress of these features will from now on be reported as part of the upcoming integration reports D1.3.2 and D1.3.3.

Since the experimentation results and report was not available at the time writing this deliverable, the content has to be considered preliminary. The final version will be handed in as soon as the experimentation reports are available.


4. References

[1] 4CaaSt Description of Work

[2] 4CaasT Consortium. D1.1.2b Analysis of the State of the Art and Definition of Requirements - Resubmission. March 2012.

[3] 4CaasT Consortium. D1.3.1 Integration of Results. April 2012.

[4] 4CaasT Consortium. D4.1.2 Scientific and Technical Report. June 2012.

[5] 4CaasT Consortium. D8.1.1 Scenario Definition: eMarketplace (Resubmission). February 2011.

[6] 4CaasT Consortium. D8.2.1 Scenario Definition: Mass Market (Resubmission). February 2011.

[7] 4CaasT Consortium. D8.3.1 Scenario Definition: Public/Private Cloud (Resubmission). February 2011.

[8] ITIL (IT Infrastructure Library): ITIL Version 3 - Service Improvement. URL: http://www.itil-officialsite.com

[9] SLA@SOI Glossary, URL:http://sla-at-soi.eu/wp-content/uploads/2008/12/[email protected], SLA@SOI project. 2010.

[10] Ken Schwaber, Mike Beedle: Agile Software Development with Scrum. Prentice Hall, Upper Saddle River 21. October 2001.

[11] 4CaaSt Consortium: D7.2.2 Immigrant PaaS Technologies: Components Design and Open Specification, Version 1.0, July, 2012.


Annex A. Requirements Elicitation Approach

4CaaSt will use an agile development process. This is already instantiated in the DoW with three macro iterations or evolutions (M14/M20; M26/M32 M39/M39) with planned micro iterations or sprints within the macro iterations. Figure 1 illustrates the requirements elicitation process we follow in 4CaaSt for each of the macro iterations.

Figure 1: Requirements Elicitation Process

The requirements elicitation process starts with gathering requirements within the WP 8 evaluation scenarios as well as specifying platform features within the scientific WPs as independent activities running in parallel.

The different business requirements for the WP 8 evaluation scenarios are identified and specified in terms of S-Cube Use Cases, while the different platform features are captured and maintained using a central predefined spreadsheet. In both cases, we consider feedback from business users as for example the BAC, the current State Of The Art (see Deliverables D{2-7}.1.1) as well as experiences gained from the architecture and components design work (see Deliverables D{2-7}.2.1)), which has influence on the priorities of use cases and platform features.

Annex B.1 provides a compact overview of all specified S-Cube Use Cases, which all reuse the User Roles introduced in D1.1.2b [2] to define the involved actors. For more details on the S-Cube approach and a full specification of the Use Cases please refer to the respective WP8 deliverables [5][6][7].

Having defined an initial set of WP 8 requirements and proposed a first set of WP-specific platform features we enter a mapping and consolidation phase. Scenario and WP leads discuss the relationship between scenario Use Cases and platform features until a complete mapping has been reached, i.e.

every platform feature is demonstrated and evaluated in at least one scenario

each use case uses at least one platform feature.

WP 8 Requirements

(S-CUBE Use Case Specs)

Business

Feedback

State of the

Art &

Added

Values

WP 2-7

Platform Features

WP Feature / Component

Mapping

Use Case / Feature

Mapping

WP Architecture


Finally, the scientific WPs develop a technical architecture for implementing the features and provide a mapping between the components of this architecture and the technical features they offer to the industrial scenarios.

Annex B. Use Case / WP Features Mapping

B.1. Scenario Use Cases

This section provides an overview to the WP 8 evaluation scenario requirements defined in terms of S-Cube Use Cases. For more details on the different Use Cases please refer to the corresponding WP 8 deliverables [5][6][7].

4.1. Scenario 8.1 – eMarketplace

Use Case ID Short Description

UC.8-1.001 Offer new service


UC.8-1.003 Rating and Charging

UC.8-1.004 Revenue sharing

UC.8-1.005 Service Specification

UC.8-1.006 Publish Service

UC.8-1.007 Deploy Service (and operate Service)

UC.8-1.008 Rate Service

UC.8-1.009 Distribute revenue shares

4.2. Scenario 8.2 – Mass Market


UC.8-2-001 Develop cloud enabled software component

UC.8-2.002 Deploy Software in the marketplace for commercialization

UC.8-2.003 Commercialise Service provided by software

UC.8-2-004 Choose service in the marketplace

UC.8-2-005 Buy service from the marketplace

UC.8-2-006 Enforce SLA

UC.8-2.007 Enforce metering

4.3. Scenario 8.3 – Public/Private Cloud


UC.8-3.001 Provide a Software to 4CaaSt


UC.8-3.002 Create Service from Software


UC.8-3.004 Use records management solution (private and public parts)

B.2. Mapping to Work Package Features

The following table provides an overview to the mapping of features to Use Cases within the different evaluation scenarios. A table entry below indicates that a Use Case requires the given feature. Note that for some features the final mapping is still pending since, at the time of writing, some feature implementations have not been available and some scenarios have not been able to reach a final agreement on suitable use cases.

Moreover, some of the features are being discussed in the scope of the scientific WPs in terms of their scientific interest and the requirements posed by the evaluation scenarios. As a result, some features may not be included in the final prototype.

Feature Id

Feature Name 8.1 Use Cases 8.2 Use Cases 8.3 Use Cases

F#WP2.01 Support the design of a cloud enabled solution

UC.8-1.001:Offer new service



F#WP2.02 Empower cloud Developers




F#WP2.03 Break the Monolithic Cloud and avoid vendor lock-in


- -

F#WP2.04 Resolution of Service Requirements


- -

F#WP2.05 Cloud Offering Orchestration

UC.8-1.007: Deploy Service (and operate Service)

- -

F#WP3.01 Product Definition


UC.8-1.005:Service Specification





UC. 8-3.002 Create Service from Software


F#WP3.02 Product Search UC.8-1.002 Contract service



F#WP3.03 Bid search - - -

F#WP3.04 Related Products - UC.8-2-004 Choose service in the marketplace

-

F#WP3.05 Recommendation - UC.8-2-004 Choose service in the marketplace


F#WP3.06 Advertising - UC.8-2-004 Choose service in the marketplace

-

F#WP3.07 Community Rating & Comments

- UC.8-2-004 Choose service in the marketplace

-

F#WP3.08 Social Graph Analysis

- UC.8-2-004 Choose service in the marketplace


F#WP3.09 Product Resolution


UC.8-2-005 Buy service from the marketplace.


F#WP3.10 Product Specification

UC.8-1.005 Service Specification






F#WP3.11 Product Customisation






F#WP3.12 Bid to Product - - -

F#WP3.13 Basket Management

- 8-2-005 Buy service from the marketplace

-


F#WP3.14 Contract Management

- 8-2-005 Buy service from the marketplace

-

F#WP3.15 Delivery Support UC.8-1.007: Deploy Service (and operate Service)




F#WP3.16 Payment Support - 8-2-005 Buy service from the marketplace

-

F#WP3.17 Pricing & Charging

UC.8-1.003: Rating and Charging

UC.8-1.004: Revenue sharing

UC.8-1.008: Rate Service

UC.8-1.009: Distribute revenue shares



-

F#WP3.18 Show Competitive Products

- - -

F#WP3.19 Reporting on products, incomes, etc

- - -

F#WP3.20 Simulations - - -

F#WP3.21 User Management


UC.8-1.002: Contract service







F#WP3.22 Business Management






F#WP4.01 Deployment of applications over a platform


- -

F#WP4.02 Automated Application Elasticity

- UC.8-2-006 Enforce SLA


F#WP4.03 PaaS API UC.8-1.007: Deploy Service (and operate Service)



F#WP4.04 IaaS Aggregated API


- -



- -

F#WP4.06 OVF Extensions (required)


- -

F#WP4.07 Improved network configuration for applications


- UC.8-3.003 Solution Provisioning & Operation for private/public components

F#WP5.01 PIC Administration

UC.8-1.002 Contract Service or/and UC.8-1.007: Deploy Service (and operate Service)

UC.8-2-005 Buy Service


F#WP5.02 Monitoring infrastructure: Set up and configure probes


UC.8-2.006 Enforce SLA




UC.8-1.003: Rating and Charging and/or UC.8-1.008 Rate Service

UC.8-2.005 Enforce SLA


F#WP5.04 Metering Capabilities



-


F#WP5.05 Monitoring analysis

- - UC.8-3.003 Solution Provisioning & Operation for private/public components

F#WP5.06 Accounting framework

UC.8-1.003: Rating and Charging

- -

F#WP6.01 Pub/Sub communication channel

- - -

F#WP6.02 Mashups catalogue

- UC.8-2-001 Develop cloud enabled software component

-

F#WP6.03 Mashup platform - UC.8-2-001 Develop cloud enabled software component

-

F#WP6.04 Mashups as building blocks


-

F#WP6.05 Location Context Provider



-

F#WP6.06 Context Manager UC.8-1.007: Deploy Service (and operate Service)


-

F#WP6.07 Context Consumer API



-

F#WP6.08 Scalability of Data Store as a Service

- UC.8-2-006 Enforce SLA

-

F#WP6.09 Simple API for Data Store as a Service


-

F#WP6.10 Standardised API for Data Store as a Service


-

F#WP6.11 Integrated telco services



UC. 8-3.004 Use Solution

F#WP7.01 Support for Various Communication Protocols


- -


F#WP7.02 Support for non-tenant-specific Service Requests and Responses


- -

F#WP7.03 Message transformations for ESB normalized format


- -

F#WP7.04 Tenant-aware Routing


- -



- -

F#WP7.06 Abstraction from the Context Provisioning Systems


- -



- -

F#WP7.08 Support for BPMN2 Correlation

- UC.8-2-001: Develop cloud enabled software component

-

F#WP7.09 Dynamic Reload of Dependencies

UC.8-1.001: Offer new service

- -





F#WP7.11 Application Server Deployment Features


UC.8-2-001 Develop Cloud enabled software component



F#WP7.12 Database Scalability

- - -


F#WP7.13 Synchronous replication



F#WP7.14 Power reduction UC.8-1.007: Deploy Service (and operate Service)


F#WP7.15 Database-independent scalability API

- - UC.8-3.003 Solution Provisioning & Operation for private/public components

F#WP7.16 Built on standards


UC.8-2-001 Develop Cloud enabled software component


F#WP7.17 Multi-tenancy Support



F#WP7.18 Monitoring capabilities (solution specific)


UC.8-2-005 Buy service UC.8-2-006 Enforce SLA UC-8.2-007 Enforce metering


F#WP7.19 Horizontal scalability support




Documents

Analysis of the State of the Art and Definition of Requirements … · 2017-04-20 · contained in the blueprint repository Scenario Evaluation results / feedback Plans for future