ecim d3.1 architecture and implementation plan - v1.0...

This project has received funding from the European Union’s Competitiveness and Innovation Framework Programme under grant agreement no. 621058.

DELIVERABLE Project Acronym: ECIM Grant Agreement number: 621058 Project Full Title: European Cloud Marketplace for Intelligent Mobility

D3.1 ARCHITECTURE AND

IMPLEMENTATION PLAN

Version: 1.0 Authors: Evangelos Argyzoudis INTRASOFT Georgios Zisis RELATIONAL Internal Reviewers:

Georgios Zisis (REL) Gorazd Marinič (iMinds) Wim Vanobberghen (iMinds) Francisco Iglesias (ESADE) Peter Vanderperren (MO4) David Mené (BEP) Steve Cross (CEN) Lucas Pignant/James Neesom (PBP) Eric Auquiere (CIRB) Jon Shamah (EJC) Francisco Iglesias (ESADE)

Dissemination Level

P Public X

C Confidential, only for members of the consortium and the Commission Services

D3.1 Architecture and Implementation Plan

© ECIM Consortium Version 1.0 – 27/06/2014

2

Table of Contents Table of Contents ............................................................................................................ 2

List of Figures ................................................................................................................. 3

Revision History .............................................................................................................. 4

1 Introduction .............................................................................................................. 5

1.1 Purpose and Scope ................................................................................................. 5

1.2 Relation to other Work Packages and Deliverables ........................................................... 5

1.3 Structure of the Deliverable ...................................................................................... 5

2 Methodology .............................................................................................................. 6

2.1 Architectural Design Principles ................................................................................... 6

3 System Workflows ....................................................................................................... 8

3.1 WF1: Sign up to the ECIM platform .............................................................................. 8

3.2 WF2: Service Provider registers a new service ................................................................ 11

3.3 WF3: ECIM Administrator revokes approval of a service .................................................... 12

3.4 WF4: Developer subscribes to a paid service .................................................................. 13

4 ECIM System Architecture ............................................................................................. 14

4.1 Cloud infrastructure ............................................................................................... 14

4.2 Platform technology stack ....................................................................................... 15

4.2.1 Java EE 7 ....................................................................................................... 16

4.2.2 Linux Ubuntu Operating System ............................................................................ 16

4.2.3 Glassfish Application Server ................................................................................. 16

4.2.4 Liferay Portal .................................................................................................. 17

4.2.5 Database Server ............................................................................................... 20

4.2.6 UI Technologies ............................................................................................... 20

4.3 The EPIC Platform Architecture ................................................................................. 21

4.4 From EPIC to ECIM ................................................................................................. 23

4.5 Platform architecture ............................................................................................. 25

4.5.1 Overall Architecture .......................................................................................... 25

4.5.2 Publishing of services and data to the ECIM platform ................................................... 26

4.5.3 Adaptation of data ........................................................................................... 26

4.5.4 Adaptation of services ....................................................................................... 27

4.5.5 Use of paid services .......................................................................................... 27

4.5.6 Service Catalogue ............................................................................................. 27

4.5.7 Administration console ....................................................................................... 27

4.6 Platform User interfaces ......................................................................................... 28



3

5 Implementation plan ................................................................................................... 34

5.1 Methodology ........................................................................................................ 34

5.1.1 Agile Development Methodology ........................................................................... 34

5.1.2 Continuous Integration process ............................................................................. 36

5.1.3 Development Infrastructure ................................................................................. 37

5.2 ICT-PROSE ........................................................................................................... 39

5.2.1 Training ........................................................................................................ 40

5.2.2 Dissemination .................................................................................................. 40

5.3 Schedule ............................................................................................................ 40

6 Conclusions .............................................................................................................. 41

List of Figures Figure 1: Layered Architecture ............................................................................................ 7 Figure 2: Sign-up procedure workflow (1) ................................................................................ 9 Figure 3: Sign-up procedure workflow (2) ............................................................................... 10 Figure 4: Sequence Diagram: Service Provider registers a service .................................................. 11 Figure 5: Sequence Diagram: Administrator Revokes approval of a service ....................................... 12 Figure 6: HOL Cloud Solution .............................................................................................. 15 Figure 7: The EPIC platform overview ................................................................................... 22 Figure 8: Consuming services from the portal .......................................................................... 22 Figure 7: ECIM Platform Overall Architecture .......................................................................... 25 Figure 1: User registration on the platform ............................................................................. 28 Figure 9: Service Catalogue ............................................................................................... 29 Figure 10: Service Catalogue details ..................................................................................... 30 Figure 11: Service Catalogue Developer's bought services ............................................................ 30 Figure 12: Client's list ...................................................................................................... 31 Figure 13: Services list ..................................................................................................... 32 Figure 14: Service details .................................................................................................. 32 Figure 15: Administrator User approval ................................................................................. 33 Figure 16: Administrator Service Catalogue Management ............................................................ 34 Figure 17: Agile methodology workflow ................................................................................. 35 Figure 18: Agile Project Management Process Framework ........................................................... 36 Figure 19: Continuous Integration Workflow ............................................................................ 37 Figure 20: Continuous Integration Workflow (2) ....................................................................... 38 Figure 21: Architecture of the PROSE solution ......................................................................... 39



4

Revision History Revision Date Author Organization Description

0.1 26/05/2014 Evangelos Argyzoudis Intrasoft Initial ToC

0.2 06/06/2014 Evangelos Argyzoudis Intrasoft First draft

0.3 10/06/2014 Evangelos Argyzoudis, George

Zisis Intrasoft, Relational

Second Draft



Integration of partner comments



Final Draft

Statement of originality:

This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both.



5

1 Introduction

1.1 Purpose and Scope This objective of this document is to present the overall architecture of the ECIM platform. The current document outlines the platform architecture including a detailed description of the components layout, their internal architecture as well as of the interactions among them. In this document are defined the flows and architecture of the ECIM platform in terms of the supported functionalities, the respective processes and the components that realise them.

This will serve as a reference point for the development work that will take place both in WP3 and WP4. The decisions presented in this deliverable are subject to refinements and modifications, based on the progress of the technical work packages, as well as the validation and evaluation phases. It is planned to deliver an updated version of the ECIM platform Architecture on month 16, which will include all the modifications that will take place during the project evolution.

1.2 Relation to other Work Packages and Deliverables The platform design is based on the requirements and specifications set out by T2.2 and particularly the deliverable D2.2. Initial Technical Requirements and Use Cases. This Deliverable will affect the developments in WP3 and particularly the delivery of the ECIM platform and its components. Also the current document contributes significantly to the technical work to be done in WP4, and particularly the work to be performed for Services and Platform integration (D4.2, D4.3) and also the delivery, upgrade and maintenance procedures of the service catalogue (D4.5).

1.3 Structure of the Deliverable The Deliverable D3.1 is organized as follows:

Section 2 presents the methodology of the ECIM Platform Architecture and the design principles that are based on the Layered Architecture.

