PHAROS D5.1 Service Platform Design Document

Transcription

1 PHAROS D5.1 Service Platform Design Document Instrument Call / Topic Project Title Collaborative Project FP7-SPACE / SPA Project on a Multi-Hazard Open Platform for Satellite Based Downstream Services Project Number Project Acronym PHAROS Project Start Date 01/12/2013 Project Duration Contributing WP Dissemination Level 30 months WP5/T5.1 Public Contractual Delivery Date September 30, 2014 Actual Delivery Date September 30, 2014 Editor SPH Contributors -

2 Document History Version Date Modifications Source /9/2014 First version SPH 30/9/2014 i

3 Table of Contents List of Acronyms... iii Executive Summary Introduction Motivation Service Platform Requirements Functional Requirements Interfacing Requirements Non-functional Requirements Service Platform Architecture Overall Architecture Data repository / GIS service Enterprise Service Bus Workflow Engine Interfaces Interfaces to PHAROS subsystems Interfaces to external services SP Management and access control Addressing of requirements Conclusions References /9/2014 ii

4 List of Acronyms API CLI COP DAL S EO ESB GIS GUI OGC PHAROS REST SOS SP WCS WFS WMS WS-BPEL Application Programming Interface Command Line Interface Common Operational Picture Data Access Layer Developed System Decision Support System Earth Observation Enterprise Service Bus Geographical Information System Graphical User Interface Open Geospatial Consortium Project on a Multi-Hazard Open Platform for Satellite Based Downstream Services Representational State Transfer Sensor Observation Service Service Platform Web Coverage Service Web Feature Service Web Map Service Webservice Business Process Execution Language 30/9/2014 iii

5 Intentionally blank 30/9/2014 iv

6 Executive Summary Deliverable D5.1 reflects the work carried out so far in the frame of Task 5.1 and presents the architecture of the software-based Service Platform, describing its components, the purpose they serve and the way they interact with each other. The main motivation behind a generic multi-mission software Service Platform, as opposed to application-specific solutions, is the observation that most disaster management platforms share some common aspects such as acquisition and processing of Earth Observation (EO) data, leveraging information from in-situ sensors using data fusion algorithms, using Geographical Information Systems (GIS) for information management/representation and using workflows for incident management. It is thus possible to build a generic applicationagnostic core system to which all peripheral application-specific components will interface. In the PHAROS context, the general system requirements laid out in D2.4 are used to derive the specific technical requirements for the Service Platform (SP). Functional requirements refer to access control, user management, configuration, access to historical data, monitoring, geospatial data storage and incident management. Interfacing requirements mandate the standards-based communication of the SP with: a user front-end (GUI), secondary user services, EO data sources, simulation services, Decision Support Systems, alerting services as well as third-party external services, such as weather providers. Nonfunctional requirements are associated to robustness and resilience, stability, expandability and virtualisation. From the technical requirements, it is possible to specify an architecture which is fully modular and reconfigurable, by using pluggable mission-specific external services and modules, yet maintaining the core platform as generic as possible. The basic components of the Service Platform architecture are identified to be the following: a Data repository, for geospatial, sensor and generic data, allowing the Service Platform to act as information hub for all interconnected modules. Communication of data is achieved via open standardised services (OGC WMS/WFS/WCS/SOS). an Enterprise Service Bus for message routing, forwarding and adaptation, allowing the SP to act as mediator, facilitating communication in a unified way. a Workflow Engine for component orchestration, enabling the SP to run specific processes in order to pool data from sources, adapt them, invoke processing modules and integrate the final product. This process is application-domain specific, yet it is easily reconfigurable and can be edited even via graphical editors. Last, the SP implements Management-related services, which allow the supervision of its operation and the configuration of the individual components. It is concluded that it is feasible to design an efficient architecture which properly addresses all functional requirements, being at the same time open, scalable and generic/multi-mission. The proposed architecture exploits well-established contemporary paradigms in software engineering and relies on widely adopted standards and technologies. Service Platform interfaces mostly comply with global open standards (including the OGC specifications for geospatial and sensor data), thus promoting the applicability and future commercial adoption of the platform. 30/9/2014 5

