analysis of the state of the art and definition of ... · d1.1.3 (b) version 2.0 wp1 – definition...

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

Building the PaaS Cloud of the Future

Analysis of the State of the Art and Definition of Requirements

D1.1.3 (b)

Version 2.0

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

Dissemination Level: Public

Lead Editor: Christof Momm

21/12/2012

Status: Final (Resubmission)

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

Ref. Ares(2013)113918 - 30/01/2013


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)

Rouven Krebs (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

1.01 21/11/12 Christof Momm (SAP) Original version 1.0 with template for additional contributions.

1.02 22/11/12 Christof Momm (SAP) Changed template according to WP1 call.

1.03 23/11/12 Christof Momm (SAP) Added example for WP4 Deployment Feature.


1.04 6/12/12 Christof Momm (SAP) Changed template to capture status of new features as well

1.05 11/12/12 Christof Momm Revised Summary/Conclusion + integrated contributions from WP3, WP4 and WP5

1.1 14/12/12 Rouven Krebs Integrated contributions WP2 and WP6

1.1.1 20/12/12 Rouven Krebs Integrated Reviewer Comments

1.2.0 21/12/12 Rouven Krebs Final Version


Table of Contents

Executive Summary .............................................................................................................10

1. Technical Feature Implementation and Evaluation Status – Release 1 / Review ..........11

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

1.2. WP 3 – Marketplace ..............................................................................................15

1.2.1. Information Phase .........................................................................................15

1.2.2. Negotiation Phase .........................................................................................21

1.2.3. Contracting Phase .........................................................................................23

1.2.4. Delivery Phase ..............................................................................................25

1.2.5. Marketplace Analytics ...................................................................................27

1.2.6. Marketplace Management .............................................................................29

1.3. WP 4 – Resource Deployment and Management ..................................................30

1.4. WP 5 – Administration, Accounting, Monitoring and Analytics ...............................39

1.5. WP 6 – Native PaaS Technologies .......................................................................46

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

2. Feature Changes Release 2/3 + Implementation Status new Features .........................71

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

2.1.1. Change Overview ..........................................................................................71

2.1.2. New Technical Features ................................................................................72

2.2. WP 3 – Marketplace ..............................................................................................72

2.2.1. Change Overview ..........................................................................................72


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

2.3.1. Change Overview ..........................................................................................75


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

2.4.1. Change Overview ..........................................................................................80


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

2.5.1. Change Overview ..........................................................................................81


2.1. WP 7 – Immigrant PaaS Technologies ..................................................................83

2.1.1. Change Overview ..........................................................................................83


3. Conclusion ....................................................................................................................98

4. References ...................................................................................................................99


Annex A. Requirements Elicitation Approach ................................................................. 100

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

B.1. Scenario Use Cases ........................................................................................... 101

4.1. Scenario 8.1 – eMarketplace............................................................................... 101

4.2. Scenario 8.2 – Mass Market................................................................................ 101

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

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


List of Figures

Figure 1: Requirements Elicitation Process ........................................................................ 100


Abbreviations

API Application Programming Interface

AWS Amazon Web Service

BCL Blueprint Constraint Language

BDL Blueprint Definition Language

BML Blueprint Manipulation Language

BPEL Web Services Business Process Execution Language

BQL Blueprint Query Language

CRM Customer Relationship Management

DMTF Distributed Management Task Force, inc.

EC European Committee

ECP Elastic Cloud Platform

IaaS Infrastructure as a Service

IT Information Technology

IU Installable Unit

KPI Key Performance Indicator

LTL Linear Temporal Logic

MDE Model Driven Engineering

OASIS Organization for the advancement of Structured Information Standards

OCCI Open Cloud Computing Interface

OVF Open Virtualization Format

PaaS Platform as a Service

QoS Quality of Service

RP2 The second reporting period

SaaS Software as a Service

SBA Service Based Application

SCA Service Computing Architecture

SDD Solution Deployment Descriptor

SLA Service Level Agreement

SM Service Manager

SOA Service Oriented Architecture


SOAD SOA Analysis/Design Modelling

SOAF SOA Framework for service definition and realization

SOCCA Service Oriented Cloud Computing Architecture

SOMA Service Oriented Modelling and Architecture

SOMF Service Oriented Modelling Framework

UUID Universally Unique IDentifier

VEE Virtual Execution Environment

VM Virtual Machine

VMAN Virtualization Management

VPDC Virtual Private Data Center

WP2 Work Package 2 (of 4CaaSt Project)

XaaS Everything as a Service

XCP Xen Cloud Platform

XML Extensible Markup Language

4CaaSt Building the PaaS Cloud of the future


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 resubmission of the third and final iteration.

Compared to the previously submitted version, this version now includes and considers the feedback from the WP8 experimentation. In addition to this, we provide an update of the implementation status as well as release 2/3 planning based on the version of the 4CaaSt platform presented at the second project review November 7/8.

Accordingly, the report 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 for the version presented at the review, a summary of the experimentation feedback from the use cases regarding release 1 and a specification of the plans for release 2 and 3, both taking 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). In addition to this, we provide a brief summary of the implementation status for these new features for the review version of the 4CaaSt platform.

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 / Review

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 report on the implementation progress. The progress is reported for the platform implementation that has been presented at the second project review Nov 7/8. This includes 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, including an update on the status of release 2, which is currently being developed.

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. This 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

8.1, 8.2 & 8.3 Adoption

The blueprint language has been adopted by all the components of the project and has been integrated into the scenarios.

8.1 Feedback


No metering information, difficulties in visualizing and editing blueprints

8.2 Feedback

Request for extension of the language for defining monitoring information

8.3 Feedback

Difficulties in visualizing and editing blueprints

Implications

The blueprint language is not expressive enough.

Plans for future releases / Implementation status release 2

Implementation status

Version 2.02 of the blueprint language has been provided taking into account the needs of the scenarios.

Graphical visualization of the XML language has been provided.

Plans for release 3

Version 3.0 is planned taking into account the new requirements of the scenarios, no major changes are foreseen at the moment.

F#WP2.02 Empower cloud Developers Major

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

Responsible Partner


In Progress


A visualization 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, allowing to build programs that update information contained in the blueprint repository


8.1, 8.2 & 8.3 Adoption

Only the blueprint language was ready at the time of the evaluation, no support of editing and manipulating information.

8.1 Feedback

Language Used in the development phase of the blueprints

8.2 Feedback


8.3 Feedback



Implications

None



The APIs and the editing graphical user interface have been extended and developed.

Plans for release 3

continuous support for the developed tools

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 generic offerings and requirements.

APIs combining blueprints coming from different vendors have been provided.


8.1, 8.2 & 8.3 Adoption

Combination and orchestration of the services have been designed into the language. At the time of the evaluation the resolution process was not in place.

8.1 Feedback

It as been tested and evaluated in combination with feature W2.01

8.2 Feedback


8.3 Feedback


Implications

None



Working version has been provided in the second iteration

Plans for release 3

Integration and porting to the new version of the blueprint

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.


8.1, 8.2 & 8.3 Adoption

not ready at the time of the evaluation

8.1 Feedback


8.2 Feedback


8.3 Feedback

Implications

None



Version 1.0 has been implemented and integrated in the scenarios during the second period

Plans for release 3

Update the resolution with the new version of the blueprint language

improve service filtering and selecting based on the 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.


8.1, 8.2 & 8.3 Adoption

The WS-I compliant interface for accessing the information was too simple for being evaluated and the resolution engine was not yet implemented.

8.1 Feedback


8.2 Feedback



8.3 Feedback

Not ready at the time of the evaluation

Implications

None



Interface and implementation have been provided and integrated into the scenarios at the end of the second period

Plans for release 3

Improvement of the functionality of the WS-I compliant interface.

Porting to the 3rd iteration of the blueprint language

Improving the matchmaking process between offering and requirements

1.2. 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 to the marketplace:

Marketplace Analytics

Marketplace Management

1.2.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.


8.1, 8.2 & 8.3 Adoption

All the components belonging to these scenarios as well as the Taxi Application, the Tourist Application and Service and the Records Management Application have been properly described by means of blueprints. All these components and services have then been published in the 4CaaSt Marketplace without significant effort.

This publication encompasses the assignment of a price model and a set of other business parameters like availability, security, etc. to each component and the applications themselves.

8.1 Feedback

Extensions to the blueprint model are required to deal with service-specific metering and monitoring information. The 4CaaSt marketplace should be able to deal with this information when defining price models.

The navigability and intuitiveness of the 4CaaSt Marketplace user interface could be improved.

8.2 Feedback

Extensions to the blueprint model are required to deal with service specific metering and monitoring information. The 4CaaSt marketplace should be able to deal with this information when defining price models.

Service providers should be able to specify SLA parameters based on KPI constraints.

8.3 Feedback

Concerns have been expressed about describing services adequately, as well as the marketplace navigation.

Implications

User experience is out of the scope of the project so no further work on marketplace navigability is planned.

Metering information has been added to the blueprint template in RP2.



Additional product parameters have been included in the product definition user interface:

o Reliability


o License type

o Energy Category

o Quality Assurance

o Customer Support

o Customization