In Section 3 are described the system Workflows and the related UML diagrams

The ECIM System Architecture, which contains Cloud infrastructure, platform infrastructure and technologies to be used, is described in section 4. This Section also(?) contains mockups of the ECIM platform. Finally in this section it is also presented the adaptation of EPIC Architectural concept to the ECIM platform architecture.

Section 5 presents the ECIM Implementation Plan and describes the Agile Development methodology, the (Continuous) integration Process and the development environment to be used. Moreover, it describes the schedule for the ECIM outcomes delivery.



6

2 Methodology

2.1 Architectural Design Principles

We consider a design as successful when it covers all the following aspects:

• Usability

• Performance

• Security

• Maintainability

• Scalability

In the architectural design of the ECIM platform we are addressing all of the above in order to make a robust and fully flexible system, which will cover all the needs of ECIM project. From a conceptual point of view, as most modern software architectures, it follows a layered architecture pattern. Thus, the system’s modules are divided into four distinct layers, each responsible for a specific set of functionalities. By convention, the layers interact with each other in a top-down manner, with each layer being able to access all layers below. A lower layer should never interact with layers above. This convention helps to avoid circular dependencies between layers.

The layers in a generic layered architectural design of any software platform are described as follows:

• Presentation Layer: Contains all the User Interfaces and Visualization Modules

• Services Layer: Exposes multiple APIs in the form of web services, defining a set of resources/methods as well as message structures

• Business Layer: Encapsulates all the business logic, as well as core domain entities of the system. It implements all system’s workflows and offers a simplified API (system façade) to the top layers for fulfilling the business workflows.

• Data Layer: Consists of all Data Access Objects as well as external service consumers. It is the broker to all the persistence storage and external data.

• Cross-Cutting Layer: Although it is not one of the basic four layers, it contains a set of features and modules which do not belong to a specific layer, since they are collaborating with all layers of the platform. These modules refer mainly to security and communication.

The following diagram1 depicts the layered software architecture:

1 http://blogs.msdn.com/b/jmeier/archive/2008/11/24/application-architecture-diagrams-added-to-codeplex.aspx



7

Figure 1: Layered Architecture

The layered architectural design addresses all the aspects that we are targeting. Together with other software architectures and standards that are followed, it helps us to apply the best standards in all the design aspects we are focusing on. More specifically:

Usability: The fact that we are following a layered architecture isolates the presentation modules from the logic layer, giving the possibility to focus on good User Experience design (UX). Thus, a web designer or a usability expert can work separately on the User Interface unaffected by the backend system developers. These experts can focus distinctly on the User Interface to maximize the quality of user experience. Internally, inside the presentation layer, we are going to follow a Model View Controller design pattern for building a web application, starting from a plain, well-defined user interface that consumes the services provided by the backend. The use of cutting-edge technologies like HTML5, CSS3 and jQuery will offer the best set of front-end features to provide a clean and fully functional interface. Finally, we are going to follow an agile methodology for developing the platform, based on rapid prototyping and frequent iterations. This enables more frequent evaluations close to the end-user of the platform and better result in terms of meeting the usability requirements.

Performance: For tackling performance issues, we are going to rely on two factors – caching and distribution. The system architecture logic is implemented in the backend and is exposed through an API of RESTful web services. These services offer parallelization in calls to the backend and can be deployed independently in a distributed way among several nodes of the cloud, following a Software Oriented Architecture. If needed, we could also use an Enterprise Service Bus to merge several heterogeneous services of the backend. If needed, load balancing and caching will be applied between the presentation



8

and the services layers. Additionally, the caching of data can take place even between the business layer and the data layer, when frequent fetching of the same data is required.

Security: The security features will be applied system-wise, covering all layers of architecture. The external API (Service Interfaces) exposed by the platform can be secured by means of encryption over HTTP via SSL, which is the standard protocol for security over the Internet. Since we are going to use Liferay for ECIM platform, any user credentials (for accessing the central platform) will be stored encrypted inside Liferay database, in a Database accessible only by Liferay server. Only the Services Layer and the UI is exposed publicly. Therefore, for the rest of the system (e.g. Databases) we don’t need further security since it is located inside a closed environment, which will be secured from the outside world by means of the cloud’s firewall. Thus, no one will be able to access the business or data layer but only the modules that reside on the same LAN. Finally, we are not going to store sensitive data inside the platform (e.g. credit card details). All the payment workflow will be implemented inside the service provider’s website, therefore there is no risk for losing such kind of data.

Maintainability: For addressing maintainability, we are going to follow standards oriented and technology independent architecture. Focusing on well-defined generic standards (e.g REST) we don’t rely on specific knowledge for proprietary solutions and standards. We will use only open-source solutions written in JVM languages (Java, Groovy) that are cross-platform and fully flexible. For code collaboration tools, we are going to use an overall Continuous Integration solution with Hudson/Jenkins, maven, sonar and subversion for code versioning management. For communication between the various developer teams, we are going to use a Redmine ticket tracking system. Trac is an interesting alternative solution that provides similar functionality. This way all tickets can be traceable and all code commits can be examined and explained, referring to specific tickets.

Scalability: The system is going to be able to scale up based on the volume of the requests. The elasticity will be provided by the cloud platform itself by configuring the resources appropriately. The architecture is free to scale up easily due to the service oriented distributed nature of the backend.

3 System Workflows

3.1 WF1: Sign up to the ECIM platform The various roles of ECIM platform are consolidated in the following table:

Actor Description

Service Provider This is an individual or business, which publishes his services (web services) through the ECIM platform.

City administrator Provides online data resources regarding his city.

ECIM Developer

This is an individual or business who uses services provided through the ECIM platform to create applications or integrate in to IT systems and solutions.

ECIM Platform Administrator

Provider of the ECIM platform who is responsible for the maintenance, updates and administration tasks (such as approving services and users) of the platform.

An ECIM user can be either an administrator of the ECIM platform, a developer (consumer of the services), a city administrator or a service provider. The registration to the platform can be made possible through the Liferay login and authentication mechanism. When the user signs up, he will be prompted to select



9

his/her role (service provider, developer, city administrator). For the sake of simplicity, the user will have to select the role through a selector describing the role, e.g. “I want to publish my service etc”. Based on this role, the user will gain access to specific pages and specific content and features of the platform. In every case, in order to enter the platform, the sign up will have to be approved by the ECIM platform admin, through the workflow provided by Liferay platform and is described in the following diagram. It is important to highlight that for every role, there will be a set of terms and conditions that the end-user shall agree with to proceed to the registration in the platform.

The following diagrams describe the workflow of the sign-up procedure for the user of the ECIM platform and the approval workflow by the ECIM administrator. As it can be seen in the following diagram, the user shall give a set of details about his/her account once visiting the registration page and given the option to agree in terms and conditions. This data will remain stored in an encrypted format inside Liferay MySQL database and will be associated with a unique user id.