7 1 Introduction In the PHAROS multi-hazard context, the Service Platform is intended to act as a generic enabler core system, able to interconnect and orchestrate a wide variety of sensor data sources, processing modules, decision support systems and user interfaces. In specific, the SP must be able to aggregate data collected from multiple sensors and route monitoring information among processing modules and decision support systems. For this purpose, the SP needs to implement a specific set of services, to be exposed in an open and interoperable manner to all interconnected systems and users. At the same time, in order to be as application-agnostic as possible, the service platform needs to be open and easily customisable to serve multiple heterogeneous application domains. This document reflects the work carried out so far in the frame of Task 5.1 and presents the architecture of the software-based Service Platform, describing its components, the purpose they serve and the way they interact with each other. The deliverable proceeds as follows: Chapter 2 describes the motivation behind a multimission service platform based on space technologies; Chapter 3 overviews the main Service Platform technical requirements; Chapter 4 presents the functional architecture of the SP, describes its components and the exposed interfaces; finally, Chapter 5 concludes the document. 30/9/2014 6

8 2 Motivation The topic of the integration of different space technologies - mostly in the fields of earth observation, satellite communications and navigation - for the purpose of effectively monitoring a hazard or a natural disaster, has been repeatedly addressed by several R&D efforts worldwide. In Europe, such research efforts have been mostly supported by the Copernicus (formerly GMES) programme [1], as well as the ESA IAP (Integrated Applications Promotion) programme [2]. Recent activities also promote the augmentation of satellite monitoring data with information from in-situ sensors [3], using state-of-the-art data fusion algorithms, towards more efficient and effective surveillance and disaster management. As outcomes of such efforts, several integrated commercial surveillance platforms have been developed, separately addressing several hazard/disaster types, such as wildfires, tsunamis, floods, earthquakes, tornados, volcano eruptions etc. While the common approach up to now has been the development of a separate, dedicated surveillance software solution for each of the aforementioned scenarios (such as [4]), the aim of PHAROS is to introduce a universal, multi-mission software Service Platform able to consolidate several usage scenarios in a single data processing and routing core. This common core should be seen as the gluing component among heterogeneous subsystems, bringing together sensor data sources, processing modules, decision support systems and user interfaces. The main motivation behind this multi-hazard concept is the observation that, despite the specificities of each specific hazard/disaster type, most disaster management platforms share some common aspects such as: acquisition and processing of Earth Observation (EO) data. leveraging information from in-situ sensors using data fusion algorithms. leveraging satellite navigation systems for location-based services. using Geographical Information Systems (GIS) for information management and representation. using workflows for incident management. interfacing to specialised modules for simulation, processing and decision support. interfacing to alerting systems for communicating/disseminating events. These common functionalities can be aggregated in a multi-hazard Service Platform. The concept is to keep the platform core as application-agnostic as possible, while achieving application-specific functionalities via the interfacing with specialised peripheral modules (such e.g. as wildfire simulators, tsunami sensors etc.). The obvious competitive advantages brought by the multi-hazard approach are that i) a multi-mission SP can be used to simultaneously monitor and manage several types of hazards, which is a feature required by e.g. civil protection authorities and ii) a multi-mission SP can be tailored to adapt to multiple usage scenarios, thus drastically widening the opportunities for commercial exploitation. Especially, when it comes to communication of georeferenced sensor data (either in-situ or satellite-based), the establishment of standardized open interfaces and APIs such as the Open Geospatial Consortium (OGC) family of standards promotes the dissemination and interfacing of sensor information in an open, standardized manner. By exploiting OGC standards, a multi-mission service platform can easily connect to a wide variety of application-specific sensors, possibly from various vendors, in order to be tailored and customized, without being restricted by vendor-specific interfaces. 30/9/2014 7

9 3 Service Platform Requirements This chapter intends to provide a comprehensive listing of the technical requirements for the PHAROS Service Platform, which will guide the subsequent technical specification/definition phase. The technical requirements trace back to and are derived from the general system requirements, as listed in Deliverable D2.4 [6]. Each technical requirement is associated with one or more system requirements, as identified. Technical requirements can be categorised in several ways. In this chapter we adopt the following classification: Functional requirements refer to tangible functionalities of the SP. They are commonly associated with the functionalities defined in D2.8. Interfacing requirements are functional requirements referring to the ability of the component to interface with other components/services in order to exchange information. Non-functional requirements refer to qualities of the SP i.e. how well it is expected to perform. Examples of non-functional requirements are: performance, capacity, scalability, availability, latency. Requirements are also categorised in terms of importance. Requirements associated with the Developed System () development level, as defined in D2.4, are considered mandatory and are absolutely needed to be fulfilled in order to realise all the foreseen use cases. On the other hand, requirements associated with the Target System (TS) development level are considered optional and are recommended to improve several aspects of the system. 3.1 Functional Requirements PHAROS_REQ_SP_F_01 Access control The SP must be able to control access to the users (primary of secondary) via authentication and authorisation procedures. Part of the information produced and processed within the PHAROS system is not considered public domain and its dissemination should be controlled. PHAROS_REQ_SYS_GL_08 Verification that access to data is not permitted to a) nonauthenticated and b) non-authorised users. Notes Authentication may be achieved either via credentials or digital certificates (or both) 30/9/2014 8

