Functional Requirements

Two primary stakeholders were identified:

Cloud-based application developer This may be an enterprise or an ISV (Independent Soft-

ware Vendor) that wants to develop an application and host it on the cloud.

Cloud PaaS provider This is any PaaS offering that wants to be as available as possible to

customers.

Table 11.1 shows a list of the requirements relevant to the design of the adapter, classified by stakeholder and priority. Low priority requirements are omitted since it was decided not to address them. As the table clearly depicts, the adapters are primarily address to developers, since the use cases related to them are the ones that need to communicate to the different underlying platforms.

Taking this list as a starting point, we have refined the requirements into a new list of finer- grained requirements specific to this project.

The new requirements have been elicited using a template inspired in the requirement tem- plates of the Volere methodology [RR12] but with a simplified set of fields adjusted to the needs of this project. Table 11.2 describes this template.

Stakholder Requirement Priority

Cloud-based application developer

F1 Monitor, manage and configure a Cloud-based appli- cation’s lifecycle (deployment, federation and migra- tion)

Top F2 Be able to migrate an application from one

Cloud4SOA-enabled platform to another

F3 Receive notifications when a SLA violation is raised F4 Establish agreements with Cloud4SOA enabled

providers (when registered)

F5 Deploy (part of) an application on a Cloud4SOA en- abled platform

F6 Acquire additional resources upon request

Cloud PaaS

provider F7 Map their platform’s API to the Cloud4SOA API Medium

Table 11.1: Cloud4SOA Functional requirements

Req. Id Requirement

identifier

Originator High-level requirement

that originates this re- quirement.

Priority Requirement

priority

Description

Description of the requirement

Rationale

Justification for the need of this requirement

Fit Criterion

Condition that has to be achieved for this requirement to be considered fulfilled Table 11.2: Requirements template inspired in the Volere template.

The following subsections describe the new requirements for each stakeholder.

Developer

Req. Id CD1 Originator F1 Priority Top

Description

The system must enable the deployment of applications to CloudFoundry by following the same process than with any other PaaS.

Rationale

To be able to add CloudFoundry to the repository of available PaaS.

Fit Criterion

The system must be capable of deploying a complex Java Web application (using a database) packaged as a war file to CloudFoundry.

Req. Id CD2 Originator F1 Priority Top

Description

The system must enable the undeployment of applications running on CloudFoundry.

Rationale

To be able to provide the required functionalities to fully integrate CloudFoundry.

Fit Criterion

The system must be capable of undeploying any application previously deployed to Cloud- Foundry.

Req. Id CD3 Originator F1 Priority Top

Description

The system must enable the governance (start/stop) of applications running on Cloud- Foundry.

Rationale

To be able to provide the required functionalities to fully integrate CloudFoundry.

Fit Criterion

The system must be capable of starting and stopping any application previously deployed to CloudFoundry.

Req. Id CD4 Originator F1 Priority Top

Description

The system must enable the monitoring of applications running on CloudFoundry. The mon- itoring must be able to collect the same metrics collected for other PaaS.

Rationale

To be able to provide the required functionalities to fully integrate CloudFoundry.

Fit Criterion

The system must be capable of showing monitoring data for any application deployed to CloudFoundry.

Req. Id CD5 Originator F2 Priority Top

Description

The system must enable the migration of an application from CloudFoundry to any compati- ble PaaS and vice-versa. The application and its environment must not be altered or damaged during this migration.

Rationale

To be able to integrate Cloud Foundry in the migration feature of Cloud4SOA which is one of the key features of the platform.

Fit Criterion

The system must be capable of migrating a complex Java Web application (using a databse) packaged as a war file to any compatible PaaS.

Req. Id CD6 Originator F4 Priority Medium

Description

The system must automatically create an agreement between the developer and Cloud- Foundry when an application is deployed to it. The details of the agreement can be defined by the developer at the time of creating the application.

Rationale

To be able to have an agreement between developers and the PaaS to which they deploy applications, thus enabling Cloud4SOA to have a control over the performance of the cloud and to warn the developer about any unexpected situations.

Fit Criterion

The system must create an implicit agreement with CloudFoundry when deploying any ap- plication to it. The agreement should contain the terms specified by the developer when creating the application.

Req. Id P1 Originator F7 Priority Medium

Description

The interface of CloudFoundry must be mapped to the harmonized Cloud4SOA API. The system must implement as much methods as possible from this interface and state clearly the methods that are not applicable.

Rationale

To take the most profit of the CloudFoundry API and implement as much operations as possible.

Fit Criterion

All methods from the harmonized Cloud4SOA API must be mapped to a method or set of methods of the Cloud Foundry API, or stated that is not applicable to CloudFoundry.