Figure 2: Sign-up procedure workflow (1)



10

Once the administrator receives the notification (by email or at his personal notification page inside Liferay) he can visit the admin console of Liferay to review and approve the request. The administrator shall also assign roles (developer, service provider or city administrator) and access privileges to the registered user. Once this is finished, the recently activated user receives a notification about the successful registration and is able to login to the ECIM platform.

Figure 3: Sign-up procedure workflow (2)



11

3.2 WF2: Service Provider registers a new service A service provider can register a new service through the management console of ECIM platform for service providers. In the management console, the service provider registers a new service by giving a set of metadata describing the service. (see further details in 4.3.1). The services must follow a set of minimum requirements, which are described in section 4.5.2. The service provider also agrees to a set of terms and conditions regarding the commercial agreement with ECIM. These will refer to technical and legal rules for submitting the services. The service passes through a procedure of test and verification by the administrator of ECIM platform (based on the technical and legal rules for submitting the services) and once approved is released in the Service Catalogue.

Figure 4: Sequence Diagram: Service Provider registers a service



12

3.3 WF3: ECIM Administrator revokes approval of a service

The administrator will be able at any time to revoke the approval of a service through the administrator’s control panel by simply deactivate a specific service. When deactivating a service, the administrator shall provide a message explaining the reason why he/she selected to disable the service. A notification containing this message will be delivered to the developers that have subscribed to this service and the service provider of the specific service.

Figure 5: Sequence Diagram: Administrator Revokes approval of a service



13

3.4 WF4: Developer subscribes to a paid service The following diagram presents the workflow followed when a registered developer subscribes to a paid service.

Figure 6: Sequence Diagram: Developer subscribes to a paid service

The workflow steps are described below:

1. The developer accesses the services list through the ECIM platform Service Catalogue

2. The developer clicks on “register” link of a service

3. The developer is redirected to the service provider for payment (ECIM userID is passed encrypted in the URL header) or alternatively notifications are send by ECIM to the service provider and developer and the negotiation and payment is handled offline.

4. The developer fills in the payment details to the payment system of the service provider

5. The service provider is receiving notification about the successful payment of the user

6. The service provider accesses the management console of ECIM to modify users’ status

* The steps 5 and 6 could be replaced by an automated registration by the service provider, using a predefined API to register and update ECIM user service registration details (https)



14

4 ECIM System Architecture

4.1 Cloud infrastructure For the purposes of ECIM project we are going to use a cloud solution provided by HOL. The benefits of using a cloud are:

• Ease of Installation - Improve Time to Market Entry: Without the need for procurement of equipment, software licenses or installation services , a company can cover its needs directly and far cheaper than a traditional solution based on hardware installation.

• Lower Cost of Ownership: Outcome of no initial investment and the absence of operating costs . It prevents the H/W replacement cycle.

• Pay per Use: This pricing model allows full utilization of computing resources used in relation to the needs and the actual usage.

• Ease of System Escalation and improved response to periodic and unpredictable demand, depending on the needs of each client. In this way, the service availability is achieved by varying capacity (power, memory, storage, network) required any time without prior engagement with market infrastructure, software platform, network line high capacity etc.

• Better use of IT human resources: The IT departments can spend less time in installation and maintenance and therefore to focus on more strategic areas which have a direct impact on improving the core business of the company.

Advantages

• Time to Market – Dramatic decrease of implementation time for new servers Scalability

• Calculation of expenses in advance

• High Availability

• Modify the server “freely” to client needs

• Stability and security

• Access from anywhere

• Maintenance – preventative supervision

The HOL cloud architecture is described in the following diagram. Further information can be found at HOL’s website: https://www.hol.gr/services/hol-cloud.



15

Figure 6: HOL Cloud Solution

4.2 Platform technology stack The following table gives an overview of the technology stack that will be used for the ECIM platform.

Technology category Selected solution

Operating System Linux Ubuntu 10 LTS

Application Server Glassfish 4.0

Portal Server Liferay Portal CE 6.2

Database server MySQL server CE 5.6

Main programming language Java ee 7

UI technologies HTML5, JavaScript, JQuery, CSS3, Alloy UI

In the following sections these technologies are presented in more detail.



16

4.2.1 Java EE 7

Java Enterprise Edition 7 is one of the most popular open source programming languages. It provides API and runtime environment for developing and running enterprise software. The main benefit of Java as compared with other languages is that it is cross-platform, therefore all applications developed in Java are fully portable and platform agnostic. Moreover, it is fast, secure, and stable and it provides a powerful memory management and garbage collection mechanism, eliminating memory leak issues.

4.2.2 Linux Ubuntu Operating System Linux Ubuntu2 operating system is a Debian-based Linux operating system developed by Canonical Ltd a company based on the Isle of Man and owned by South African entrepreneur Mark Shuttleworth. In general, as any other Linux distribution, the Linux Foundation of which platinum supporters are IBM and Oracle also supports it. Ubuntu is composed of many software packages, the majority of which are free software. Free software gives users the freedom to study, adapt/modify, and distribute it. Additional software that is not installed in the default distribution can be downloaded and installed using the Ubuntu Software Center or other APT-based package management tools3. For increased security, the sudo tool is used to assign temporary privileges for performing administrative tasks, allowing the root account to remain locked, and preventing inexperienced users from inadvertently making catastrophic system changes or opening security holes Ubuntu also offers Ubuntu Cloud Images which are pre-installed disk images that have been customized by Ubuntu engineering to run on cloud-platforms such as Amazon EC2, Openstack, Windows, LXC and HOL. For ECIM platform we will install Ubuntu on HOL cloud.

4.2.3 Glassfish Application Server

GlassFish 4 is an open-source application server project started by Sun Microsystems for the Java EE platform and now sponsored by Oracle Corporation. The supported version is called Oracle GlassFish Server. GlassFish is free software,dual-licensed under two free software licences: the Common Development and Distribution License (CDDL) and the GNU General Public License (GPL) with the classpath exception5.

The current version of the Glassfish server is v4.0 and it is the first application server that can support the Java EE7 specifications. This version is designed with primary focus on higher productivity and support for HTML5 applications.

Glassfish runs in any operating system, it can manage easily any Java EE application, it has high stability and performance more than other commercial application servers. Glassfish comes along with an administration console for easy access and deployment of application and services.

2 http://www.ubuntu.com/ 3 http://en.wikipedia.org/wiki/Linux_ubuntu 4 https://glassfish.java.net/ 5 http://en.wikipedia.org/wiki/GlassFish



17

4.2.4 Liferay Portal

In ECIM, we need a platform to support user management (definition and administration of roles and privileges). We also need a solution to bring together various software modules and information in a uniform way, under a central user management mechanism. For this purpose, there is a need to use a portal (portlet container). Liferay Portal6 is an open source enterprise portal written in Java that allows developers to set up features common to websites and easily create corporate intranets and extranets. Since we are going to be based on Java programming language for the development, Liferay is the ideal solution as it is free, open source, stable, popular and rich in features. The community of Liferay provides well-documented guidelines as well as support to developers through a forum.