10 PHAROS_REQ_SP_F_02 User management The SP must be able to offer the capability to manage users with different access permissions. The PHAROS system is assumed to be operated by users with different privileges. PHAROS_REQ_SYS_GL_09, PHAROS_REQ_SYS_GL_11, PHAROS_REQ_SYS_GL_12, PHAROS_REQ_SYS_GL_13, PHAROS_REQ_SYS_GL_14 Validation of user management procedures: user creation, user deletion, access rights modification. Verification that user credentials are stored in encrypted form. Notes - PHAROS_REQ_SP_F_03 Management and reconfigurability The SP must provide means to configure its operational parameters. The SP needs to have flexibility in order to address diverse user needs in multi-application scenarios PHAROS_REQ_SYS_GL_15, PHAROS_REQ_SYS_GL_16 Modification of key system parameters by the system admin, verification that the parameters have been properly adjusted Notes List of configurable parameters to be defined. PHAROS_REQ_SP_F_04 Access to historical data The SP must be able to store data (sensor data, events, incidents) and provide access to past data within a given 30/9/2014 9

11 time window. Users need to have access to past data for short-term viewing, logging and also post-incident analysis PHAROS_REQ_SYS_RA_13, PHAROS_REQ_SYS_RA_18, PHAROS_REQ_SYS_MGM_08, PHAROS_REQ_SYS_MGM_09 Retrieval (by a test web client) of past data, events and incidents via the SP web API for a specified time window Notes - PHAROS_REQ_SP_F_05 System monitoring The SP must be able to provide information on key system metrics. Necessary so that the administrator is aware of the resources used and can act proactively in case of malfunctions and/or resources outage. PHAROS_REQ_SYS_RA_19 Retrieval (via the GUI or other means) of key system parameters in real time. Cross-checking with metrics reported by system tools, when available. Notes Set of monitored parameters to be defined. PHAROS_REQ_SP_F_06 Storage and communication of geo-referenced data The SP must be able to store and make available on request geo-referenced information. All incoming data and events must be stored/logged. Most information associated with risk management is georeferenced. PHAROS_REQ_SYS_RA_02, PHAROS_REQ_SYS_RA_03, PHAROS_REQ_SYS_RA_04, PHAROS_REQ_SYS_RA_05, 30/9/

12 PHAROS_REQ_SYS_RA_10, PHAROS_REQ_SYS_RA_11, PHAROS_REQ_SYS_RA_14, PHAROS_REQ_SYS_RA_15, PHAROS_REQ_SYS_RA_16, PHAROS_REQ_SYS_RA_22, PHAROS_REQ_SYS_MGM_04, PHAROS_REQ_SYS_MGM_08 Successful publication to the SP of georeferenced data (raster images, vector data, other sensor data). Verification that the data are stored. Retrieval/query by data ID and/or spatio-temporal window. Notes Only some indicative associated system requirements are shown above, since most of the system requirements rely on proper data storage and handling. PHAROS_REQ_SP_F_07 Incident management The SP must be able to handle incident information and to support the association of data and events to a specific incident. Grouping data and events to incidents is considered a valuable assistance to end users for risk management. PHAROS_REQ_SYS_MGM_19 Verification of incident management procedures (creation/ modification/ deletion). Verification (with multiple streams of emulated data) that data are properly categorised to incidents. Assumptions/Dependencies A module external to the SP is assumed to manage the categorisation of data and events to incidents and to dictate the associated rules. Notes - PHAROS_REQ_SP_F_08 Information routing The SP must be able to act as a mediator, appropriately routing information among different modules. Having the SP as a mediator greatly promotes system 30/9/

