This document has identified the functionalities and it has also defined the technical specifications of the different modules. The objective, along the design, has been to be pragmatic and reuse the existing tools and applications, mainly, as far as possible based on the results of FI-WARE. We have identified the different pieces that provide added value to the different modules, as well as defined the dependencies and interrelationships between them.
Furthermore, the document has focused on the interactions with the user since it is one of the most important aims of XIFI. There is one access point providing a centralized point for all of the components; for this reason, it is important to design and define the graphical user interface.
We aim to progress in parallel with the rest of components and work packages, since the design of the components is not static and will evolve over time. This means that the results of this document are crucial and it is the base for subsequent development of the components resulting from the activities in T4.1, T4.2, T4.3, T4.4 and T4.5 after this release. However, it is not a final and static specification, and it should be actualized along the development through collaborative tools such as Wiki and Redmine, in order to achieve the ultimate goal of quality.
REFERENCES
[1] D1.1. XIFI core concepts, requirements and architecture draft (month 4). XIFI Deliverable D1.1.
August 2013. http://wiki.fi-XIFI.eu/Public:D1.1
[2] D3.1 XIFI infrastructure adaptation components API open specification.
[3] Future Internet Public-Private Partnership (FI-PPP). http://www.fi-ppp.eu/
[4] FI-WARE. http://www.fi-ware.eu
[5] Security Assertion Markup Language 2.0 (SAML 2.0) http://en.wikipedia.org/wiki/SAML_2.0 [6] The OAuth 2.0 Authorization Framework. http://tools.ietf.org/html/rfc6749
[7] Andrieux, A., Czajkowski, C., Dan, A., Keahey, K., Ludwig, H., Pruyne, J., Rofrano, J., Tuecke, S., Xu, M., WebServices Agreement Specification (WS-Agreement). June 29th 2005
[8] Cloud4SOA: EU-funded project research http://www.cloud4soa.eu/
[9] WS-Agreement standard is a full recommendation of the Open Grid Forum (OGF) defined by the Grid Resource Allocation Agreement Protocol working group (GRAAP--WG)
http://www.gridforum.org/Public_Comment_Docs/Documents/2011-03/WS-Agreement-Negotiation+v1.0.pdf
[10] The XIFI Consortium. eXperimental Infrastructures for the Future Internet. Annex I - Description of Work. March 2013
[11] Maarten van Steen, Andrew S. Tanenbaum. Distributed systems: principles and paradigms.
Pearson Prentice Hall. 2007. ISBN: 0-13-239227-5 [12] FI-WARE Cloud Portal. http://cloud.lab.fi-ware.eu/
[13] FI-WARE Application Mashup, Open Specification. http://forge.fi-
ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE.OpenSpecification.Apps.ApplicationMashup
[14] FI-WARE Wirecloud, Application Mashup Generic Enabler. FI-WARE Catalogue.
http://catalogue.fi-ware.eu/enablers/application-mashup-wirecloud [15] FI-WARE Store, Open Specification.
https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE.OpenSpecification.Apps.Store [16] FI-WARE WStore, Store Generic Enabler. FI-WARE Catalogue.
http://catalogue.fi-ware.eu/enablers/store-wstore
[17] FI-WARE Application Mashup, Open API RESTful Specification.
http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Application_Mashup_Open_RESTful_API_S pecification
[18] FI-WARE Store, Open API RESTful Specification.
https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Store_Open_API_RESTful_Specification [19] FI-WARE Catalogue: http://catalogue.fi-ware.eu/enablers/marketplace-sap-ri
[20] FI-WARE Marketplace, Open Specification: https://forge.fi- ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE.OpenSpecification.Apps.Marketplace
[21] FI-WARE Marketplace GE, RESTful API Specification:
o https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE.OpenSpecification.Apps.MarketplaceRegistrationREST
o https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE.OpenSpecification.Apps.MarketplaceOfferingsREST o
https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE.OpenSpecification.Apps.MarketplaceSearchREST [22] FI-WARE Marketplace GE, User and Program guide:
http://forge.fi- ware.eu/plugins/mediawiki/wiki/fiware/index.php/Marketplace_-_User_and_Programmer_Guide
[23] FI-WARE Marketplace GE, Installation and Administration Guide: http://forge.fi-
ware.eu/plugins/mediawiki/wiki/fiware/index.php/Marketplace_-_Installation_and_Administration_Guide
[24] Software-Defined Networking: The New Norm for Networks. Open Networking Foundation.
April 2012.
[27] FI-WARE Repository GE, Open Specification Repository GE.
https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Apps.Repository [28] FI-WARE Repository GE, User and Program guide, Repository GE:
http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Repository_-_User_and_Programmer_Guide [29] FI-WARE Repository GE, Installation and Administration Guide, Repository GE:
http://forge.fi- ware.eu/plugins/mediawiki/wiki/fiware/index.php/Repository_-_Installation_and_Administration_Guidedd
[30] FI-WARE Repository GE, RESTful API Specification, Repository GE:
https://forge.fi-ware.eu/plugins/mediaw[20]iki/wiki/fiware/index.php/FIWARE.OpenSpecification.Apps.Reposit oryREST
[31] XIFI Wiki. http://wiki.fi-XIFI.eu
[32] FI-WARE Security Monitoring GE, Open Specification:
https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Security.Security Monitoring
[33] FI-WARE Security Monitoring GE, User and Program guide: https://forge.fi- ware.eu/plugins/mediawiki/wiki/fiware/index.php/Security_Monitoring_-_User_and_Programmers_Guide
[34] FI-WARE Security Monitoring GE, Installation and Administration Guide: https://forge.fi-
ware.eu/plugins/mediawiki/wiki/fiware/index.php/Security_Monitoring_-_Installation_and_Administration_Guide
[35] FI-WARE IdM GE, Open Specifications
http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Security.Identity Management
[36] FI-WARE IdM GE, Open API specifications
http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Identity_Management_Generic_Enabler_API_S pecification
[37] FI-WARE Access Control GE, Open Specifications
http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Security.Access_
Control_Generic_Enabler
[38] FI-WARE Access Control GE, Open API Specifications
http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Security.AccessC ontrolGE.Authorization.Open_RESTful_API_Specification
APPENDIX A: WIRECLOUD MASHUP PLATFORM
According to the description of the baseline technology section, the Wirecloud Mashup
Platform will be considered at first glance as the reference implementation of the FI-WAREApplication Mashup Generic Enabler. Given that there is already an available implementation; some screenshots of Wirecloud may be taken as examples to offer possible pictures of XIFI Portal Graphical User Interfaces.
1) Creating a new workspace
A workspace consists of the set of widgets and operators that can be mashed-up. Widgets and operators in a workspace can share data though data flow- or event-based mechanisms.
If a new workspace is required to be created and be named 'History Info', the 'New workspace'
option will need to be chosen in the dropdown menu.
Once accepted, the name of the new workspace is shown in the upper of the window and the features of it might be configured.
2) Browsing a marketplace
The platform must support the access to a marketplace. Once there, the end user can quickly find and compare widgets, operators and even pre-built mashups.
The following figure shows a screenshot of Wirecloud where the FI-WARE marketplace is
displayed. In our specific case, XIFI infrastructures will be playing the role of those stores
which make their offering available.
Wirecloud offers a built-in local marketplace, which allows the user to search among the available widgets, operators and mashups. The following figure shows a screenshot of the local catalogue for a user in a given instance of Wirecloud.
3) Adding a new marketplace
If only the Local marketplace is available, the FI-WARE marketplace can be added by using
'Add new marketplace' option as shown in the following screenshots.
4) Wiring widgets and operators
Once chosen the desired widgets, it will be required to wire them in order to enable their intercommunication and to achieve coordinated behaviour. Widgets and operators in Wirecloud are capable of sending and/or receiving events and data through well-identified ports called endpoints. By connecting two compatible endpoints, the input or target endpoint prepares to receive data flows and/or events coming from the source endpoint.
To wire the widgets and add operators to your mashup go to the Wiring view of the tool.
In this case, an Entity Service operator is going to provide the Map Viewer widget with data
information. This kind of operators are called piping operators and needed to be added to the
wiring canvas.
As the endpoints are not compatible, a transform operator is required to convert the event data provided by the Entity Service operator to the format used by the Map Viewer widget. In this example, the operator in charge of the transformation is Entity To PoI.
Given that they are compatible, the PoI endpoint can be connected to the Entity To PoI
operator to the Insert/Update PoI endpoint on the Map Viewer widget.
Going through the 'Edit' window, the map widget will be updated and showing the PoIs
obtained from the Entity Service operator.
APPENDIX B: RESOURCE CATALOGUE, API OPERATIONS Resource Catalogue, API Operations
Resources
Here we start with the description of the operation in the next table:
Verb URI Description Mandatory
/Optional
GET /api/resources Gets a list of all registered
resources. Mandatory
POST /api/resources Registers a new resource Mandatory
GET /api/resource/{resource_id} Gets resource info Mandatory
DELETE /api/resource/{resource_id} Unregisters a Resource Mandatory PUT /api/resource/{resource_info} Updates Resource info Mandatory POST /api/resource/{resource_id}/vote Recommend a resource in
the catalogue Mandatory
POST /api/resource/{resource_id}/comment Publish a comment on a
resource in the catalogue Mandatory
POST /api/resource/{resource_id}/{instance_id}/vote
Recommend a resource instance deployed in an infrastructure.
Mandatory
POST /api/resource/{resource_id}/{instance_id}/comment
Publish a comment in a resource instance deployed in an infrastructure
Mandatory
Getting Resources
Example request:
GET /api/resources HTTP/1.1 Accept: application/json
Example response:
"description": "Sol/CEP is a fast, versatile Complex Event Procesor even to collect abast amount ... "
"image": "img_file"
"description": "Self-service provisioning and life cycle management of virtual machines and associated compute,
Content-type: application/json [
{
"name": "IaaS Data center resource manager GE"
"description": "Self-service provisioning and life cycle management of virtual machines and associated compute,
storage and network resources"
"image": "img_file"
"type": "Generic Enabler"
...
} ]
Example response:
HTTP/1.1 201 Created Content-Type: application/json [
{
"resource_id": "1112"
"name": "IaaS Data center resource manager GE"
"description": "Self-service provisioning and life cycle management of virtual machines and associated compute,
storage and network resources"
"image": "img_file"
"type": "Generic Enabler"
"popularity": 4
"comments": [{comment1}, {comment2}, ... ] "instances": [{instance1},{instance2}, ... ] ...
} ]
Delete Resource
Example Request
DELETE /api/resources/{resource_id} HTTP/1.1 Content-type: application/json
Accept: application/json
Example Response
HTTP/1.1 204 No Content
Update Resource
Example Request
PUT /api/resource/ HTTP/1.1 Content-type: application/json Accept: application/json [
{
"resource_id": "2123"
"name": "IaaS Data center resource manager GE"
"description": "Self-service provisioning and life cycle management of virtual machines and associated compute,
storage and network resources"
"image": "img_file"
"type": "Generic Enabler"
"popularity": 4
"comments": [{comment1}, {comment2}, ... ] "instances": [{instance1},{instance2}, ... ] ...
} ]
Example Response
HTTP/1.1 200 OK
View Resource
Example request:
GET /api/resources/1 HTTP/1.1
Example response:
HTTP/1.1 200 OK
Content-Type: application/json [
{
"resource_id": "1"
"name": "Gateway Data Handling GE: Sol/CEP"
"description": "Sol/CEP is a fast, versatile Complex Event Procesor even to collect abast amount ... "
"image": "img_file"
"type": "Generic Enabler"
"popularity": 4
"comments": [{comment1}, {comment2}, ... ] "instances": [{instance1},{instance2}, ... ] ...
} ]
Catalogue
Verb URI Description Mandatory/Optional
GET /api/catalogue Gets a list of all registered resources
order by default. Mandatory
GET /api/catalogue?orderby={parameter} Gets a list of all registered resources
order by parameter value Mandatory GET /api/catalogue?filter={filter_values} Gets a list of all registered resources
depending on filter values Mandatory
Get Catalogue Resources
Example request:
GET /api/catalogue HTTP/1.1
Example response:
HTTP/1.1 200 OK
Content-Type: application/json [
{
"resource_id": "1"
"name": "Gateway Data Handling GE: Sol/CEP"
"description": "Sol/CEP is a fast, versatile Complex Event Procesor even to collect abast amount ... "
"image": "img_file"
"type": "Generic Enabler"
"popularity": 4
"comments": [{comment1}, {comment2}, ... ] "instances": [{instance1},{instance2}, ... ] }
{
"resource_id": "2"
"name": "Some GE Name"
"description": "Some GE detailed description. "
"image": "img_file"
"type": "Generic Enabler"
"popularity": 2
"comments": [{comment1}, {comment2}, ... ]
"instances": [{instance1},{instance2}, ... ] }
{
"resource_id": "3"
"name": "Some GE Name"
"description": "Some GE detailed description. "
"image": "img_file"
"type": "Generic Enabler"
"popularity": 3
"comments": [{comment1}, {comment2}, ... ] "instances": [{instance1},{instance2}, ... ] }
{ ...
...
} ]
Get catalogue resources order by
Example request:
GET /api/catalogue?orderby=popularity HTTP/1.1
Example response:
HTTP/1.1 200 OK
Content-Type: application/json [
{
"resource_id": "1"
"name": "Gateway Data Handling GE: Sol/CEP"
"description": "Sol/CEP is a fast, versatile Complex Event Procesor even to collect abast amount ... "
"image": "img_file"
Get catalogue resources depending on filter values
Example request:
GET /api/catalogue/filter?filter1=value1&filter2=value2&filter3=value3&filtern=valuen HTTP/1.1
"description": "Sol/CEP is a fast, versatile Complex Event Procesor even to collect abast amount ... "
"image": "img_file"
{ ...
...
} ]
APPENDIX C: SLA MANAGEMENT, API OPERATIONS SLA Management, API Operations
Here we start with the description of the operation following the next table:
Verb URI Description Mandatory/Optional
GET /api/sla Gets a list of all sla templates. Mandatory POST /api/sla Registers a new sla template Mandatory GET /api/sla/{sla_template_id} Gets SLA temaplate info Mandatory DELETE /api/sla/{sla_template_id} Unregisters a Sla template Mandatory PUT /api/sla/{sla_template_id} Updates Sla template info Mandatory GET /api/sla/offer/{resource_id} Gets SLA offer info for a resource Mandatory
Getting Sla
Example request:
GET /api/sla HTTP/1.1 Accept: application/json
Example response:
HTTP/1.1 200 OK
Content-Type: application/json [
{
"sla_id": "1"
"template_name": "template1"
"metrics": [{metric1}, {metric2}, ... ] "contracts": [{contract1},{contract2}, ... ] ...
}
{
"sla_id": "2"
"template_name": "template2"
"metrics": [{metric1}, {metric2}, ... ] "contracts": [{contract1},{contract2}, ... ] ...
} ]
Register a new SLA Template
Example request:
POST /api/sla HTTP/1.1 Content-type: application/json [
{
"name": "SLA Template 1"
"metrics": [{metric1}, {metric2}, ... ] ...
} ]
Example response:
HTTP/1.1 201 Created Content-Type: application/json [
{
"sla_id": "1112"
"name": "SLA Template 1"
} ]
View SLA Template
Example request:
GET /api/sla/1 HTTP/1.1
Example response:
HTTP/1.1 200 OK
Content-Type: application/json [
{
"sla_id": "1"
"template_name": "template_name"
"metrics": [{metric1}, {metric2}, ... ] "contracts": [{contract1}, {contract2}, ... ] ...
} ]
Update SLA Template
Example request:
PUT /api/sla HTTP/1.1 Content-Type: application/json [
{
"sla_id": "1"
"template_name": "template_name_updated"
"metrics": [{metric1}, {metric2_updated}, ... ] "contracts": [{contract1}, {contract2}, ... ]
...
} ]
Example response:
HTTP/1.1 200 OK
Delete SLA Template
Example request:
DELETE /api/sla/1 HTTP/1.1
Example response:
HTTP/1.1 204 No Content
Gets SLA offer info
Example request:
GET /api/sla/offer/1 HTTP/1.1
Example response:
[ {
"resource_id": "1"
"name": "Gateway Data Handling GE: Sol/CEP"
"description": "Sol/CEP is a fast, versatile Complex Event Procesor even to collect abast amount ... "
"image": "img_file"
"type": "Generic Enabler"
"popularity": 4
"comments": [{comment1}, {comment2}, ... ] "sla": [{sla_info1}]
} ]
APPENDIX D: INTEROPERABILITY TOOL, API OPERATIONS Interoperability Tool, API Operations
Here we start with the description of the operation following the next table:
Verb URI Description Mandatory/Optional
GET /api/patterns Gets a list of all
registered patterns. Mandatory
POST /api/patterns Registers a new pattern Mandatory
GET /api/patterns/{pattern_id} Get the data describing
a single pattern Mandatory DELETE /api/patterns/{pattern_id} Deletes a pattern Mandatory PUT /api/patterns/{pattern_id} Updates pattern info Mandatory POST /api/patterns/{pattern_id}/execute Execute a given
pattern Mandatory
POST /api/Specifications/{specification_id}/compare
Compare compatibility of interface with specification
Mandatory
Getting Resources
Example request:
GET /api/patterns HTTP/1.1 Accept: application/json
Example response:
HTTP/1.1 200 OK
Content-Type: application/json [
{
"pattern_id": "1"
"name": "authentication"
"description": "xxxx xxxx xxxx "
"Pattern": { "Resources": [{resource1},{resource2}, ...]
"Transitions": { "From": resource1 "To": resource2}
"Assertions": [{a==b}, {a!=c}]
} ]
APPENDIX E: CLOUD4SOA
The SLA Management module will leverage on the results of Cloud4SOA [8] to offer a dynamic SLA negotiation and enforcement framework for multi-cloud environment based on a unified monitoring interface and metrics.
The Cloud4SOA project helps to empower a multi-cloud paradigm, providing an interoperable framework for developers. The system supports Cloud-based application developers with multiplatform matchmaking, management, unified application and cloud monitoring and migration. It interconnects heterogeneous Cloud offerings across different providers that share the same technology through the concept of adapter that provides a REST-based API for any-cloud access.
In-depth, the module will leverage on the Cloud4SOA dynamic SLA negotiation and enforcement to develop a framework enabling dynamic SLA negotiation and tools that enable Cloud providers to analyse their offerings and performance and adapt the SLAs accordingly. The framework allows providers and customers to negotiate flexibly between standard and customized SLAs, while supporting business dynamics through business-performance related SLA metrics being monitored and analysed. To deal with a SLA in an automatic way, the SLA itself has to be expressed in a formalized way using an SLA specification language.
In terms of technology baseline, Cloud4SOA provides a RESTful implementation of the WS-Agreement standard [9] . In the context of the project several languages for SLA specification have been reviewed (e.g. WSOL, WSLA, WSML etc.) but the WS-Agreement specification was selected as the most appropriate:
WS-Agreement offers a protocol to be followed for the negotiation process and a common understanding (i.e. language) of the objects the negotiation is about. Thus, it enables the automatic creation of SLAs.
The outcome of a successful negotiation with WS-Agreement is a SLA with binding character for both parties to deliver a reliable service to the end-user.
WS-Agreement is a novel but well-accepted standard for creating and enforcing SLAs in distributed environments as well as monitoring their resources properties.
Cloud4SOA leverages on WS-Agreement specification to offer three main functionalities that enables users to negotiate and enforce SLAs, as well as recover from SLA violations:
Agreement Negotiation. Allows the automatic negotiations on behalf of Cloud providers, based on the semantic description of offerings and the QoS requirements specified by application developers.
Agreement Enforcement. Supervise that all the agreements reached in a SLA are respected (i.e. measurements are within the thresholds established in SLA for QoS metrics).
Violation recovery. Whenever the execution of the business application does not satisfy the SLA (i.e. breaches of the agreement occurs), the most appropriate recovery action (e.g.
warning messages, stop or migration of the application) is suggested based on the policies defined by the software developer.