The current version of Liferay is 6.2. The community edition is freely available, distributed under the GNU Lesser General Public License and is maintained by the “community”, that is, a group of registered to Liferay users, while the professional is provided for a fee under a commercial license and maintained by the Liferay team, who also provide support.

Liferay portal is also a content and document management system that allows users to store, retrieve and edit documents and web content for their portals.

Although Liferay offers a sophisticated programming interface for developers, no programming skills are required for basic website installation and administration.

Some of Liferay’s key features are presented below. These features are not necessarily needed for ECIM at the current stage, however, they could be useful in case we need to extend the platform.

Multi-language Support

International or multi-lingual organizations get out of the box support for 30+ languages. Users can toggle between different language settings with just one click.

Simplified UI Development

Liferay Portal simplifies the development of internal, external, and channel websites--notably those that allow users to login for personalized services or views and those that require a workflow approval process to update content and integrate or aggregate multiple existing services. Liferay Portal provides a single presentation layer for integrating all enterprise systems into a single easy to use interface for end users.

Wikis

Build up and document important or interesting information as a community with Liferay's Wiki, which competes with standalone products in the robustness of feature set.

Each community gets its own Wiki with its own set of authorizations. Anyone with editing rights can quickly contribute information to these online topical encyclopedias.

Blogs

Liferay's Blogs provide the best features of modern blogging tools coupled with the benefits of the community-centric nature of Liferay Portal. They allow users to convey information and facilitate conversations around blogs directly in the context of a website, intranet, extranet, or social network.

6 http://www.liferay.com/



18

Features include a user-friendly rich text editor, social bookmarking links, email notifications of blog replies, and an entry rating system. All blogs can be subscribed to via RSS and users can schedule entries to be published at specific times and dates.

Message Boards

Message Boards are a perfect solution for facilitating conversations around shared ideas within a department or project team, or for capturing and sharing the knowledge of the workgroup.

Liferay offers views of message board activity statistics and recent posts and users can both subscribe to threads via RSS and reply to threads by email. Like all other portlets, Message Boards are secured by Liferay's granular system of authorizations which grants varying levels of control to different users.

Polls

Multiple choice polls can be created with this tool that also keeps track of votes. Many separate polls can be managed and a separate portlet can be configured to display a specific poll's results.

RSS

Subscribe to frequently read RSS feeds from message boards and blogs within the portal.

User-Driven Workflow & Approval

Not only is there embedded workflow for content, Liferay Portal allows users to create their own workflow and define the number of approval paths based on their own unique business requirements and operational needs.

User Groups, Organizations and Sites

Liferay users can be intuitively grouped into a hierarchy of "organizations" or cross-organizational "user groups," providing flexibility and ease of administration.

For example, members of different geographies such as Americas and EMEA can be grouped into organizations, whereas project based or departmental teams such as a "Website redesign" that cross disciplines can be created as user groups. Liferay provides support for "sites" where both organizations and user groups can be added to a separate web property with its own set of pages, content management system, shared calendar, and authorizations. A user can belong to multiple sites and easily navigate between them.

Web Content Structures and Templates

Liferay Portal allows users to easily create reusable templates for web pages and page sections. This enables users to quickly build pages and allows websites to maintain a common look and feel across the entire site by allowing new pages to be created with an approved set of templates. Users can quickly create templates within Liferay's web UI or by using external web development tools.

SOA Framework

Liferay Portal is developed using an open SOA strategy that makes it the choice of enterprises worldwide for enterprise application integration.

OpenSocial

Support for OpenSocial 1.1 creates new avenues for developers to add social capabilities and dimensions in their websites. With OpenSocial, users can manage and deploy web-based social applications built from gadgets directly to pages and sites.



19

Technologies

Liferay Portal is Java based and runs on any computing platform capable of running the Java Runtime Environment and an application server. A number of application servers (Tomcat, Glassfish etc.), databases (MySQL, PostgresSQL, SQLServer, etc.), technologies (AJAX, REST etc.) and open standards (JSR-286,JSR-170, JSR-314 etc.) is supported, fact that gives the opportunity to developers to combine them in a way that best suits to the needs of each project.

For a full list of technologies used and supported by current version of Liferay portal see Technical Specifications.

Development

With Liferay portal it is possible to develop themes that define the look n’ feel of the web application’s pages, hooks that customize the portal’s abilities and layout templates that define the way portlets are spread inside a portal page.

The main parts of a portal are functional units that are called portlets. Liferay comes with a number of built – in portlets that implement many of its features mentioned previously. It is also possible to extend Liferay’s functionalities by creating custom portlets. Technologies that can be used for this purpose (and not limited in these), are Java Server Faces (JSF), Vaadin, or Java Server Pages (JSP) and JQuery.

The development of all these units is possible through a series of plugins provided freely by Liferay for the Eclipse IDE or Liferay Developer Studio for the Enterprise Edition.

Security

Liferay Portal uses industry standard, government-grade encryption technologies, including advanced algorithms such as DES, MD5, and RSA, and was benchmarked as among the most secure portal platforms using LogicLibrary's Logicscan suite. It offers a customizable single sign-on (SSO) that integrates with Yale CAS, JAAS, LDAP, Microsoft Exchange, and more.

What's more, Liferay Portal ships with robust user management and security features including password policies, user reminder settings, and complete log-in security procedures. Liferay also abides by OWASP guidelines to reduce the risk of security vulnerabilities. Other security features include:

• Pluggable Authentication

• Email Verification

• Session Management

Clustering

Liferay Portal is designed to serve everything from the smallest to the largest web sites. Out of the box, it's configured optimally for a single server environment. If one server isn't sufficient to serve the high traffic needs of a project, Liferay scales to the size necessary.

Liferay works well in clusters of multiple machines (horizontal cluster) or in clusters of multiple VMs on a single machine (vertical cluster), or any mixture of the two. Once a Liferay portal is installed in more than one application server node, there are several optimizations that can be performed in different aspects of the portal like database, DMS repositories, caching and searching.

• Database: Liferay supports database sharding through different portal instances, using the round robin shard selector. This is a class which serves as the default algorithm for sharding in Liferay.



20

Using this algorithm, Liferay selects from several different portal instances and evenly distributes the data across them.

• DMS: Liferay’s Documents and Media Library is capable of mounting several repositories at a time and presenting a unified interface to the user. By default, users can make use of the Liferay repository, which is already mounted. This repository is built into Liferay Portal and can use as its back-end one of several different store implementations. In addition to this, many different kinds of third party repositories can be mounted and all nodes of the cluster will point to this repository. If one of the Liferay’s repositories is used, more configurations are available to achieve higher performance in a clustered environment.