13 scalability and interoperability, since each module needs to communicate only with the SP and not with all peer modules. PHAROS_REQ_SYS_COM_02 Publication of information by all PHAROS modules, verification that the information has been properly stored, verification that the information is properly routed to the recipient. Notes Routing rules can be either static or dynamic. 3.2 Interfacing Requirements PHAROS_REQ_SP_IF_01 Interface to GUI for interaction with end users The SP must be able to communicate with a GUI front-end module in order to expose its services to primary users. A user-friendly graphical user interface is considered essential for the adoption and the commercial viability of the PHAROS platform. PHAROS_REQ_SYS_GL_01, PHAROS_REQ_SYS_MGM_03, PHAROS_REQ_SYS_MGM_10, PHAROS_REQ_SYS_COM_23 Verification of all GUI functionalities which involve communication with the SP; e.g. COP viewing, sensor data presentation, S and simulation results, incident management (creation/modification/deletion) etc. Notes Only some indicative associated system requirements are shown above, since most of the system requirements rely on proper SP<>GUI communication. PHAROS_REQ_SP_IF_02 Interface to secondary user services The SP must be able to provide means for data access by secondary users. 30/9/

14 Secondary users are assumed a main stakeholder for the system, yet they are not assumed to access the PHAROS system directly via the GUI. PHAROS_REQ_SYS_GL_03, PHAROS_REQ_SYS_GL_04, PHAROS_REQ_SYS_GL_05, PHAROS_REQ_SYS_RA_14, PHAROS_REQ_SYS_RA_15, PHAROS_REQ_SYS_RA_16, PHAROS_REQ_SYS_COM_17, PHAROS_REQ_SYS_COM_18, PHAROS_REQ_SYS_COM_21 Retrieval by a test client service (COTS or to be developed for testing purposes) of the information which will be exposed to secondary users, including events, simulation results, incidents etc. Notes The SP will expose a web-based API for this purpose. The development of GUI services for secondary users for the presentation of information (web platforms or stand-alone applications) is out of the scope of the project. PHAROS_REQ_SP_IF_03 Interface to EO data sources The SP needs to be able to receive data from EO data sources. EO data are considered critical for hazard monitoring. PHAROS_REQ_SYS_RDM_01, PHAROS_REQ_SYS_RDM_02, PHAROS_REQ_SYS_RDM_03, PHAROS_REQ_SYS_RA_22 Successful reception of processed EO images with associated metadata, presentation of the EO image via the GUI. Notes Data may either be pulled from an EO service provider or published to the SP by a PHAROS EO processing service. PHAROS_REQ_SP_IF_04 Interface to simulation services 30/9/

15 The SP needs to send data to simulation services and retrieve results Simulation data are considered critical for hazard assessment and management. PHAROS_REQ_SYS_RA_01, PHAROS_REQ_SYS_RA_02, PHAROS_REQ_SYS_RA_03, PHAROS_REQ_SYS_RA_04, PHAROS_REQ_SYS_RA_05, PHAROS_REQ_SYS_RA_06, PHAROS_REQ_SYS_RA_08, PHAROS_REQ_SYS_RA_09, PHAROS_REQ_SYS_RA_10, PHAROS_REQ_SYS_RA_11, PHAROS_REQ_SYS_RA_21 Successful dispatch of simulation parameters to the simulation service, successful retrieval of results and presentation via the GUI. Cross-checking by manual invocation of the simulation service. Assumptions/Dependencies The simulation service is assumed to expose a Webservice for invocation and control. Notes Refers to simulation either of incident evolution or risk assessment. Simulations will be either invoked by the SP or run periodically. PHAROS_REQ_SP_IF_05 Interface to Decision Support Systems The SP shall send data to and receive results from Decision Support Systems. S are considered a valuable tool in the risk management process. PHAROS_REQ_SYS_MGM_01, PHAROS_REQ_SYS_MGM_02 Successful dispatch of sensor/simulation data to the S, successful retrieval of results, presentation to the GUI. Cross-checking by manual invocation of the S. Notes Apart from exchanging data, S are also assumed to trigger workflows. 30/9/