Extensions to the blueprint model to deal with metering and monitoring information have been added (see feature F#WP3.24)

Plans for release 3

Handling of additional SLA parameters if required.

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

Closed


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

o Free Text Search


8.1, 8.2 & 8.3 Adoption

The Marketplace provides a free text search which could be successfully used to find the Taxi Application, the Tourism application and service and the Records Management Application. It can also be used to find the constituent components.

Once found, the customer can get detailed information about each product.

8.1 & 8.3 Feedback

Enhanced search has been identified as a relevant additional


feature.

8.2 Feedback

The availability of products ratings and comments from other users would be a valuable feature for customers.

Implications

Additional search methods would be an important enhancement.



Ratings and comments from other users are shown when accessing information about a product (see feature F#WP3.07).

Plans for release 3

Currently there are no plans to extend this feature.

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

N/A Feature Status

Cancelled


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

Closed


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.


Not explicitly evaluated.

No feedback available.




No changes since RP1.

Plans for release 3


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.08).

Responsible Partner

N/A Feature Status

Partially Cancelled; Rest moved to F#WP3.008


Theoretical research has been done and is being continued.

At the time of writing this deliverable, there are plans to focus on recommendation based on social data. This will be reported as part of feature F#WP3.008.

Recommendations based on the service consumer‘s user profile or purchase history are not in focus of HSG`s research. This decision may change in the future based on the requirements brought in by the application scenarios defined by the project.

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

Cancelled



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.



Not evaluated in release 1.



Service consumers can rate and comment products they have contracted in the marketplace.

Other users and service providers can view this information as part of a product description and by means of graphical reports on ratings per product.

Average product ratings are used in the business resolution process (see feature F#WP3.09).

Plans for release 3

Rating & Comments information can be used to implement social enhancements.

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 a social graph in business environments, 2. Applications of social data in electronic marketplaces.


8.3 Adoption

Social Enhancements have been discussed with experts

Ideas for social enhancements have been collected

8.3 Feedback

Information unique to social data, cannot be obtained elsewhere

Requires quality data base, sufficient marketplace size

Possible misuses of data

Implications

Based on the positive feedback during expert interviews, social enhanced features will be in focus for review period 3.


Plans for release 3

Within the next release, 4CaaSt will be enhanced by Social Analytics, which will be part of the Business Model Component.


F#WP3.24 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

Closed


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.


8.1 Adoption

Definition of Price Models, incl. Metering Information

Simulation of Price Models

Aggregation of Price Models

8.1 Feedback

All service providers are thought to find eMP attractive

Particularly small companies can profit

Long-term developments: increased competitiveness, falling profits

Implications

Feature is completed; - only minimal Bugs have to be fixed.


While the first release already allowed the definition and management of price models, the second release is able to deal with metering information, defined as part of the blueprint. 4CaaSt Release 2 is the final release for Price Model Management.

1.2.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.

A customer request is resolved into products or product compositions and the characteristics of each final product are identified. The marketplace enables the selection of the most appropriate product among those offered.

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.

Scenario It is mostly used in 8.1 demo.


Evaluation results / feedback

The resolution works well only if all the components works. So the resolution needs the Price Aggregator the marketplace and the technical resolution from WP2.


The resolution should take into consideration more parameters from the user profile.

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

Closed


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


Not explicitly evaluated by any scenario.




Plans for release 3


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

N/A Feature Status

Cancelled




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

N/A Feature Status

Cancelled



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 Partner

TID Feature Status

Cancelled




None.


Discarded feature.

1.2.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


4CaaSt customers can contract products published in the 4CaaSt marketplace. They can also specify business constraints to be applied during the contracting process.

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


8.1, 8.2 & 8.3 Adoption

The Taxi Application, the Tourist Service and the Records Management Application can be contracted by 4CaaSt customers.

o In addition, the Taxi Application includes a set of components that are selected based on the user request.

8.1 Feedback

The 4CaaSt marketplace is perceived as an effective and attractive solution since it helps users search and find composed services while hiding the contracting complexity beneath.

In general, learnability of the contracting process is considered positive. However some concerns are raised about learnability for end users.

The intermediary role between consumers and service providers is regarded as a plus because contracts happen via the 4CaaSt marketplace and not directly between the consumer and the service providers, thus simplifying the full process.

8.2 Feedback

Some customer may choose stronger SLA constraints than others and thus be charged different prices.

8.3 Feedback

None.




Plans for release 3

The impact of SLA parameters on price should be taken into account (see F#WP3.24).


1.2.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.


8.1, 8.2 & 8.3 Adoption

Once contracted, the 4CaaSt marketplace triggers the deployment of the Taxi Application, the Tourist Service or the Records Management Application on the 4CaaSt cloud.

8.2 Specific

o Unlike scenarios 8.1 and 8.3, this scenario does not deploy a software instance per customer but grants users access to an already deployed SaaS.

o Provisioning of the service is done via the SaaS provisioning API, and the user is granted access to the service.

8.1 Feedback

None.

8.2 Feedback

Generic handling of SLA/KPI parameters should be available.

8.3 Feedback

Additional customer SLA parameters are required from the marketplace to select the most appropriate deployment design:

o Reliability

o Responsiveness

o Work load



Additional customer SLA parameters are passed to the deployment component:

o Reliability

o Responsiveness

o Work load

Extended 4CaaSt_Id, including:


o domain

o customer_id

Plans for release 3

Include additional SLA parameters if needed.

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


Not available in RP1.


Not evaluated yet.



Generation of customer bills as pdf files based on information provided by the Settlement Component.

Customers can access their bills from the marketplace frontend.

Plans for release 3

No further changes are planned.

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

Closed


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.

Scenario Evaluation results /

8.2 Adoption

Definition of Price Models, incl. Metering Information


feedback Charging based on contracts, prices and usage data.

Charging component sends Charging Data Records (CDRs) to Settlement Engine

8.2 Feedback

Charging Component displays correct CDRs

Settlement Engine sends positive Acknowledgments

Implication

Feature is completed; - only minimal Bugs have to be fixed.


In 4CaaSt release 2, the Charging Component has been implemented, and works as specified. No further releases planned.

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, incomes have to be distributed among them, including revenue sharing policies if they have been defined.

Responsible Partner

TID Feature Status

In Progress


Not available in RP1.


Not evaluated yet.



Generation of customer billing data based on charging information provided by the Charging Component.

Plans for release 3

Storage of charging information in the Settlement Repository.

Revenue distribution to the different stakeholders involved in the delivery of a product.

1.2.5. Marketplace Analytics

F#WP3.18 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 used by other 4CaaSt components.


Not explicitly evaluated by any scenario.-



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




8.1, 8.2 & 8.3 Adoption

Not integrated yet

8.1 & 8.3 Feedback

Additional analytic tools and feedback mechanisms would be highly appreciated.

8.2 Feedback

None



A graphical reporting tool allows users of the 4CaaSt marketplace to access relevant information, e.g. Platform usage, products, contracts, etc.

This tool is based on HTML5 and can thus be used from different types of devices (PCs, tablets, smartphones) and operating systems (iOS, Android).

Plans for release 3

Customized user reports

Reports on incomes, revenue distribution, etc.


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




8.1 Adoption

Simulation of different Price Models

Simulation of Cost & Revenues

Estimation of usage functions, depending on price

8.1 Feedback

All service providers are thought to find eMP attractive

Particularly small companies can profit

Long-term developments: increased competitiveness, falling profits

Implications

Price Model Simulation is completed.



Two kinds Simulations have been implemented in release 2: First the Price Model Simulation and second the Business Model Simulation.

Price Model Simulation has been evaluated and improved within the last iteration.

Plans for release 3

Business Model Simulation will be extended until the final release of 4CaaSt.

1.2.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

Closed


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


8.1, 8.2 & 8.3 Adoption

Used in the three scenarios to manage marketplace users.

Different roles are available: service providers, marketplace administrators and customers.

8.1, 8.2 & 8.3 Feedback

None.




Plans for release 3


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.


Not evaluated yet.

Note there is a specific feature for price model management (F#WP3.24) while this one will mainly focus on the management of revenue sharing models (see F#WP3.23).



Management of revenue sharing models is already implemented but has not yet been fully integrated in the 4CaaSt platform.

Plans for release 3

Integration of revenue sharing models.

1.3. 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


8.1 Adoption

Automated deployment using predefined static OVF used (UC.8-1.007)

Integrated with marketplace.

8.2 Adoption

N/A

8.3 Adoption

Automated deployment using predefined static OVF used (UC.8-3.003)

8.1 Feedback

Deployment automation working reliably, but…

o Chef scripts are not modular + reusable so far so that automation requires significant effort

o Complexity of Taxi application stack so high that dynamic deployment resolution probably very difficult to achieve (if at all)

o Deployment rather slow when using PIC-in-PIC deployments (in particular Orchestra on Tomcat

o Configuration of application components (ACs) not supported so far

o Architecture of taxi application itself should be simplified

8.2 Feedback

Instead of full deployment, the WP4 deployment has to support a


SaaS user provisioning for UC.8-2-005

Configuration of monitoring probes has to be supported for enabling elasticity + accounting (UC.8-2-005)

8.3 Feedback

Full automation ideally without any need to add application specific installation scripts should be targeted for all future releases

Deployment design should consider specification of elasticity rules, which are handled automatically by the platform

Each 4CaaSt component should provide reusable and composable enabler Chef scripts to lower effort for deployment automation

Infrastructure sizing should be supported

Implications

Design guidelines for reusable+composable Chef enabler scripts required (R1)

Approach for handling complex architectures required (R2)

AC configuration has to be supported (R3)

SaaS user provisioning has to be supported (R4)

Support infrastructure sizing (R5)

Support specification of elasticity rules (R6)

Support for performing automated monitoring configuration required (R7) New Feature F#WP4.08



New Resource Requirements Calculator [NTUA] supporting the evaluation of resource requirements for given QoS constraints (R5).

Extensive re-design of Deployment Design Manager [SAP] to support generation + evaluation of different (elastic) designs (R6) and provisioning of SaaS users (R4)

Developed + distributed design guidelines for Chef enablers (R1) WP6/WP7 has to address development of scripts!

Developed concept for AC configuration + Intial implementation (R3)

Open issues for release 2

Finalize all required Chef enabler scripts to properly demonstrate switching of components WP6/7

Finalize simple generation of elastic deployments (R6)

Finalize AC configuration (R3)

Plans for release 3

Advanced generation of elastic deployments (R6)


Develop approach for handling complex architectures (R2)

Add support for mixed component/service deployments also related to R2

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


Not implemented in release 1


Elasticity is not evaluated in release 1.



Implementation of the execution of elasticity rules at the Service Manager Level, by cloning of virtual machines.

Usage of Platform level KPIs.

Generation of VM images after software stack generation for cloning nodes.


Synchronization of PaaS Manager and Service Manager for scale up/ scale down.

Plans for release 3

Integration of elasticity with monitoring analytics (predictions, ranges of normality).

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







Specification and implementation of an API for management of the catalogue of products.

Specification and implementation of the API to deploy applications.

Specification and implementation to support queries to the deployed resources.


Specification and implementation of the API to deploy applications over different environments.

Plans for release 3

Configuration and application management APIs (start, stop).

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.

Scenario Evaluation results /

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


feedback Flexiscale Cloud provider.

8.1 & 8.3 Feedback

No specific issues of the evaluation of scenario 8.1 can be associated to the IaaS Aggregated API, beyond the fact that it worked for Flexiscale and it was not available for Open Nebula.

Implications

Requirement to support OpenNebula


Implementation Status

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

Plans for release 3

Integration of NaaS if required at the IaaS Aggregated API level.

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.


8.1 Adoption

Chef cookbook(s) written for Taxi application, note that AC and PIC management not yet separated in cookbooks.

8.2 Adoption

N/A

8.3 Adoption

N/A

8.1 Feedback

Deployment automation working reliably, but…

o Chef scripts are not modular + reusable so far so that automation requires significant effort

o Deployment rather slow when using PIC-in-PIC deployments (in particular Orchestra on Tomcat

o Configuration of application components (ACs) not supported so far

8.2 Feedback

Instead of full deployment, the WP4 deployment has to support a SaaS user provisioning for UC.8-2-005

Configuration of monitoring probes has to be supported for enabling elasticity + accounting (UC.8-2-005)

8.3 Feedback

Full automation ideally without any need to add application specific installation scripts should be targeted for all future releases

Each 4CaaSt component should provide reusable and composable enabler Chef scripts to lower effort for deployment automation

Implications

1. Design guidelines for reusable+composable Chef enabler scripts required (R1)

2. Approach for handling complex architectures required (R2)

3. AC configuration has to be supported (R3)

4. SaaS user provisioning has to be supported (R4)

5. Support for performing automated monitoring configuration required (R7) New Feature F#WP4.08

(Note that REC Manager design supports 1-3, however, lack of time and steep Chef learning curve prevented the development of proper Chef Cookbooks. So, the actual steps needed are not so much the redesign of the feature (although some improvements are required) but to put more effort into conveying the existing design guidelines to the partners developing the cookbooks.)




End-to-end forwarding all artifacts, cookbooks and attributes (see 1 and 3 above)

Service deployment support (see 4 above)

Monitoring deployment support (see 5 above)

Plans for release 3

Support for template images (see 2 above)

Support for complex deployment cases, e.g. PIC-in-a-PIC and combined PICs (see 2 above)

F#WP4.06 OVF Extensions 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


8.1 Feedback

Limitation to support variations of deployments in the interface (different sets of PICs).

8.2 Feedback

Limitation to support services provisioning.

8.3 Feedback

NaaS Support


Implications

Need to support Virtual Services (service provisioning) (R1)

NaaS Support specification in the OVF++ (R2)



Virtual Service support implementation (R1).

Plans for release 3

Extensions to support NaaS specification (R2).

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







Support of creation of virtual LANs on a point-to-point basis

Support of bandwidth in path computation

Automatic topology discovery


Support of configuring virtual and HW switches (OF1.0) end-to-end

GUI to display virtual and physical topology and allocations

Basic link failover handling


No support for QoS parameters

Lack of routing via external router

Plans for release 3

OCCI based ―A‖ interface integrated with IaaS and service manager

Support of latency on both ―A‖ interface and in path computation

Routing of public IPs via external router

Creation of full mesh virtual networks on-demand with virtual network level QoS and bandwidth parameters

1.4. 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 2. Please note that the feature F#WP5.04 has not been addressed by this release.

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.


8.1 Adoption

Used for deployment/provisioning of services (UC.8-1.002 Contract Service and UC.8-1.007 Deploy Service)

Blueprints and cookbooks for PICs management have been provided

8.2 Adoption

Used in UC.8-2-005 (buy a service) at deployment phase


8.3 Adoption

N/A

8.1 Feedback

Blueprints and cookbooks have been provided for PICs involved in the scenario but the end to end deployment could not be achieved due to some issues related to error management in the Chef recipes processing and to some problems running the application on top of the targeted PICs (e.g. JOnAS).

Blueprints and cookbooks considered as an appropriate way to define monitoring configuration

8.2 Feedback

An AC probe has been implemented but is still not integrated in the deployment process (no blueprint definition)

8.3 Feedback

KPI and rules in Blueprints were missing for automated scalability

Implications

None for the feature by itself.



Feature now focused on deployment and configuration of PICs, ACs, and associated probes

Clarified relationship with WP4 (resource management) and WP7 (PICs). PICs management done automatically through WP4 Resource Manager and Chef Cookbooks

o PIC depl, undepl, start, stop, deploy AC, undeploy AC

Corresponding REST API developed for JOnAS (WP7)


More integration work needed to achieve end to end deployment based on cookbooks, and to have use cases working properly on 4CaaSt targeted PICs

Plans for release 3

Complete blueprints and cookbooks for remaining 4CaaSt components (PICs, ACs and Probes)

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.


8.1 Adoption

Used for monitoring set up (UC.8-1.002 Contract Service and UC.8-1.007 Deploy Service)

JASMINe Probe, the monitoring source for collecting Java/JMX information and collectd the monitoring source used to get platform related information have been installed and configured on the testbed.

8.2 Adoption


Used in UC.8-2-006 (enforce SLA) at deployment phase

8.3 Adoption

Collectd probes monitoring the infrastructure level used for scalability, but manually deployed

8.1 Feedback

Monitoring framework to deal with different kinds of probing system (JASMINe and Collectd) is OK

Automatic deployment of probes from KPI in blueprints, PIC and AC cookbooks could not be tested

8.2 Feedback

None

8.3 Feedback

KPIs missing in blueprint for this use case

Implications

The mechanisms are implemented but could not be entirely tested: KPIs applied to use cases should be defined and corresponding probes provided

KPIs in blueprints should allow automated management of probes by the 4CaaSt platform

Plans for future releases / Implementation


Integration of Probe Configuration and Deployment in the global


status release 2 4CaaSt deployment process

o KPIs in Blueprints

o Chef cookbooks used by the REC Manager (some recipes developed: a) for installing a collectd agent, b) for postgreSQL and MySQL probes, c) for a generic probe for JMX data gathering.

o Two monitoring sources handled (Collectd, JASMINe Probe)

Collectd: some adaptors developed

JASMINe Probe (for Java/JMX Probes): Development of a REST API

Plans for release 3

Integrate end to end probes deployment in use cases, from KPI definition in blueprint to Chef recipes and actual probe implementation

JASMINe Probe enhancement (distributed probes, console)

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


8.1 Adoption

JASMINe Probe, the monitoring source for collecting Java/JMX information, and collectd, the monitoring source used to get platform related information, have been installed and configured on the testbed.

8.2 Adoption


Used in UC.8-2-006 (enforce SLA) at deployment phase: a custom KPI probe in Scalaris using JMX technology has been implemented.

8.3 Adoption

Collectd probes monitoring infrastructure indicators are used for scalibility


8.1 Feedback

Monitoring framework to deal with different kinds of probing system (JASMINe and Collectd) is OK

8.2 Feedback

Custom probe that have been developed remains to be tested in a fully integrated process. KPI probe definition in the application blueprint not provided yet

8.3 Feedback

OK, but the probe were manually deployed, should now be integrated in the automated deployment process

Implications

The platform should use the KPI definition in blueprint to set up automated deployment and management of probes



Integration and enhancements of monitoring sources

o JASMINe Probe: new OSGi based architecture and implementation for a modular, extensible and adaptable collecting system

o Collectd: Extension through plugins development

Monitoring data structure definition

Enhanced dashboards built using mashup as a service

Improved performance of Pub/Sub component SilboPS

Plans for release 3

Finalize integration in WP4 deployment and resource management processes

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

Scenario Evaluation

N/A


results / feedback


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


8.1 Adoption

N/A

8.2 Adoption

N/A

8.3 Adoption

N/A

8.1 Feedback

N/A

8.2 Feedback

N/A

8.3 Feedback

N/A

Implications

N/A



Design and implementation of the analysis framework

Experimentation of NoSQL DB (HBase) and MapReduce

Several Data Analysis methods tested

Two new (periodic) operations implemented:

o Prediction: hourly estimating future values from past values


o Normality: daily calculate expected normal behaviour

Plans for release 3

Integration of analytics results with WP4 rules

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




8.1 Adoption

N/A

8.2 Adoption

An accounting plug-in for the Wikipedia renderer has been fully implemented and pushes an SDR to the accounting server for each page view (UC.8-2.007 Enforce metering)

8.3 Adoption

N/A

8.1 Feedback

N/A

8.2 Feedback

For this use case, missing the application description part specifying an accounting probe so that 4CaaSt platform is aware of it

8.3 Feedback

N/A



Redesign and implementation of the accounting framework: flexible, adaptable to any kind of services, scalable, multi-tenant.

Definition of the Service Detailed Record (SDR)

Blueprint definition for Accounting (in collaboration with WP3)

Plans for release 3


Integration of usage records from multiple 4CaaSt technologies, accounting agent enhancement

1.5. 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.


8.1 Adoption

N/A

8.2 Adoption

Not adopted in RP1 but planned and done for RP3

8.3 Adoption

N/A

8.1 Feedback

N/A

8.2 Feedback

N/A

8.3 Feedback

N/A

Implications

N/A



Stable distributed implementation of the pub/sub service, including the distributed routing algorithm. Advertise messages supported and automatic unadvertisement/unsubscription. New binary


communication protocol has brought performance increase.

Plans for release 3

Implement memory caching of messages and historical retrieval of messages

Automatic scaling

Full support for tenant provisioning

Monitoring and charging of platform usage

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


8.1 Adoption

N/A

8.2 Adoption

Widgets created are stored in mashup platform catalogue, as part of UC.8-2.001

8.3 Adoption

N/A

8.1 Feedback

N/A

8.2 Feedback

Successful development of prototype using this feature

8.3 Feedback

N/A

Implications

N/A



Integration with WP4 support by the API to inject widgets/mashups into the internal catalogue of a running instance

Plans for release 3


Tenant-based internal catalogue of resources in an execution environment

Viability of displaying marketplace blueprints of widgets/mashups

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


8.1 Adoption

N/A

8.2 Adoption

Application interface served through the mashup platform, as part of UC.8-2.001

8.3 Adoption

N/A

8.1 Feedback

N/A

8.2 Feedback

Successful development of early prototype using this feature.

8.3 Feedback

N/A

Implications

N/A



Finalized the module architecture for extensions, created Pub/Sub connection as first plugin. Initial support for external provisioning.

SaaS provisioning offered for applications using mashups as a service


Plans for release 3

Full support for tenant provisioning and AC deployment

Monitoring and charging of platform usage

Automation of platform deployment/configuration

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 Partner

UPM Feature Status

In Progress


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.


8.1 Adoption

N/A

8.2 Adoption

Application interface created through several widgets composing a mashupped workspace, as part of UC.8-2.001

8.3 Adoption

N/A

8.1 Feedback

N/A

8.2 Feedback

Successful development of prototype using this feature

8.3 Feedback

N/A

Implications

N/A



Newest version of WDL (Widget Description Language) and MDL (Mashup Description Language) supported

Plans for release 3


Creation of 4CaaSt components from platform-created mashups, so as to be published on the marketplace.

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 Android terminals is provided.


8.1 Adoption

Offered a service involving location context (UC.8-1.001)

Provisioned the service at deployment (UC.8-1.007)

8.2 Adoption


8.3 Adoption

N/A

8.1 Feedback

Location was available to the application and integrated in it

8.2 Feedback

Successfully integrated into the application, more context providers to come and integrate

8.3 Feedback

N/A

Implications

N/A



Context provider gathers location information from different sources and publishes it to the Context management system. An Android application has been created as a context source, and a location simulator has been created for development purposes

Plans for release 3

N/A


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


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


8.1 Adoption



8.2 Adoption


8.3 Adoption

N/A

8.1 Feedback

Context information correctly delivered to the application

8.2 Feedback

Context information correctly delivered to the application

8.3 Feedback

N/A

Implications

N/A



Advanced User Profile has been created so as to support rich user definition

Plans for release 3

N/A

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 TI Feature closed


Partner Status


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.


8.1 Adoption



8.2 Adoption


8.3 Adoption

N/A

8.1 Feedback

Manual integration in Release 1, neither cookbooks nor monitoring probes could be evaluated. Automated deployment, monitoring and accounting must be provided so as to be evaluated

Deployment, monitoring and accounting to be developed on new featureF#WP6.12

8.2 Feedback

Deployment, monitoring and accounting to be developed on new feature F#WP6.12

8.3 Feedback

N/A

Implications

N/A



REST-like interface for publishing/retrieve context information to or from a Context Manager. Subscription-based interface for retrieving context information

Integration of access control fields into API, and integration with accounting architecture

Plans for release 3

N/A

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.


8.1 Adoption

N/A

8.2 Adoption

Involved in UC.8-2-006 to demonstrate scalability features. Created probes and declared in blueprint

8.3 Adoption

N/A

8.1 Feedback

N/A

8.2 Feedback

Scalaris successfully used in the application

Not used to evaluate full platform scalability since automatic scalability enforcing SLA to control horizontal scalability is not available until RP3

8.3 Feedback

N/A

Implications

N/A



Scalaris is able to scale out, adding and removing nodes to/from an existing Scalaris ring with a data migration algorithm that ensures maximum availability even under high load.

Load monitored through a micro-benchmark (and VM-load such as CPU/network)

Plans for release 3

Evaluation of scalability with dynamic scale-in/out operations under load


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.


8.1 Adoption

N/A

8.2 Adoption

Used in UC.8-2-001 (developing application artefacts)

8.3 Adoption

N/A

8.1 Feedback

N/A

8.2 Feedback

Successfully used in the ―Wiki on Scalaris‖ application.

8.3 Feedback

N/A

Implications

N/A



APIs available for Java, Python (2 & 3), Ruby and via JSON-RPC for any other language for e.g. reading/writing values, executing transactions etc.

API extended to support monitoring and management of Scalaris nodes

Connection pool and node discovery daemon for ease-of-use

Enhanced data manipulation tools (higher-level read-modify-write operations, e.g. appending to lists)

Executor service for better performance

Implementation of Enabler Interfaces


Plans for release 3

further enhancements based on 8.2 requirements, in particular the Wiki on Scalaris component

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.


This feature was not evaluated in RP2 as its delivery is planned for mid RP3


Integrate usage of this API in the development part of the tourism demo.

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.


Scenarios identified the need for a native API such as SMS, but feature was not available for evaluation as SMS has been scheduled and released in early RP3.


Integrate SMS messaging in tourism & taxi application

Demonstrate ease of integration in development use case of tourism scenario.


1.6. 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)


8.1 Adoption

As the extended ESB Apache ServiceMix has not been integrated in the first version of the scenario 8.1 prototype this feature could not be evaluated, but will be evaluated in the second evaluation round

8.2 and 8.3 Adoption

N/A


Implementation and integration status

Implementation of this feature has been integrated with the ESB extension to enable multi-tenant administration and management done for release two. Moreover the release two version of the ESB has been integrated as building block into the second release of the prototype of scenario 8.1 as demonstrated during RP2 review. Thus, this feature will be considered for next round of evaluation.

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




8.1 Adoption



N/A

Plans for future Implementation and integration status


releases / Implementation status release 2


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




8.1 Adoption



N/A




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 Partner


Closed




8.1 Adoption

As the extended ESB Apache ServiceMix has not been integrated in the first version of the scenario 8.1 prototype this feature could not be evaluated, but will be evaluated in the second evaluation


round


N/A




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




8.1 Adoption

CIF is either offered with 4CaaSt internal CaaS or 4CaaSt external Google Maps Web Services as Context Provisioning Systems (UC.8-1.001)

During deployment and offering of Taxi Service within the 4CaaSt platform CIF is integrated and interacting with both CaaS and Google Maps Web Services as Context Provisioning Systems (UC.8-1.007)


N/A

8.1 Feedback

CIF works perfectly, but there are two open issues regarding both the integration with the scenario 8.1 prototype as well as the 4CaaSt platform

o In the first version of the scenario 8.1 prototype point-to-point connections were used for integrating the different components. This has to be improved in order to avoid tight coupling and aim at a flexible integration solution.

o The first version of the CIF building block has been manually integrated in the platform. Thus, the CIF blueprints and Chef cookbooks and receipts are to be evaluated in the next round of evaluation.

Plans for future Implementation and integration status


releases / Implementation status release 2

To avoid the point-to-point connection in the second release of the scenario 8.1 prototype the extended ESB has been integrated and is used as a flexible integration solution for all scenario 8.1 prototype components. Thus, this feature will be evaluated during the next evaluation.

With respect to integration with the platform the Chef cookbooks and receipts as well as the CIF blueprints have been created and are ready for evaluation.

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




8.1 Adoption

CIF offers either abstraction from the 4CaaSt internal CaaS or 4CaaSt external Google Maps Web Services Context Provisioning Systems and enables through its layered architecture different levels of abstraction from the underlying Context Provisioning System (UC.8-1.001)

During deployment and offering of Taxi Service within the 4CaaSt platform CIF is integrated and therefore abstracts from the REST interfaces offered by both CaaSt and Google Maps Web Services. CIF provides efficient and effective domain specific context information for determining the nearest taxi drivers from the customer pickup location within the taxi provider BPEL process (UC.8-1.007).


N/A

8.1 Feedback

Abstraction from REST APIs of context provisioning systems worked well, but there are two open issues regarding both the integration with the scenario 8.1 prototype as well as the 4CaaSt platform:






To avoid the point-to-point connection in the second release of the scenario 8.1 prototype the extended ESB has been integrated and is used as a flexible integration solution for all scenario 8.1 prototype components. Thus, this feature will be evaluated during the next evaluation.


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




8.1 Adoption

CIF encapsulates and therefore enables the reuse of higher level functionality in the domain of management of a taxi fleet and realizes this for the purpose of demonstration for both 4CaaSt internal CaaS and 4CaaSt external Google Maps Web Services Context Provisioning Systems (UC.8-1.001)

During operation CIF provides higher level functionality in the domain of management of a taxi fleet and this functionality is encapsulated in the two upper layers of CIF consisting of BPEL processes, which eases reuse and integration with other applications via WSDL interface (UC.8-1.007).


N/A

8.1 Feedback

Encapsulation of higher level taxi domain specific functionality is done sufficiently and eases reuse, but there are two open issues regarding both the integration with the scenario 8.1 prototype as well as the 4CaaSt platform






To avoid the point-to-point connection in the second release of the scenario 8.1 prototype the extended ESB has been integrated and is used as flexible integration solution for all components of scenario 8.1 prototype. Thus, this feature will be evaluated during the next evaluation.


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)


8.2 Adoption

Modelling and definition of the process used in the TOURISM demo application (UC.8-2.001)


N/A

8.2 Feedback

Specification and modelling of TOURISM demo application process went well, but there are open issues regarding the integration into the platform, especially regarding the Blueprint language:

o The Blueprint language was missing fields, e.g. to describe the mechanisms the components and services are interacting with the process. Thus, only the descriptor of the process could be provided. This has definitely to be improved for the second version of the scenario prototype in order to evaluate it in the next round.


The plans for future releases and the implementation status is described in detail at 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

Progress Initial steps have been taken; results have to be refined, extended and


(Release 1 status)

tested for production readiness (see D1.3.1)


8.2 Adoption

This feature of Bonita Open Solution has so far not been used in scenario 8.2


N/A



The realization of this feature is in progress. It is planned to be finished for use in the next version of the scenario prototype depending on the plans on extending scenario 8.2 in WP8.

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)


8.1 Adoption

When contracting the Taxi service JOnAS application server is part of the contract as some artefacts are deployed as JOnAS assemblies later on (UC.8-1.002)

During deployment and operation of the Taxi service several artefacts such as frontends and business logic artefacts are deployed on and executed on JOnAS application server (UC.8-1.007).

8.2 Adoption

Monitoring of JOnAS application server is used to enable measurement of KPIs and enforcement of SLAs (UC.8-2.006)

8.3 Adoption

As JOnAS is not used in scenario 8.3 so far there is no evaluation of this feature in this scenario yet.

8.1 Feedback

This feature of JOnAS did not work well and had to be fixed in the second version of JOnAS prototype. Thus, parts of the application artefacts had to be hosted on Apache Tomcat and some parts were hosted on JOnAS. This has to be fixed in the next version of scenario 8.1 prototype in order to deploy all artefacts required to be


run on an application server or servlet container on JOnAS.

8.2 Feedback

Usage of JOnAS for the application development in the scope of scenario 8.2 caused no additional 4CaaSt platform specific overhead and therefore is considered to be optimal.


The plan is to 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)


8.1 Adoption

When contracting the Taxi service JOnAS application server is part of the contract as some artefacts are deployed as JOnAS assemblies later on (UC.8-1.002)

During deployment and operation of the Taxi service several artefacts such as frontends and business logic artefacts are deployed on and executed on JOnAS application server (UC.8-1.007).

8.2 Adoption

During the development of Cloud-enabled software components for the TOURISM demo application several components are deployed and run on the JOnAS application server (UC.8-2.001enforcement of SLAs (UC.8-2.006)

8.3 Adoption

As JOnAS is not used in scenario 8.3 so far there is no evaluation of this feature in this scenario yet.

8.1 Feedback

This feature of JOnAS did not work well and had to be fixed in the second version of JOnAS prototype. Thus, parts of the application artefacts had to be hosted on Apache Tomcat and some parts were hosted on JOnAS. This has to be fixed in the next version of scenario 8.1 prototype in order to deploy all artefacts required to be run on an application server or servlet container on JOnAS.

8.2 Feedback

Usage of JOnAS for the application development in the scope of


scenario 8.2 caused no additional 4CaaSt platform specific overhead and therefore is considered to be optimal.


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)


8.1, 8.2, and 8.3 Adoption

As PgCloud is not used in scenarios 8.1, 8.2, or 8.3 so far there is no evaluation of this feature in these scenarios yet.


Implementation status and future plans

The work on the realization of the integration with the platform with respect to integration with the Marketplace, i.e. creation of required blueprint including metering information is in progress, but not finished yet.

Future plans are

o Finishing the integration of PgCloud into the 4CaaSt platform, i.e. enabling monitoring by following WP5 approach

o Usage of PgCloud in at least one of the scenarios 8.1, 8.2, or 8.3 in order to enable evaluation

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

Progress (Release 1

Production quality implementation of synchronous replication delivered into PostgreSQL 9.1, beta May 2011, full release September of 2011.


status) (see D1.3.1)



N/A

8.3 Adoption

During provisioning and operation of scenario 8.3 prototype PostgreSQL is used as the underlying database solution (UC.8-3.003enforcement of SLAs (UC.8-2.006)

8.3 Feedback

Due to the evaluation results this used feature enables 100 times faster updates than the next fastest alternative implementation.



The work on the realization of the integration with the platform with respect to integration with the Marketplace, i.e. creation of required blueprint including metering information is in progress, but not finished yet.

Future plans are

o Finishing the integration of PostgreSQL into the 4CaaSt platform, i.e. enabling monitoring by following WP5 approach

o Extending PostgreSQL for bidirectional replication for multi-master configuration is planned to be contributed to PostgreSQL release 9.3

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)



N/A

8.3 Adoption

During operation of scenario 8.3 prototype PostgreSQL is used as the underlying database solution and this feature is used in particular (UC.8-3.003enforcement of SLAs (UC.8-2.006)

8.3 Feedback

Due to the evaluation results this used feature reduces idle wakeups 11.5 to 0.4 per second. This is especially important, because it enables wide deployments of PostgreSQL as virtualized


servers use less power.


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)



N/A

8.3 Adoption

During provisioning of scenario 8.3 prototype the database-independent scalability API Saladdin is provisioned and also used during operation of scenario 8.3 (UC.8-3.003enforcement of SLAs (UC.8-2.006)

8.3 Feedback

This feature has been used in scenario 8.3 prototype, but has not been evaluated yet. Thus, it will be considered for the next round of evaluation.


(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)


8.1 Adoption

In order to offer the Taxi Application Service in the 4CaaSt marketplace the immigrant technologies CIF, Orchestra, and


JOnAS, which support standards such as BPEL, Web services and JDBC, have been integrated into the description of the service following the 4CaaSt Blueprinting approach (UC.8-1.001enforcement of SLAs (UC.8-2.006)

8.2 Adoption

During the development of Cloud-enabled software components for the TOURISM demo application the business process is modelled in BPMN supported by Bonita Open Solution (UC.8-2.001enforcement of SLAs (UC.8-2.006)

8.3 Adoption

During operation of scenario 8.3 prototype PostgreSQL is used as the underlying database solution and it‘s standard support for JDBC and SQL are used in particular (UC.8-3.003enforcement of SLAs (UC.8-2.006)

8.1 Feedback

The standard support of the different immigrant technologies used in scenario 8.1 eased the integration of the components and helped to realize the Taxi Application prototype as for the standards the tool support is very good.

As the development and realization of the standard support is sufficient the integration of the components into the 4CaaSt platform has to be the focus of the next releases and evaluation cycle.

8.2 Feedback

Specification and modelling of TOURISM demo application process in BPMN went well, but there are open issues regarding the integration into the platform, especially regarding the Blueprint language:

o The Blueprint language was missing fields, e.g. to describe the mechanisms the components and services are interacting with the process. Thus, only the descriptor of the process could be provided. This has definitely to be improved for the second version of the scenario prototype in order to evaluate it in the next round.

8.3 Feedback

PostgreSQL supports all database standards required by 4CaaSt scenario 8.3, which are so far: JDBC and SQL



So far the following components provide standard support: Extended Apache ServiceMix, Context Integration Framework, PgCloud, Saladdin (PostgreSQL), Orchestra, JOnAS

Future plans are

o The focus in the future with respect to both implementation and evaluation has to be the integration of the components into the 4CaaSt platform by following the approaches of the other WPs, i.e. Blueprinting (WP2), deployment and provisioning (WP4), monitoring (WP5), etc.


o Continue JOnAS standard implementation , complete and certify the Java EE 6 Web profile

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)


8.1 Adoption

Bonita Open Solution is not yet used in this scenario

Apache ServiceMix was not used in the first release of the scenario 8.1 prototype, but it is used in the second release.

Multi-tenancy feature of JOnAS is not yet used in this scenario

8.2 Adoption

Multi-tenancy feature of Bonita Open Solution has not been used in this scenario yet

8.3 Adoption

Immigrant technologies Bonita Open Solution and Extended Apache ServiceMix are not yet used in this scenario


8.1, 8.2, and 8.3 Feedback

There is no feedback available from the first evaluation, because either the Cloud-enabled immigrant technologies where not used or this multi-tenancy feature of the used immigrant technology was not used in the corresponding 4CaaSt scenarios.



For release two the following extensions to the immigrant technologies have been completed w.r.t. multi-tenancy support:

o Apache ServiceMix has been extended for multi-tenant aware administration and management and this extension has been integrated with the extension for multi-tenant aware communication, which was completed for release one

o Bonita Open Solution has been extended to enable tenant-aware configuration and management

o Extension of JOnAS for multi-tenant awareness considering the persistence layer, the management API, the registry and logging is still on-going, but planned to be finished for the final release

Future plans are

o Investigation of performance isolation as an important characteristic of multi-tenancy regarding the Orchestration


Engine, which is part of Bonita Open Solution

o Usage of multi-tenancy awareness feature of Apache ServiceMix in 4CaaSt scenario 8.1 as flexible integration solution for several taxi companies using the Taxi Application Service.

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


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


8.1 Adoption

The solution specific monitoring capabilities of JOnAS and Orchestra are used to enable rating and charging of the Taxi Application Service (UC.8-1.003, UC.8-1.008)

8.2 Adoption

The solution specific monitoring capabilities of JOnAS and Bonita Open Solution are required and used to enable buying the TOURISM demo application from the 4CaaSt Marketplace based on rating, SLA enforcement, and to enable enforcement of metering (UC.8-2.005, UC.8-2.006, UC.8-2.007)

8.3 Adoption

The monitoring feature of JOnAS is not yet used in this scenario

8.1 Feedback

The monitoring capability feature has not been considered for the first evaluation

8.2 Feedback

The provisioning of monitoring probes as defined by WP5 had to be done manual as some artefacts required for the complete integration into the 4CaaSt platform where missing at the time of the first evaluation, e.g. Chef scripts and cookbooks for automatic deployment of monitoring and metering probes.



OW2 Orchestra has been discontinued by Bull without major impact on scenario 8.1, because we continue using the last release of Orchestra for the scenario prototype

Integration with the platform w.r.t. monitoring has been started focusing on JOnAS and Bonita Open solution and will be completed asap in order to consider it for the next round of evaluation

Future plans are

o Evaluation of the monitoring capabilities not limited to JOnAS and Bonita Open Solution following the 4CaaSt platform monitoring


approach in the second evaluation. This requires that the monitoring of the components strictly follows the 4CaaSt approach specified for metering and monitoring.

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)


8.1 Adoption

As there is only one instance of JOnAS and Orchestra used in this scenario this feature has not been considered yet

8.2 Adoption

In order to enable enforcement of specified SLAs and KPIs it might be necessary that JOnAS is scaled out or in (UC.8-2.006)

8.3 Adoption

This feature of JOnAS is not yet used in scenario 8.3


8.2 Feedback

In the first evaluation the scalability feature of the 4CaaSt platform and its components could not be evaluated as its realization has been planned for the next releases of the 4CaaSt platform component prototypes.



OW2 Orchestra has been discontinued by Bull without major impact on scenario 8.1, because we continue using the last release of Orchestra for the scenario prototype

Finalization of JOnAS scalability support and integration in the 4CaaSt platform following the deployment and provisioning approach (WP4) are on-going

Future plans are

o Investigation of scalability support for Apache ServiceMix

o Evaluation of the scalability features of selected components and their usage in 4CaaSt scenarios in the next round of evaluation


2. Feature Changes Release 2/3 + Implementation Status new Features

This chapter provides the final 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].

Since this is a resubmission of D1.1.3 we additionally include an update of the implementation status for the new features defined. This status report is based on the version presented at the second project review Nov. 7/8.

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 Closed Community based search and social search are no longer addressed.

F#WP3.03 Bid Search N/A Cancelled


F#WP3.04 Related Products

TID Closed No changes.

F#WP3.05 Recommendation

N/A Partially Cancelled, rest moved

There are plans to focus on recommendation based on social data. This will be reported as part of feature F#WP3.008. Recommendations based on the service consumer‘s user profile or purchase history are no longer focus.

F#WP3.06 Advertising HSG / SAP

Cancelled


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



F#WP3.11 Product Customisation

N/A Cancelled


F#WP3.12 Bid to Product

N/A Cancelled


F#WP3.13 Basket Management

TID Cancelled


F#WP3.14 Contract Management

TID In Progress No changes.

F#WP3.15 Delivery Support


F#WP3.16 Payment Support

TID Closed


F#WP3.17 Charging SAP Closed

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 Competitive Products

NTUA In Progress No changes.

F#WP3.19

Reporting on products, incomes, etc


F#WP3.20 Simulations SAP & HSG

In Progress Assigned to SAP & HSG

F#WP3.21 User Management


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 Closed

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

Plans for future releases / Implementation status


Generation of customer billing data based on charging information provided by the Charging Component.

Plans for release 3

Storage of charging information in the Settlement Repository.

Revenue distribution to the different stakeholders involved in the delivery of a product.


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

Plans for future releases

While the first release already allowed the definition and management of price models, the second release is able to deal with metering information, defined as part of the blueprint. 4CaaSt Release 2 is the final release for Price Model Management.

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



KPI definition in Blueprints

Definition of chef recipes for probes management (deploy/start/stop/undeploy probes) on PICs and ACs, and how they are used by REC Manager. Such recipes will be provided for both kinds of probes (JASMINe and Collectd)


End to end monitoring configuration (from KPI in blueprint to probe deployment from Chef Recipes) could not be tested, goal was to do it at least for a couple of probes defined on PICs.

Plans for release 3

Complete end to end monitoring integration in 4CaaSt use cases: more probes, to be used for elasticity.

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



Cluster management feature is fully operative and integrated with the latest OpenNebula version.

Cluster support has been successfully tested within scenario 8.3, to implement HA capabilities.

Plans for release 3

Support for new features, such as support for service QoS, using OpenNebula cluster functionality.

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, which must be already included into the relevant IaaS BP offerings

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

Effort High


Implementation Status

Extend the BP definition to include hints for resource requirements for ACs/PICs

Extend the BP definition to describe the various IaaS offerings from a single provider

Define the overall requirements for computational resources for each virtual node according with the application provider‘s selected values of the hints

Define the optimum allocation of Virtual Machines for every virtual node, according to the IaaS offerings

Decide which deployment designs are feasible or not, and select the cheapest one

Open Issues for release 2

Extend the concept of BP to include elasticity rules

Transform the elasticity rules, as defined at the blueprints, to be aligned with the suggested deployment designs in order to enable elastic deployments from the F#WP4.01

Plans for release 3

Entrain the concept of ‗4CaaSt Powerpoints‘ as hints at the PIC layer to decorrelate the AC from the REC layer


Extend the functionality of the this feature to support End-to-End elasticity in all phases of the service lifecycle

Incorporate the elasticity rules with the conception of the hints and implement mechanisms to choose the most appropriate rule for scalability, when different rules regarding actions on different layers are triggered simultaneously

Use prediction models to suggest proactive scalability in combination with the elasticity rules upon certain thresholds to force scaling actions

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 Android terminals is provided.

F#WP6.06 Context Manager In Progress The SW implementing the CMS is provided, up and running in a 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

Dependencies to other

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


features


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



Task 6.1 has developed service provisioning and accounting of the usage

Task 6.4 has developed PIC deployment, and monitoring probe

Task 6.5 has developed SaaS provisioning


PIC deployment on T6.2 and T6.5 is under consideration

Plans for release 3

Finish the implementation of the remaining interfaces according to the nature of each component:

o Monitoring on T6.1, T6.2, T6.3 and T6.5

o Service provisioning on T6.2 and T6.3

o AC deployment on T6.5

o Accounting probe on T6.2, T6.3 and T6.5

2.1. 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

Closed Will be delivered as part of D7.3.2

F#WP7.09 Dynamic Reload of Dependencies

In Progress No Changes.



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 for JOnAS and Bonita Open Solution, but Closed for all other WP7 building blocks

This is required for all prototypical implementations of WP7 components.

F#WP7.17 Multi-tenancy support

In Progress for JOnAS, but Closed for Bonita Open Solution and Extended Apache ServiceMix

This is required for all prototypical implementations of WP7 components.

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

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

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

Closed Will be delivered as part of D7.3.2

F#WP7.29 Tenant Isolation and Security


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

In Progress for most of WP7 building blocks, but Closed for PostgreSQL and JOnAS

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

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

In Progress for most of WP7 building blocks, but Closed for CIF and Extended Apache ServiceMix

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


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


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


components

Responsible Partner

UPM


PgCloud, Resource Manager


N/A


N/A

Risks N/A

Effort High



Dynamic load balancing through PgCloud JDBC driver by reconfiguring connection transparently and dynamically based on replica load has been implemented, but final testing is on-going


Finishing final testing as soon as possible to enable usage of this feature in 4CaaSt scenarios

Continue working on the integration of PgCloud into the 4CaaSt platform

Plans for release 3

Finalizing the integration of PgCloud into the 4CaaSt platform including testing and bug fixing

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



Transparent failover through PgCloud JDBC driver by reconfiguring connection transparently when replica failover detected has been implemented, but final testing is on-going


Finishing final testing as soon as possible to enable usage of this feature in 4CaaSt scenarios, especially scenario 8.3

Plans for release 3

Finalizing the integration of PgCloud into the 4CaaSt platform including testing and bug fixing

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




Optimized group commit has been implemented in order to increased maximum write rate on restricted hardware in virtualized environments

This feature has been contributed to PostgreSQL release 9.2


Usage of this feature in one of the 4CaaSt scenarios including evaluation

Plans for release 3

Finalizing the integration of PostgreSQL into the 4CaaSt platform including testing and bug fixing

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



Managing large numbers of PostgreSQL servers is now easier using Barman, the Backup And Recovery Manager for PostgreSQL. Barman 1.0 has been partially sponsored by 4CaaSt, and has been due for release on June 15, 2012. It is already in production use at a small number of controlled release sites. Barman allows a single management interface to backup and recover large numbers of PostgreSQL servers


Usage of this feature in one of the 4CaaSt scenarios including


evaluation

Plans for release 3

Finalizing the integration of PostgreSQL into the 4CaaSt platform including testing and bug fixing

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



As the work on performance isolation recently started in RP2 there are only some basic results available so far, which have to and will be improved in RP3

A definition of performance isolation has been provided

The following three general issues have been identified with respect to performance isolation: layer discrepancy, unpredictable workloads, and the lack of metrics

Plans for release 3

Development of novel metrics for quantifying the performance isolation as well as a generic methodology for measurement.

Implementation of a domain independent framework for performance isolation measurement


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



As the work on performance isolation recently started in RP2 there are only some basic results available so far, which have to and will definitely be improved in RP3

A definition of performance isolation has been provided

A generic metric for performance isolations was developed

Plans for release 3

Proposal of a concrete Benchmark to run measurements independently from the platform against a servlet container providing multi-tenancy features.

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



As the work on performance isolation recently started in RP2 there are only some basic results available so far, which have to and will be improved in RP3

A definition of performance isolation has been provided in a generic technology independent way.

The developed metrics and measurement techniques for performance isolation are independent to a concrete domains or scenario.

Plans for release 3

Implementation of an measurement approach that goals for flexibility, thus it could be generically applied to different scenarios like performance isolation between different application instances or isolation between VMs on one hypervisor.

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)



N/A


N/A

Risks N/A

Effort High



The architecture of BOS has been revised and improved towards a Service-Oriented Architecture to make the new solution highly flexible and configurable. This new architecture comes with benefits to satisfy some non-functional requirements like large amount of data management and scalability. A lot of work has been done around transaction management to reduce database locking effects.


Usage of this requirement in the next release of scenario prototype depending on the plan to extend scenario 8.2

Plans for release 3

For the third release of the BOS prototype the focus is on the finalization of the integration into the 4CaaSt platform including testing and bug fixing

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



Extension of Apache ServiceMix for multi-tenancy support focusing on administration and management including tenant-based deployment has been realized in RP2

Moreover this extension has been integrated with the extension for multi-tenant aware communication done in RP1

Additionally the performance of the extension has been evaluated by extending an existing ESB performance benchmark

The Extended Apache ServiceMix has been integrated into the second release of scenario 8.1 prototype and used as flexible and Cloud-aware integration solution.

Plans for release 3

Investigation scalability support of Apache ServiceMix

Evaluation of the scenario 8.1 prototype release 2 in the next 4CaaSt evaluation

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



Responsible Partner

Bull, BONITASOFT, USTUTT


JOnAS, BOS, Apache ServiceMix


F#WP7.17, F#WP7.28


N/A


Risks N/A

Effort High



Tenant isolation in JOnAS has been realized with respect to the: persistence (JPA), management (JMX), Registry (JNDI), and logging. Finishing the final tests is on-going and to be finished as soon as possible to enable the usage of this feature in 4CaaSt scenarios including evaluation.

Tenant isolation in Bonita Open Solution has been realized and considered with respect to two subjects. The extension of the GUIs to enable tenant-specific configuration and the replacement of the configuration framework in order to enable multi-tenancy w.r.t. data isolation. Finishing the final tests is on-going and to be finished as soon as possible to enable the usage of this feature in 4CaaSt scenarios including evaluation.

The multi-tenancy characteristic of tenant isolation has been realized for Apache ServiceMix as part of the extension for multi-tenant aware administration and management, but security is an open issue to be addressed for the final release. Moreover this feature has been used in release two of scenario 8.1 prototype where Apache ServiceMix is used as integration solution.


Finish testing and bug fixing of tenant isolation in JOnAS

Plans for release 3

Apache ServiceMix multi-tenant mechanisms have to be extended for consideration of security, e.g. by using WS-Security

Evaluation of usage of Apache ServiceMix and corresponding features in release two of scenario 8.1 prototype

Investigation on how to enable performance isolation in Bonita Open Solution

Usage of this feature in JOnAS and BOS in at least one 4CaaSt scenario based on the plans for extending the scenarios including evaluation

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



The required Chef cookbooks and recipes for deployment and configuration have been created for PostgreSQL and JOnAS


Creation of the required Chef cookbooks and recipes for the other WP7 immigrant technologies

Plans for release 3

Usage of the Chef cookbooks and recipes of WP7 immigrant technologies in the corresponding 4CaaSt scenarios for dynamic and automatic deployment and provisioning including evaluation afterwards

The focus for release 3 of WP7 components is on finalizing the integration with the 4CaaSt platform not only focusing on the deployment and provisioning, but also e.g. on monitoring and accounting.

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

Major

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



The required Blueprints including metering and monitoring information as well as the pricing models and products for the representation in the 4CaaSt Marketplace are available for CIF and Apache ServiceMix.


Creation of required Blueprints including metering and monitoring information as well as the pricing models and products for the representation in the 4CaaSt Marketplace for the other WP7 immigrant technologies

Plans for release 3

Usage of the Blueprints, pricing models, and products of WP7 immigrant technologies in the corresponding 4CaaSt scenarios for offering in the 4CaaSt Marketplace and dynamic Blueprint resolution including evaluation afterwards

The focus for release 3 of WP7 components is on finalizing the integration with the 4CaaSt platform not only focusing on providing the Blueprints as well as the pricing models and products.


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.


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




analysis of the state of the art and definition of ... · d1.1.3 (b) version 2.0 wp1 – definition...

Documents