• Search: Liferay uses as its default search engine Lucene. One way of achieving search is to further configure Lucene so indexes replicate across the individual file systems of the nodes in the cluster. Liferay also supports the usage of Solr which is an enterprise search engine and has more configuration options.

• Caching: Liferay uses Ehcache, which has robust distributed caching support. This means that the cache can be distributed across multiple Liferay nodes running concurrently. Enabling this cache can increase performance significally.

4.2.5 Database Server

The actual storage is based on the MySQL Community Server database. This is considered to be the most popular object relational database system. The MySQL development project has made its source code available under the terms of the GNU General Public License, as well as under a variety of proprietary agreements. MySQL was owned and sponsored by a single for-profit firm, the Swedish company MySQL AB, now owned by Oracle Corporation. MySQL works on many different system platforms, including AIX, BSDi, FreeBSD, HP-UX, eComStation, i5/OS, IRIX, Linux, Mac OS X, Microsoft Windows, NetBSD, Novell NetWare, OpenBSD, OpenSolaris and others. It is a very mature system, very good documented and with a wealth of resources available. Many graphical interface applications for the management and administration of a MySQL database are available, both free and paid. Although MySQL was the database of choice for almost all open source projects, the acquisition of Sun by Oracle, which brought MySQL under Oracle's control, made many developers sceptical about using it in new projects. Oracle promised to continue supporting the database system and keep offering the community edition, but it is generally thought that a sudden policy change from Oracle's part is not to be excluded. Currently, the status of the terms of use for the MySQL Community Server fit to the needs of the ECIM project.

4.2.6 UI Technologies

HTML5

HTML5 is the latest W3C standard for HTML and a core technology markup language of the Internet used for structuring and presenting content for the World Wide Web.

HTML5 was designed to replace HTML 4, XHTML, and the HTML DOM Level 2, and it introduces elements and attributes that reflect typical usage on modern websites.

It was specially designed to deliver rich content without the need for additional plugins. The current version delivers everything from animation to graphics, music to movies, and can also be used to build complicated web applications.



21

HTML5 is also cross-platform. It is designed to work whether you are using a PC, or a Tablet, a Smartphone, or a Smart TV.

JQuery

jQuery is an open source JavaScript library that simplifies the interactions between an HTML document, or more precisely the Document Object Model (aka the DOM), and JavaScript. It is open source software licensed under the MIT license, which is small in size, plays in any browser, is extremely popular and is well documented. jQuery's syntax is designed to make it easier to simplify HTML document traversing and manipulation,

browser event handling, to create animations, handle events, and develop Ajax applications. jQuery also provides capabilities for developers to create plug-ins on top of the JavaScript library which makes it even more powerful and flexible.

CSS3

Cascading Style Sheets (CSS) is a style sheet language used for describing the look and formatting of a document written in a markup language. While most often used to style web pages and interfaces written in HTML and XHTML, the language can be applied to any kind of XML document, including plain XML, SVG and XUL. CSS is a cornerstone specification of the web and almost all web pages use CSS style sheets to describe their presentation7.

CSS3 is the latest standard for CSS and introduces many advanced features like 2D and 3D transitions and transformations, advanced element selections, media queries, gradients, new web fonts etc. that make the user experience even more pleasing.

4.3 The EPIC Platform Architecture

ECIM is the follow on project from EPIC EU project (2010 Competitiveness and Innovation Programme-CIP). The overall aim of the EPIC project was to develop a flexible, extensible, future-proof cloud computing platform maximising the use of open-standards. The platform would host, manage and deliver a diverse range of smart-city applications to citizens and businesses, deliver smart-city data services to support innovation among SME developers and improve efficiency in city administration.

This section gives an overview of the components of the EPIC platform architecture and the way the EPIC services were deployed and published to the users.

The EPIC platform was based on the SOA principles and open standards and was realized with the help of a number of IBM tools.

More specifically the main parts of the EPIC platform were:

• A cloud infrastructure based on the IBM SmartCloud Enterprise Solution

7 http://en.wikipedia.org/wiki/Cascading_Style_Sheets



22

• A portal server running the EPIC portlets and web sites, delivering content to all kind of devices through the Internet and limiting access to registered users based on their role. The IBM WebSphere Portal Server was used for this purpose.

• An application server hosting the EPIC web services. The IBM WebSphere Application Server was used for this purpose.

• A service catalogue that allowed the developers to search and consume EPIC services. The IBM WebSphere Service Registry & Repository tool was used.

• Databases to store users and applications data. The IBM DB2 database server was used.

Figure 7: The EPIC platform overview

Figure 8: Consuming services from the portal

In EPIC a typical scenario would be:

• A service provider has a number of services available running to his local application server and he wants to make them accessible through the EPIC platform.

• The service provider registers to the EPIC platform

• The service provider develops an EPIC service, that is, he writes code for a new service by using a tool like IBM WID that will consume his services running on his local server.



23

• The service provider uploads his service to the platform

• The service catalogue is populated by the service file of the service

• A registered developer accesses the service catalogue, searches for services for his application and views details based on the service files

• The developer chooses the services he wishes to use and develops a series of portlets that consume them.

4.4 From EPIC to ECIM

The ECIM platform will follow and level up the EPIC methodologies and practices, but the implementation will be based on open source tools instead of the IBM ones.

A one by one mapping of the EPIC and ECIM equivalent tools is summarized in the following table.

EPIC ECIM

Cloud solution IBM Smart Cloud Enterprise HOL Cloud

Portal Server WebSphere Portal Server Liferay CE

Application Server WebSphere Application Server

Glassfish CE

Service catalogue WSRR Liferay portlets

Database Server DB2 MySQL CE

Development tools WebSphere Portlet Factory, WebSphere Web Services Integrator

Eclipse, Netbeans

In terms of functionality the ECIM platform based on D2.2 and in more detail in the next sections will have the following additional features comparing to EPIC:

In EPIC a service provider had to develop an EPIC service, according to IBM’s platform standards and deploy it on the EPIC platform. This service in term connected to other services outside of the EPIC platform. In ECIM instead the service provider develops his services according to the guidelines of the ECIM platform and then publishes the service through the ECIM platform. In order to publish a service the service provider will provide information that describes his web services, like method name, method type, parameters, type of parameters and web service end-point (URL), through a platform web interface. Service providers will have access to documentation guiding them through the process of preparing and submitting their services to the ECIM platform.

In the EPIC architecture there was no access control for using the services built in the platform. In ECIM Service providers will have the opportunity to control access over their registered services, that is, to enable or disable developers from using their services.

The EPIC platform did not include any reporting features for the web services usage. The ECIM Platform will provide reporting tools to the service providers to enable them to monitor the usage of their services.



24

The ECIM service catalogue will be populated by the information provided by the service providers and this way it will provide a more readable and intuitive interface for developers to discover, evaluate and subscribe to services offered. In EPIC service catalogue only contained technical information, whereas the ECIM service catalogue will contain both very specific technical information and more user-friendly information for non-technical users.