16 PHAROS_REQ_SP_IF_06 Interface to alerting services The SP must be able to connect to alerting services (gateway) for dispatching alerts. Population alerting is considered an essential component in risk management. PHAROS_REQ_SYS_COM_03, PHAROS_REQ_SYS_COM_04, PHAROS_REQ_SYS_COM_07 Verification that the alert message has been properly received by the alerting gateway. Notes - PHAROS_REQ_SP_IF_07 Interface to external weather services The SP must be able to connect to external weather services in order to retrieve weather data (current conditions and forecasting). Weather data are essential both as part of the COP but also as input for simulations and decision support. PHAROS_REQ_SYS_RA_07 Verification (via the SP management GUI) that latest weather data have been properly acquired and stored in the SP repository. Cross-checking with the native GUI of the weather service provider. Assumptions/Dependencies Assumes the existence of a weather service provider with a documented API and the capability to connect over the Internet Notes - PHAROS_REQ_SP_IF_08 IP-based communication All SP interfaces to the GUI, data sources and modules need to be IP-based. 30/9/

17 GUI, data sources and modules may be in a remote location, so that communication via the public Internet (or via a private network) needs to be possible. PHAROS_REQ_SYS_GL_21, PHAROS_REQ_SYS_MGM_10, PHAROS_REQ_SYS_MGM_11, PHAROS_REQ_SYS_MGM_13 Successful remote interconnection with the PHAROS GUI, all PHAROS data sources and processing modules. Notes - PHAROS_REQ_SP_IF_09 Standards-based communication SP interfaces shall comply with open standards for information exchange and representation to the maximum possible extent. Communication will be secure (encrypted) where possible. Standards-based communication is crucial for the interoperability and the expandability of the SP. PHAROS_REQ_SYS_GL_18, PHAROS_REQ_SYS_MGM_17, PHAROS_REQ_SYS_COM_01 Examination of the data communication streams with protocol analysers. Notes Non-functional Requirements PHAROS_REQ_SP_NF_01 Robustness and resilience The SP needs to be stable and resilient to faults. The PHAROS system handles critical information, so it needs to maintain high availability. PHAROS_REQ_SYS_GL_17 30/9/

18 Verification that the SP achieves 99,9% availability for a period of one month. Verification that the operation of the SP is fully restored and critical data are maintained after a service restart. Notes - PHAROS_REQ_SP_NF_02 Stability in multi-user operation The SP must be able to support a number of users operating simultaneously. The PHAROS system is supposed to be accessed by several users, including actors on the field. PHAROS_REQ_SYS_GL_18 Assessment of system stability under simultaneous access by 5 users (or even more, subject to availability of infrastructure for emulation). Notes - PHAROS_REQ_SP_NF_03 Expandability The SP needs to be able to be easily extended with new sensors, modules etc. The SP is assumed to offer a universal solution for diverse user needs in multi-hazard scenarios. PHAROS_REQ_SYS_GL_18 Verification that the addition of a new sensor platform or a new processing module can be achieved without modifications in the SP code. Assumptions/Dependencies The sensors/modules to be added need to expose interfaces conforming to a pre-defined set of protocols. 30/9/

19 Notes Further promoted by the use of open standards for data exchange. PHAROS_REQ_SP_NF_04 Virtualisation The SP needs to be able to run on virtualised IT infrastructures. Large-scale SP deployments involving considerable resources and/or with high availability constraints will require deployment on data centre and/or cloud infrastructures. PHAROS_REQ_SYS_GL_20 Verification that the SP operates as expected (all functionalities are available) in a virtualised infrastructure. Assumptions/Dependencies The virtualisation technology will need to support the OSs which are compatible with the SP application. Notes - 30/9/

20 4 Service Platform Architecture 4.1 Overall Architecture Taking into account the requirements set out in the previous chapter, a set of basic services which need to be implemented by the SP can be identified, as shown in Figure 4-1. The aim is to adopt a fully modular and reconfigurable architecture, by using pluggable missionspecific external services and modules, yet maintaining the core platform as generic as possible. Figure 4-1: Service Platform basic services and external modules The main services which need to be provided by the Service Platform are (briefly mentioned below and detailed in the sections to follow): i. Data storage. The Service Platform is assumed to store all raw and processed data in a central repository, thus acting as information hub for all interconnected modules. For the communication of georeferenced raster and vector data (e.g. base map data, EO images, simulation results etc.), a GIS database service is essential, exposing open interfaces, such as the OGC Web Map Service (WMS), Web Feature Service (WFS) and Web Coverage Service (WCS). Also, for in-situ sensor data, in order to be able to easily accommodate various types of sensors, the platform needs to expose a standards-compliant interface, such as the OGC Sensor Observation Service (SOS). ii. Message Routing, Forwarding and Adaptation. Since data have to be exchanged among modules, the SP needs to enable the communication among them in a unified way, acting as a mediator, also adapting the information as well as the interfacing protocol, according to the specification of each module. In this context, the SP should also allow the communication of information according to the publish/subscribe paradigm; an external module should be able to subscribe to specific information and receive a notification when such information becomes available. For all these purposes, a dedicated Enterprise Service Bus is the most appropriate component. iii. Component Orchestration. The successful implementation of each disaster management scenario is associated with a specific business logic, i.e. a conditional sequence under which 30/9/

21 data is retrieved from sources, processed and sent to the system outputs. For this purpose, the Service Platform includes a Workflow Engine, which runs a specific process in order to pool data from sources, adapt them, invoke processing modules and integrate the final product. This process is application-domain specific, yet it is easily reconfigurable and can be edited even via graphical editors. Last, the SP needs to implement Management-related services (not shown in Figure 4-1), which allow the supervision of its operation and the configuration of the individual components. SP Management also allows monitoring the connected services and subsystems (online/offline status, availability etc.). Figure 4-2 depicts a high-level view of the Service Platform architecture, also showing the interconnections between components. Figure 4-2: Service Platform architecture The following sections describe in more detail the role and functionality of each component. 4.2 Data repository / GIS service The data repository of the SP essentially comprises three main components: a repository for geospatial data (GIS service), a repository for in-situ sensor data and a repository for generic platform information. The geospatial data repository is actually an implementation of a GIS service. It allows the publication and retrieval of both raster and vector data via open standardised interfaces, mostly WMS and WFS (also supporting REST communication, see Sec. 4.5), enabling various heterogeneous services and users to share, process and edit geodata. Data conversion is also possible among main popular formats, such as shapefiles, GML/KML, GeoTIFF and GeoJSON. Stored vector data can also be internally digitised and retrieved as 30/9/

22 raster, allowing simpler client and user GUI implementations, since the need for rendering at the GUI is minimised. Within the repository, data are hierarchically organised, so that they can be easily categorised according to both the source and the nature of information. Examples of PHAROS data to be published to and retrieved from the geospatial repository are: EO images (raw or processed), incident (fire, flood etc.) fronts and perimeters, base map layers, vegetation maps and simulation results (risk/hazard assessment maps, incident evolution/propagation curves). The in-situ sensor data repository allows the publication, handling and retrieval of sensor information and sensor observations. Specifically, the following transactions are supported: insertion of new sensor, description of sensor, insertion/retrieval/deletion of observations (i.e. observed properties), insertion/retrieval/deletion of results (i.e. property values), accompanied with their unit of measure. All these transactions are communicated over the OGC SOS (Sensor Observation Service). Examples of PHAROS data to be published to and retrieved from the sensor data repository are in-situ sensor information (e.g. sensor status and locations, including locations of on-site personnel) and measured metrics (e.g. weather data, alerts etc.). Finally, the generic platform repository is used for information which does not fit in either the geospatial or the sensor database. It is implemented via a common relational database with a data access layer and a REST interface front-end. Examples of PHAROS data to be published to and retrieved from the generic platform repository are incident information, user data and miscellaneous platform and service configuration parameters. 4.3 Enterprise Service Bus The role of the Enterprise Service Bus (ESB) within the PHAROS SP is to promote agility and flexibility with regard to the communications among the different PHAROS subsystems, mostly when it comes to control/invocation messages, rather than storage and retrieval of data, which is already handled by the data repository, as aforementioned. Thanks to the ESB, each PHAROS subsystem does not have to directly interface with each of the other subsystems (e.g. the S with the simulator) for the communication of control and data messages. Instead, it interfaces solely with the ESB component of the SP which adapts and forwards the message appropriately to its destination. Furthermore, the operation of each subsystem is not blocked due to reduced availability of the peer subsystem, since all messages are buffered/queued until the recipient becomes available. In order to serve this role, the ESB constitutes an integration broker (middleware), which provides an abstraction layer on top of a messaging system. The ESB provides the following core services: multi-interface communication (REST, SOAP, Sockets, FTP, etc.) routing of messages among different subsystems/components data transformation, protocol conversion message queuing message sequencing support of service registration / subscription / discovery In PHAROS, the Enterprise Service Bus is implemented around a common message bus/ message queue which interfaces with several protocol adapters whose role is to translate external messages and push/pull them to/from the queue. 30/9/