The ECIM platform will also incorporate community features, not present on the EPIC platform, allowing the platform users to exchange opinions, rate the services etc

Therefore, an ECIM typical scenario would be:

• A service provider has a number of services available running on his local application server and he wants to make them accessible through the ECIM platform.

• The service provider registers to the ECIM platform

• The service provider fills in the necessary data about his web services through a user interface provided by the platform

• These data are stored in the platform.

• The service catalogue is populated by the service data provided.

• A registered developer accesses the service catalogue, searches for services required by the application he is developing and views details based on the information provided by the service providers

• The developer chooses the services he wishes to use and he subscribes to them.

• The service provider then provides access to the services for the developer through the platform.

• The developer is ready to develop an application that consumes the services he has subscribed to from the ECIM platform.



25

4.5 Platform architecture 4.5.1 Overall Architecture

Figure 9: ECIM Platform Overall Architecture

The overall architecture of the platform is described in the diagram above. As seen, the architecture follows the layered architecture principles. More specifically, the ECIM platform will be entirely hosted on HOL Cloud and will be served by a Glassfish Server. Glassfish server will also act as the hosting container of Liferay CMS.

The graphical interface provided to ECIM users will be implemented inside Liferay and will consist of Liferay portlets, Liferay themes, the Liferay admin UI and the access control portlet.

There will also be two main repositories, a MySQL database server responsible for Liferay data persistence as well as a generic purpose repository (could be a NoSQL database) responsible for caching of data or local data maintenance.

The core logic of the platform will be implemented by means of Liferay hooks and java backend code of the portlets. The business layer modules of Liferay will interact with the service and data consumers, which in turn will use internally the service and data adapters respectively.

Finally, a RESTful API will be exposed by a set of resources, which will consume and proxy the data and the services provided by third party service and data providers.

To describe the calls that take place between the various modules of the platform we can take a look at the arrows provided in the previous diagram as described below:

1. The developers, city administrators and service providers access the platform through the only graphical interface that is provided by the Liferay. They will either access a specific portlet, or the overall Liferay container. The look and feel will be controlled by the applied custom Liferay theme.



26

2. All the information that needs to be maintained by the platform and by Liferay, will be stored inside the relational MySQL database that resides in the cloud. Inside this repository we will store data like user details (id, role, email, screen name), services details, service provider details etc. All data used by Liferay will be also persisted at this place (portlet details, hook details, themes, admin configurations etc)

3. Application developers will access the ECIM API’s to interact with the services published through the ECIM platform. Once a developer needs to access a service published by the platform, he will call the related RESTful POST method. The developer shall pass (together with the necessary parameters asked by the API of the service) the user id or token (unique for each user) as well as the requested service id. These parameters shall be always encrypted over https.

4. When the request reaches the RESTful resource of ECIM platform, the business layer of the system (residing inside Liferay) will have to check inside the database the status of the user. If the developer has been activated for the use of the requested service, the backend will answer with an acknowledgment message.

5. In this case, the RESTful resource will address to the appropriate Data or Service consumer to fetch the respective data from the related service provider.

6. The service consumer module will call the remote service provider’s API and fetch the corresponding data. If authentication is required , the request will be secured through the OAuth 2.0 token (non-expiring) granted by the service provided a priori to ECIM platform.

7. For caching and redundancy purposes, there may be a Caching Repo inside the platform that can be used either for backing up response content or for retrieval of previously fetched info.

8. Finally, the Service (or Data) consumer modules can take use of various adapters to adapt the retrieved data into the desired format, for instance: csv to json.

4.5.2 Publishing of services and data to the ECIM platform

The modules of the data access layer will consume the third party services. In case security is a prerequisite by a service provider, the provided service must be secured by OAuth2.0. The consumer client modules of ECIM platform will be implemented in either Groovy or Java and will be able to consume json, XLS, XML and CSV formats. The service providers shall expose their services as RESTful services, associated with the appropriate documentation to be used when registering a service to the ECIM platform. More specifically, the only prerequisite for the service provider is to describe each RESTful resource with the following attributes for each method:

• Base URI: e.g. http://example.com/resources/

• Request Relative URI: e.g. /parking-zones

• Category: REST

• Method type: e.g. GET/POST

• Parameters: e.g. zoneId=[the zone id] or complex json input

• Sample input (example to test the method)

• Sample output

• Payment URL (https)

4.5.3 Adaptation of data

The data providers can provide their data services by exposing online datasets of various format e.g. CSV. The ECIM platform will provide a support mechanism (e.g. documentation, FAQs, discussion forum) for the transformation of these data from the original formats to JSON. It must be noted that the exposed data sets must be available as web resources. In this way the ownership of data resides with the data owner.



27

4.5.4 Adaptation of services

The third party services will be exposed through the RESTful API of the system. The developers will be able to select to use a service through the Service Catalogue. In practice, once the user selects a service, the related id of the service will be assigned to the account of the user.