23 Within the SP, the ESB communicates with the data repositories for storing and retrieving data and with the Workflow Engine (see Sec. 4.4) for communicating workflow commands and results. 4.4 Workflow Engine The workflow engine is the main active orchestrating component of the SP. Its role is to execute workflows and invoke the different PHAROS subsystems including other SP components- according to a conditional sequence. Workflows to be executed have been defined using an appropriate XML-based description language (WS-BPEL) [5] created with the assistance of a graphical workflow editor. Published workflows are stored in a local Workflow Repository. Prior to executing the workflow, the engine checks the workflow document for validity and also verifies the access rights of the user or the service. Then, according to the conditions set, different subsystems are invoked using webservice-based calls, in a Service Oriented Architecture (SOA) paradigm. The Workflow Engine internally communicates with the data repositories for storing and retrieving data and with the Enterprise Service Bus for communicating workflow commands and results. More details on the workflow engine and especially on the workflows to be used in PHAROS are to be found in Deliverable D5.2 (Workflows Design Document). 4.5 Interfaces Interfaces to PHAROS subsystems The PHAROS subsystems interact with the Service Platform for two purposes a) for sending and retrieving data and b) for triggering workflows. Data exchange is mainly performed over HTTP directly to the SP Data repository. Geospatial data can be published/retrieved via the OGC-compliant services (WFS, WCS) and can be retrieved also fully rasterised via the WMS service. In addition, a REST-based interface will be available. Sensor data is exchanged via the OGC SOS service, while generic data can be published and retrieved via a proprietary HTTP REST interface, whose API will be defined within the PHAROS project. Workflow triggering can be conducted via the interfaces exposed by the workflow engine, commonly HTTP REST and SOAP, depending on the binding chosen Interfaces to external services Apart from the data provided by PHAROS subsystems, it is foreseen that the PHAROS workflows will also involve externally available information by third party providers, such as e.g. weather data. For this purpose, the PHAROS SP will implement service-specific interfaces as plug-ins which will retrieve the information from the external service provider using the service provider s API, adapt it and feed it to the SP via the already provided open interfaces. It is also foreseen that PHAROS-generated information will need to be communicated to external services, including secondary users. For this purpose, controlled access to the OGC interfaces for direct data acquisition will be possible. In addition, a service gateway functionality will be possible via the ESB; external services will be able to subscribe to 30/9/

24 data/events and retrieve them via a variety of interfaces (HTTP REST, SOAP, FTP, etc.). More details on the SP interfaces to PHAROS subsystems as well as external services, including specific technical interface specifications and message formats and examples are to be found in Deliverable D5.3 (Interfaces and Service Gateway). 4.6 SP Management and access control The SP Management component allows the configuration and monitoring of the various SP services as well as of the SP as a whole. The SP Management component consists both of a centralised service (for managing platform-wide parameters) as well as distributed management services for each of the aforementioned SP components. SP management procedures allow, among others: configuration of access rights configuration of interfaces deployment of workflows creation/ modification/ update of data repository overview of data repository contents and basic visualisation monitoring of basic system resources (CPU, RAM utilisation etc.) security settings for the various exposed interfaces Interaction with the user (platform administrator) is facilitated by both graphical web-based interfaces as well as CLI access. 4.7 Addressing of requirements The design of the Service Platform and its breakdown into specific components aims at the proper addressing of all functional, interfacing and non-functional requirements, as laid out in Section 3. Table 4-1 below explains how all identified requirements are effectively addressed by the proposed design. Table 4-1: Addressing of requirements by SP architectural choices Requirement name How it is addressed PHAROS_REQ_SP_F_01 Access control Access control (by means of credentials) is an inherent feature of all SP components (Data Repository, ESB, WF engine, Management) so that unauthorised access is prevented. PHAROS_REQ_SP_F_02 User management User management is supported across all SP components (Data Repository, ESB, WF engine, Management). PHAROS_REQ_SP_F_03 Management and reconfigurability The Management components (overall SP management, Data repository, ESB, WF engine management) allow the configuration of several operational system parameters. PHAROS_REQ_SP_F_04 Access to historical The storage of all incoming data into the Data 30/9/

25 data Repository allows future access and retrieval. PHAROS_REQ_SP_F_05 System monitoring The Management components (overall SP management, Data repository, ESB, WF engine management) allow the monitoring of several system metrics. PHAROS_REQ_SP_F_06 PHAROS_REQ_SP_F_07 Storage and communication of geo-referenced data Incident management Fulfilled by the Geospatial data repository. Incident information can be stored in the Generic Data repository. All data structures will accommodate proper metadata in order to be explicitly associated to a specific incident. PHAROS_REQ_SP_F_08 Information routing Fulfilled by the Enterprise Service Bus. PHAROS_REQ_SP_IF_01 PHAROS_REQ_SP_IF_02 PHAROS_REQ_SP_IF_03 PHAROS_REQ_SP_IF_04 PHAROS_REQ_SP_IF_05 PHAROS_REQ_SP_IF_06 PHAROS_REQ_SP_IF_07 PHAROS_REQ_SP_IF_08 PHAROS_REQ_SP_IF_09 PHAROS_REQ_SP_NF_01 PHAROS_REQ_SP_NF_02 Interface to GUI for interaction with end users Interface to secondary user services Interface to EO data sources Interface to simulation services Interface to Decision Support Systems Interface to alerting services Interface to external weather services IP-based communication Standards-based communication Robustness and resilience Stability in multi-user operation The GUI will directly exploit all SP exposed interfaces (OGC, REST etc.) to retrieve/publish data and to invoke workflows. Secondary user services may either acquire data directly from the OGC services or subscribe to messages and events via the ESB. EO data and processed information can be stored to the SP (Geospatial repository) via the OGC interfaces. For the pull scenario (retrieval of data from an EO provider), the appropriate plug-in will be developed. Simulation services are invoked by the Workflow engine and store their output directly to the Data repository. Decision services are invoked by the Workflow engine and in turn invoke workflows as welland store their output directly to the Data repository. The alerting gateway interfaces directly with the ESB. A plug-in implementing the weather service provider s API to acquire information, will be developed. All defined interfaces are IP-based. All defined interfaces rely on open standards, at least for message exchange (OGC, HTTP REST etc.). The SP will be developed using the latest.net framework and rely, where possible, on welltested commercial software components. The exposed interfaces, as well as the chosen application paradigms (GIS database, ESB, WF engine) are inherently designed to support multi-user operation. 30/9/

26 PHAROS_REQ_SP_NF_03 Expandability With the given design, there is no theoretical limitation on the number of modules which can interface to the SP. PHAROS_REQ_SP_NF_04 Virtualisation The proposed design is hardware-agnostic and can be implemented into one or more Virtual Machines. 30/9/

27 5 Conclusions Deliverable D5.1 identified the technical requirements for the PHAROS Service Platform and presented its architectural design. It is concluded that it is feasible to design an efficient architecture which properly addresses all functional requirements, being at the same time open, scalable and generic/multi-mission. The proposed architecture exploits wellestablished contemporary paradigms in software engineering and relies on widely adopted standards and technologies. Service Platform interfaces mostly comply with global open standards, thus promoting the applicability and future commercial adoption of the platform. D5.1 conclusions and design decisions will be used as input to T5.1 (Service Platform architecture), T5.2 (Rule/Workflow Engine) and T5.3 (Interfaces and Service Gateway) which will develop the core components of the SP, the workflow engine and the interfaces respectively. 30/9/

28 6 References [1] Copernicus, the European Earth Observation Programme, [2] European Space Agency Integrated Applications Promotion programme, [3] M. Guerriero, P. Willett, S. Coraluppi, C. Carthel, "Radar/AIS data fusion and SAR tasking for Maritime Surveillance," 11th International Conference on Information Fusion, 2008, vol., no., pp.1,5, June July [4] A. Burkle, B. Essendorfer, "Maritime surveillance with integrated systems," 2010 International Waterside Security Conference (WSS),, vol., no., pp.1,8, 3-5 Nov [5] Web Services Business Process Execution Language, v. 2.0, OASIS Standard, 11 April 2007 [6] J. Mulero Chaves et al. PHAROS Deliverable D2.4: PHAROS Requirements and System Engineering First Issue, July /9/