There will be a common RESTful resource exposed by the ECIM platform (e.g. http://api.ecim-cities.eu) accessible by the user. In this method, the user will be able to provide parameters based on the service that needs to access. Assuming for instance that is needed to access the BePark service, he could use the method http://www.ecim-eu/rest with POST parameters: 1. the Liferay account user id and 2. the selected service id. The platform will have to check every time if the user has registered for the specific service and, if yes, will provide the response. For security purposes, the method called by the user shall be encrypted over HTTPS.

4.5.5 Use of paid services

The ECIM platform will not provide a payment system. It will provide access control, monitoring and reporting to the service providers and city administrators. The service providers will be responsible for implementing the payment services. Once the developer decides to subscribe to a provided service, he will be immediately directed to the service provider’s service, which will take responsibility over the payment workflow. Inside the redirection request there will be encapsulated the ECIM user id. In this way, the service provider administrator will be aware of the ECIM user that is accessing the payment service and will be able to link the ECIM user id to the service provider’s database for future needs. Alternatively, a notification is sent by ECIM to the service provider and the developer with the necessary details for the negotiation and subscription to take place outside the ECIM platform. Once the service provider administrator approves the payment, there will be two options. Either the service provider administrator gets a notification about the payment and manually modifies the user’s status in the ECIM platform, or the registration process takes place automatically through the use of ECIM privileged API offered to the service providers. For the last option, the service providers should modify their payment service to use this feature.

4.5.6 Service Catalogue

The Service Catalogue will rely on Liferay “Marketplace” portlet8. This portlet ensures basic functionality for the features that we need to be provided by the ECIM platform, such as the services catalogue. In the scope of the use cases of ECIM platform, the Service Catalogue will provide a set of services as registered by the service providers. In the Service Catalogue portlet an ECIM developer may see the available services, drill into the details of each one, see the statistics and pricing and eventually subscribe to the service. On the other hand, the service providers will be able to use the Service Catalogue to register their services or data endpoints. By filling in a set of metadata, they will provide a full description of their service. The registration will be semi-automatic since it has to be approved by the administrator of ECIM platform. Therefore, by using the sample input of the service provider description, the administrator tests the provided services and, if tests pass successfully, proceeds to the approval and the publication of services.

4.5.7 Administration console

The admin console of Liferay will be used for the management of the ECIM platform. There are two privileged roles, the service provider role and the ECIM admin role. The service provider will be able to access the administration console to modify the ECIM users that have registered to the provided services, On the other hand, the ECIM admin, will have access to the whole set of platform users, change rights, monitor activity, reject or approve provided services or signed up users. For this purpose we will have two main admin interfaces, one for ECIM administrator for approving new services and users and a second one to be accessed by ECIM service providers. The service providers will be able to monitor the access of their services, statistics, consumer details and status. Moreover, they will be able to change the status of each consumer. Finally, they will be able to extend their services, register new ones or update existing services.

8 https://www.liferay.com/marketplace



28

4.6 Platform User interfaces In this section a series of indicative mockups about the platform are presented. The purpose of these mockups is to present the main functionalities a user can perform on the platform as described in section 3 “System Workflows” of the present document and section ‘Platform Functional Requirements’ of D2.2. It is to be noted that these mockups are only indicative and do not represent the final look and feel of the platform.

As described in section 3.1, a user of the ECIM platform (developer, service provider or a city administrator) first needs to register in order to use its offered functionalities. In the following figure a typical registration form is shown that will hold user data like first and last name, preferred username etc.

Figure 10: User registration on the platform

Developers

The main goal of a developer on the platform is to find and potentially subscribe to free or paid services for his applications (see section 3.3).

In order to do so, as mentioned in 4.3.7, a Service Catalogue will be developed in the context of the ECIM project.

The developer first will be able to view a service catalog like the one presented in the following mockup.

The catalog will present a list of available services and their data such as service category (Parking, POIs etc), current version, pricing information etc as the service providers have provided during the service registration phase.

The catalog will also provide search capabilities according to certain search criteria like price, or category, location etc and sorting and filtering capabilities on most of the services data.



29

Figure 11: Service Catalogue

The service list will hold the main information about the services available. A developer will be able to select a service from the list and view more details. The details indicative view is presented in Figure ‘Service Catalogue details’. As depicted in this mockup, the developer will be able to view all the basic information about the service and key information about the services methods and their inputs – outputs. The developer could also view information like service statistics (number of subscribed developers, market share comparing with other services in the same category, etc) and user opinions about it.



30

Figure 12: Service Catalogue details

The services the developer has subscribed to and the service providers have approved, can be viewed in his services list.

Besides the basic information about the service, the user will be able to view also the date of subscription

Figure 13: Service Catalogue Developer's bought services



31

Service Providers

The service providers will be able to view a list of the registered clients that have subscribed to their services through the ECIM platform. The list could contain information like client name, the service name and if the user is deactivated for a reason from the service provider and he needs to stop accessing the services (access control).

The platform will provide a service to the service providers in order for them to add this information to the client’s list (Figure 12). This has to be done after the developer has subscribed to the service. The platform will also provide a GUI that can optionally give the service providers the opportunity to update this information manually.

Figure 14: Client's list

As mentioned in section 3.2, the service providers’ main goal is to register their services to the ECIM platform. In order to achieve that, the service providers will be able to view and edit a list of all their registered services. In this list, the provider will be able to add, delete and update a service and its metadata (eg. category, type, payment URL etc). He will also be able to view statistics about a selected service. The payment URL will be used to redirect the developer to the website of the service provider to start the payment process and contract agreements etc.



32

Figure 15: Services list

In order to complete the service registration, the service provider needs also to provide information about its methods and their inputs, outputs. The page will also provide documentation that explains how to develop and submit their services.

Figure 16: Service details



33

Administrator

The administrator, as mentioned, is responsible for accepting or rejecting the user role registration requests and for the management of the Service Catalogue.

The administrator will be able to view a list of all pending user requests for the roles supported by the ECIM platform (developer or service provider) and the details of a selected user (username, name, email, phone number etc) in order to decide if he will approve or reject the user’s request for this role.

Figure 17: Administrator User approval

In order for the administrator to manage the Service Catalogue, the administrator will be able to view a list of all the service providers and their registered services and activate/deactivate or delete them from the ECIM platform.



34

Figure 18: Administrator Service Catalogue Management

City administrator

The City administrators will have exactly the same rights and features as the service providers.

5 Implementation plan

5.1 Methodology

5.1.1 Agile Development Methodology

A research among the most dominant development methodologies9 indicates that the most appropriate way of implementing ECIM platform would be ‘Rapid Application Development’10. This implies that a system prototype is implemented, tested and evaluated in an iterative manner, using short cycles to add functionality to the prototype. This is more suitable for an R&D project aiming to deliver a system prototype, since it enables business oriented teams to continuously participate in the development of the platform and guide the development towards their needs. In this manner, the processes of implementation and definition of the platform will proceed in parallel until the end of the project by means of close collaboration between all the teams. One of the most popular types of Rapid Application Development is the ‘Agile Methodology’, which is associated with a list of terms and rules that have to be followed during development as described in the ‘Agile Manifesto’11. Agile methodology implies and enforces collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. Some of the principles of the Agile Manifesto are:

! Welcome changing requirements, even late in development

! Working software is delivered frequently (weeks rather than months) 9 http://en.wikipedia.org/wiki/Software_development_methodology 10 http://en.wikipedia.org/wiki/Rapid_application_development 11 http://agilemanifesto.org/



35

! Working software is the principal measure of progress

! Customer satisfaction by rapid delivery of useful software

! Close, daily co-operation between business people and developers

! Projects are built around motivated individuals, who should be trusted

! Continuous attention to technical excellence and good design

! Simplicity

! Self-organizing teams

! Regular adaptation to changing circumstances The methodology workflow could be reflected in the following diagram12:

Figure 19: Agile methodology workflow

Agile Practices

These principles define the practices that are going to be followed for the implementation. Moreover, they imply the processes that are going to be adapted during the development cycle. The Agile Project Management Process Framework is presented in the diagram below13

12 http://exelanz.com/why-cloud/development-methodology/

13 Agile Project Management: Creating Innovative Products. Jim Highsmith. 2009. Addison-Wesley Professional.



36

Figure 20: Agile Project Management Process Framework

To sum up, the five phases of agile project management are:

1. Envision: determine the product vision and project scope, the project community, and how the team will work together

2. Speculate: develop a feature-based release, milestone, and iteration plan to deliver on the vision 3. Explore: deliver tested features in a short timeframe, constantly seeking to reduce the risk and

uncertainty of the project 4. Adapt: review the delivered results, the current situation, and the team's performance, and adapt

as necessary 5. Close: conclude the project, pass along key learnings.

5.1.2 Continuous Integration process Continuous Integration process fits perfectly with the Agile Methodology. Continuous integration (CI) comprises practices such as daily builds and additional checks so as to prevent bugs. In order to enable automatic daily builds, Continuous Integration software gathers the whole source code in one place (with different revisions), automate the build process and testing, and provides the latest working executable to anyone involved in the project. The CI model comprises a set of activities for the process implementation: building the system, running tests, deployment activities, and finally reporting test and deployment results. The practice of Continuous Integration assumes a high degree of tests, which are automated into the software: a facility that can be seen as “self-testing code”, often using a testing framework, such as JUnit4. Each automated build will perform the following steps:

• Compilation and creation of the build package

• Creation of a report on code metrics (such as package, dependency analysis and cyclomatic complexity)

• Creation of a report on how much source code follows declared Coding Standard



37

• Creation of a report on possible bugs by a static code analysis execution

• Automated deployment in testing environment

• Execution of automated test cases and creation of test report

• Publishing the build artifacts

• Notification to stakeholders and involved developers about build outcome by email and on central build dashboard

Continuous Integration is a software development practice where:

• Members of a team integrate their work frequently.

• Each integration is automatically compiled and built

• New artifacts are automatically deployed in testing environment

• Integration and Unit Testing is performed automatically

• Automated notifications to developers are sent

• Creation of reports about software quality code

The workflow is also depicted in the following diagram:

Figure 21: Continuous Integration Workflow

5.1.3 Development Infrastructure Hudson CI: For the continuous integration workflow of the ECIM platform, we are going to use Hudson Continuous Integration server.

• Hudson is one open source tool to perform Continuous Integration.

• Monitors a SCM (Source Control System) and if changes occur to start and monitor a build system (for example Apache Ant or Maven).



38

• Hudson will monitor the whole process and provide reporting functionality and notification functionality to report success or errors.

Hudson controls the builds of the project through a graphical interface accessible by the administrator of the integration process. Thus, the integrator can easily change the maven goals to be executed as well as the execution mode and time of the scheduled maven jobs. Apache Maven: Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information. It is important that all modules are compatible with maven rules, sharing the same .pom file. In this way, the integration will be easily controlled through maven and moreover, the project will be independent of an IDE; as a maven project can be opened in eclipse, netbeans, IDEA etc. Trac or Redmine: An enhanced wiki and issue tracking system for software development projects. Subversion or Git: A software versioning and a revision control system distributed under a free license alternatives: mecurial, ClearCase, Git Sonar: Sonar is an open source software quality platform. Sonar uses various static code analysis tools such as Checkstyle, PMD,FindBugs, Clover to extract software metrics, which then can be used to improve software quality. Sonatype Nexus: Sonatype Nexus sets the standard for repository management providing development teams with the ability to proxy remote repositories and share software artifacts. Download Nexus and gain control over open source consumption and internal collaboration.

In a more descriptive way, the workflow of the procedure is the following:

Figure 22: Continuous Integration Workflow (2)



39

5.2 ICT-PROSE

ECIM project will have as objective to get advantage of the solution provided by PROSE platform. This will ensure a long term sustainability, dissemination and exploitation of ECIM platform as a FLOSS (Free/Libre and Open Source) project. For this purpose, ECIM will have to comply with the rules of PROSE and deploy on frequent releases the project source code to the PROSE platform. This will not affect the continuous integration process we have already described, but will extend it by adding an additional step after every release declaration. PROSE is a EU FP-7 project aiming to support FLOSS (Free/Libre and Open Source) ICT projects. This is achieved by increasing the lifetime of the software developed inside EU projects and by promoting dissemination and training events on the features provided by the open source projects. Everything is organized through a coordination platform responsible for both hosting and training/dissemination. PROSE enables the ICT open source projects to remove the legal and business obstacles. The following diagram describes the architecture of the PROSE solution.

Figure 23: Architecture of the PROSE solution

Common Platform More specifically, the platform provided by the PROSE project offers hosting and support of ICT FLOSS software. It will enable creating and managing software repositories. The platform will offer support to development processes as well as common infrastructure for maintaining the projects. It will finally provide a suite of community and software management tools, access to methodology, business and legal information.



40

5.2.1 Training PROSE takes responsibility for giving training documentation for the software platform and also for the legal and business aspects related to FLOSS use. There are FLOSS development methodologies given to project owners for taking advantage of the tools. Finally, it offers access to business and legal information that facilitates to build successful exploitation models of a FLOSS project, including licencing and intellectual property rights.

5.2.2 Dissemination PROSE aims at promoting the hosted FLOSS projects by reaching a wide ICT audience. It takes over responsibility for organizing training and dissemination events as well as participating at several scientific events (e.g. the European FLOSS Workshops) for raising the awareness towards the FLOSS advantages in ICT.

5.3 Schedule

Month 7: Platform Development - Iteration 1 Beta version of the initial Platform to support the Brussels Pilot.

! Features for ECIM platform administrators o User management for developers, service providers and city administrators o Approval mechanism of users and published services

! Features for developers

o Registration of developers o Access control to services

! Features for service providers and city administrators

o Registration of service providers and city administrators o Publish RESTful services

! Incoming service security based on OAuth 2.0 ! Outgoing API security based on SSL

o Publish online data files (csv format) as a json RESTful web service o Access control for published services

Month 9: Platform Development - Iteration 2, to support Brussels pilot. Release version, of the initial platform to support the Brussels Pilot. Month 12: Platform Development - Iteration 3, to support Barcelona and Paris pilots. Platform ready to support all pilots and includes bug fixes identified from the previous iteration.

! New features for developers o Service Catalogue

! Search for services ! Filter services ! Subscribe to services



41

! New features for service providers and city administrators o Publish online data file (xls) as a json RESTful service o Service Catalogue

! List their services in the catalogue ! Provide descriptions ! URI (URL?) to their payment endpoints

Month 16: Platform Development - Iteration 4, to support interim Brussels, Paris, Barcelona testing. First version of the fully featured platform

! New features for developers o Service usage statistics o Community features

! Rating of services ! Reviews/Comments ! Forum

! New features for service providers and city administrators

o Reporting and monitoring of services

Month 30: Platform Development - Final version Final version of the ECIM platform incorporating bug fixes and enhancements. Support Birmingham proof of concept pilot (Month 28).

6 Conclusions The current document contains the architecture specifications and design of the integrated ECIM platform that will serve as a basis for the development tasks of the project. A second version of this document will be delivered on M16 with the revised and complete specifications of the ECIM Platform and interfaces.

The first version of the ECIM platform architecture description document will be very useful to define and communicate the initial blueprint of the ECIM platform. The architecture will continue to evolve throughout the project and we need to make sure that it is consistent with design and implementation work in the other technical work packages and the early pilot activities of the project.

This deliverable presented the activities for the delivery of a baseline implementation of the ECIM platform, which acts as the reference point for the actual development of this platform and offers a shared and common background for the Consortium participants on the envisaged technologies that are necessary to build such a platform.