ORCHESTRA: Developing a Unified Open Architecture for Risk Management Applications

Transcription

1 Frascati ORCHESTRA: Developing a Unified Open Architecture for Risk Management Applications The ORCHESTRA service architecture, interoperability challenges and SOA solution José Esteban, Thomas Usländer, Ioannis Kanellopoulos ORCHESTRA Consortium Table of contents ORCHESTRA overview More info at: Interoperability challenges and the Reference Model ORCHESTRA Architecture (RM-OA) chaining Slide 2 1

2 ORCHESTRA overview Presented by José Esteban (ATOS) Slide 3 ORCHESTRA Goals Improve efficiency risk management activities through: The design and implementation of an open service-oriented architecture based on standards (de-facto and de-jure) and in INSPIRE and GMES specifications To validate the architecture in multi-risk scenarios, developing the sets of services that are most useful and adequate for the risk management end users Slide 4 2

3 What ORCHESTRA is NOT ORCHESTRA is NOT: A system (centralised or distributed) to be used in risk management Each institution in each European region must work with the systems they consider more appropriate according to their needs, characteristics, policies, etc. A list of methodologies or procedures for risk management Each institution in each European region must have the flexibility and autonomy to establish the most adequate to their case An effort of systems integration Because then it would solve with a prohibitive cost the actual situation, but not the future ones Slide 5 What ORCHESTRA is ORCHESTRA is the definition of a service architecture that enables interoperability at an European level ORCHESTRA defines the interface that a software service must have in order to be interoperable ORCHESTRA does not only design the architecture but also develops a list of services for risk management in order to: Validate the architecture in the pilots Provide this software together with the specifications, so the interested institutions can see how to make their own services and applications interoperable ORCHESTRA cannot develop all the required services for risk management. In fact, the continuous emergence of new needs, together with the flexibility and interoperability that ORCHESTRA provides, constitute the project business case Slide 6 3

4 Current Status ORCHESTRA has published the second version of the RM-OA and service specifications: ORCHESTRA is providing feedback to OGC for the extension of existing standards for geographical information ORCHESTRA is being deployed in 4 pilots, 1 of them for the experts analysing risks of the EU Member States ORCHESTRA is being applied to the tsunami early warning system of the German government in the Indian Ocean ( ) ORCHESTRA is cooperating with EU initiatives like INSPIRE (European Directive for data harmonisation) and GMES. ORCHESTRA is cooperating with other projects (in the EU and abroad) that are based on or use ORCHESTRA results. Slide 7 Slide 8 4

5 Interoperability challenges and the Reference Model ORCHESTRA Architecture (RM-OA) Presented by Thomas Usländer (IITB) Slide 9 Problem statement of a Civil Protection or Environmental Agency Conceptual ref.: What is a risk? How big is the risk of a forest fire in a certain region of the Pyrenees in a given season? Spatial ref.: cross-border, crossadministration Temporal ref.: Time series and prognostics Thematic ref.: Forest Fire Vegetation Geology Cartography Meteorology Settlements Industry Traffic -... Quelle: Slide 10 5

6 Question for the ORCHESTRA Architecture How to find, select, access, integrate and process all relevant information and services for Environmental Risk Management? Slide 11 ORCHESTRA Architectural Approach (1) Instead of individual Risk Management systems, that are just integrated and available in one organisation... the individual systems of different organisations are networked by means of a well-specified serviceoriented architecture (SOA) and thus can interact in a controlled manner. Slide 12 6

7 ORCHESTRA Architectural Approach Info Centre Analysis Maps Archive Control centre Knowledge Base(s) Catalog(s) Thematic data Spatial data Metainformation Documents Sensors Slide 13 Claim of the ORCHESTRA Reference Model Open -oriented Architecture improving Interoperability Public and free specifications Use of existing standards Contribute to the evolution of standards Syntactic encodings Structural schemas, interfaces Semantic meaning Slide 14 7

8 RM-OA: Basis and Extensions/Adaptions User Requirements Risk Management Projects Req. Analysis functional, informational and qualitative System Requirements IT Challenges Architectural Principles ISO RM-ODP process model SOA Reference Model for the ORCHESTRA Architecture (RM-OA) conceptual model Web s OGC geospatial services service meta-model ISO 191xx Semantics W3C SOA Reference Model OASIS Slide 15 RM-OA Design Process: Iterations User Requirements Risk Management Projects ORCHESTRA Pilots System Requirements IT Challenges Architectural Principles ISO RM-ODP process model SOA Reference Model for the ORCHESTRA Architecture (RM-OA) OGC 07-xxx BP OGC DP conceptual model Web s OGC DP OGC geospatial services service meta-model ISO 191xx Semantics W3C SOA Reference Model OASIS Slide 16 8

9 Engineering of ORCHESTRA Networks Requirements F: functional I: informational Q: Quality of /non-functional Problem analysis abstract design ORCHESTRA Reference Model F I Q Abstract Platform concrete design W3C Web s Concrete Platform engineering Operation Policies Networks Slide 17 ORCHESTRA Result (1): Abstract Architecture Problem ORCHESTRA Architecture analysis abstract design Meta-model s and Information F I Q /Interface Abstract Specs (UML) of Architecture s Abstract Platform (Meta-)Information Models (UML) concrete design Concrete Platform engineering Networks Slide 18 9

10 ORCHESTRA Architecture s (1) Capabilities Interface (A)Synchronous Interaction I/F Transaction I/F Feature Access Map and Diagram Document Access Gazetteer Thesaurus Access Schema Mapping Interface Format Conversion Coordinate Operation Ontology Access Chain Access Access Search resources Control Monitoring Catalogue Document Indexing Slide 19 ORCHESTRA Architecture s (2) Query Mediation Interface Inferencing Interface Annotation Sensor Access Sensor Planning Semantics Access Search Sensor Support User Management Authorisation Authentication resources Control Monitoring Monitoring Slide 20 10

11 ORCHESTRA Result (2): Application Architecture Problem ORCHESTRA Architecture analysis abstract design Meta-model s and Information F I Q /Interface Abstract Specs (UML) of Architecture s Abstract Platform concrete design Concrete Platform engineering Networks (Meta-)Information Models (UML) thematic extension ORCHESTRA Application Architecture Thematic s (UML) Thematic (Meta-)Information Models (UML) Slide 21 ORCHESTRA Thematic Support s Processing for join and aggregation normalisation classification map algebra Simulation Management s Processing Access Search resources Control Monitoring Collaboration Project Management Support Communication Calendar Reporting Slide 22 11

12 Toolbox for Risk Management s Risk-neutral/ Risk-specific / Interface Specs e.g. Differential Risk Map Calculation parameter refinement e.g. Translating Feature Access Interface re-usage ORCHESTRA / Interface Specs e.g. Processing e.g. Feature Access I/F e.g. Schema Mapping I/F Slide 23 ORCHESTRA Result (3): Implementation (Specs) Problem analysis abstract design F I Q Abstract Platform concrete design Concrete Platform engineering Networks ORCHESTRA Implementation Specifications Specification of Web Platform (WSDL, SOAP, GML Profile) Development Tools (UML platform) Development Frameworks /Interface Impl. Specs Implementation Components Slide 24 12

13 Ex.: ORCHESTRA Container Framework HTTP SOAP Axis2 web application Axis Handlers s Modules logging module,... specific modules Message Receiver op1 Skeleton opn service specific impl. osl.jar,... Monitoring osl.jar, UAA s UAA User s Management Authentication Authorisation Axis2 Jars Slide 25 ORCHESTRA Result (4): Networks F Problem analysis abstract design Abstract Platform I concrete design Q ORCHESTRA Implementation Architecture Integration of Components Integration of Application Components Network Management (Configuration and Monitoring) Policy Configuration (e.g. discovery, access control) Concrete Platform engineering Networks ORCHESTRA Pilot Applications Forest Fire Marine Flooding Geo-hazards Slide 26 13

14 Example use of semantics: Semantic Catalogue Q R Ontology Access Ont. Semantic Query Proc. Semantic Report Gen. Semantic Add-On of ORCHESTRA Catalogue Q R... Q R ORCHESTRA Catalogue (cascading) Q Q R R Cat. e.g. X OGC Catalogue ebrim ISO AP Q R Catalogue X Schema Y ORCHESTRA Catalogues (Adapters) Slide 27 Answers of the ORCHESTRA Architecture How to 1 find, select, access, integrate and process all relevant information and services for Environmental Risk Management? 2 Integrated meta-information approach for information and services 3 Rules to define service and (meta-) information models 4 Generic interface and service types validated through implementation! Slide 28 14

15 chaining Presented by Ioannis Kanellopoulos (JRC-IES) Anders Friis-Christensen, Roberto Lucchi, Michael Lutz, Nicole Ostlaender, Ioannis Kanellopoulos SDI Unit Institute for Environment and Sustainability Joint Research Centre European Commission Slide 29 Outline chaining: Why? Chain Access (SCAS) Issues and service chaining in a semantics scenario Slide 30 15

16 Why service chaining? chained applications are built on top of existing services and can be exposed as new services EC Data Integration Processing data Aggregation EC data distribution Uses Accessing distributed data Administrative units data Reporting Visualising Italy data distribution Spain data distribution MS data distribution Italy data Spain data... Any MS data Distributed MS Data Resource sharing Distributed computing Integration Design of inter-organizations applications Slide 31 chains (ISO 19119) Based on the Reference Model of Open Distributed Processing definition of chain of actions, a service chain is defined in ISO as a sequence of services where, for each adjacent pair of services, occurrence of the first action is necessary for the occurrence of the second action. ISO lists three different service composition approaches: User defined chaining (transparent chaining) A user creates the service chain and manages its execution (no explicit description of the chain) Workflow-managed chaining (translucent chaining) A user invokes a service that controls the chain (the user can provide some inputs parameters during the execution of the chain) Aggregate service (opaque chaining) A single service coordinates the execution of all services in the chain. The user may or may be not aware of the services behind the aggregate service. Slide 32 16

17 chaining via aggregate services Why aggregate service? Existing networking technologies support aggregate services It does not prevent the interaction with the user (some intermediate points can be programmed) Fast integration to new functionalities, that can be also defined on the fly by means of semantics (e.g. based on ontologies) Definitions chain description: it is an explicit description of a concrete service chain in some workflow language. chain instance: it is a service instance (the aggregate service) which is exhibited by a workflow engine executing its corresponding service chain description. Slide 33 Chain Access (SCAS) The ORCHESTRA architecture includes the SCAS type: chain descriptions SCAS chain instances The role of SCAS is to manage the service chain instances domain The SCAS Orchestra service type introduces standard service interface for: Deploying service chain instances Registering service chain description MI and service chain instance MI in the catalogue Slide 34 17

18 Chain Access Example: Peunha-1 Integrator SCAS Client 1 Provide description and reference to catalogue service Forest Fire Frequency Sevice Chain Access 2 Register new service Deploys 3 Catalogue Descriptions Slide 35 Workflow for Chain Access Peunha-1 implemented by using service chain instance Legend Analyst PEUNHA Client Forest Fire Frequency : aggregate service MAS 1 Provide execution parameters FAS: Feature access service FAS-X: translating FAS Aggregate forest fire features 4 Forest Fire Frequency MAS: Map access service 2 Retrieve forest fire features Join & Processing FAS -X Aggregation service accesses 3 FAS Retrieve admin. unit features accesses MS Forest Fire registration Administrative units uses Mapping Rules to Common Schema Slide 36 18

19 chaining issues (1) Harmonizing/managing interactions between services Interaction modalities (synchronous/asynchronous, transactions?) Data types Security How to govern the access policies to all the services involved in the chain? Statefulness Managing multiple executions of service chain sessions Performance Network overload caused by the data moved between services Introduction of different data passing modalities Slide 37 chaining issues (2) Creating service chain descriptions (semi-)automatic composition Meaningful service MI for discovery (using semantics) Lineage (MI) Created using workflow descriptions to trace the processing path of data Enables the discovery and evaluation of processed data Slide 38 19

20 Thank you for your attention José Fernando Esteban Lauzán Tel: Fax: Thomas Usländer Tel: Fax: Ioannis Kanellopoulos ioannis.kanellopoulos@jrc.it Tel: Slide 39 Pilots (1 of 4) Pan-European Assessment of natural Hazards (PEUNHA) Objectives: Risk and damage assessment related to natural hazards on a regional or pan-european level, focusing on two applications areas: Integration, aggregation, classification and visualisation of national forest fire records. Development of tools for impact assessment caused by floods and other natural hazards. Leader: JRC-IES (the Joint Research Centre of the European Commission) Participants: Within the consortium: JRC-IES, INTECS, BRGM External: European experts, personnel from different EU DGs and from the INFOREST and WDNH (Weather Driven Natural Hazards) actions of the JRC Slide 40 20

21 Pilots (3 of 4) Risk assessment for the road network in the French-Italian border region The main objective of the pilot is to demonstrate how ORCHESTRA can be used to effectively support cross border, regional and provincial risk management with a focus on the activities related to the vulnerability and consequence analysis of road infrastructure Leader: BRGM Participants: Within the consortium: BRGM, Ordnance Survey, JRC-IPSC, JRC-IES, ARCS External: Local authorities from Provence, Piedmont Region and Liguria Regions, Italian Transport companies, Italian Ministry of Transport, French Ministry of transport and ESCOTA (operates the toll motorways) Slide 41 Pilots (2 of 4) Floods and Forest Fire Risk prevention assessment in the Tordera Basin (Catalonia, Spain) Objectives Improve the context of decision-making process in the prevention planning of various risks (floods and forest fires) in a basin by focusing on the efficiency of information management and assessment services, thus improving the interoperability among the involved actors and systems Prove the adequacy of ORCHESTRA Architecture as a solution for the mentioned challenges and, in turn, identify which parts need to be corrected or modified towards a fully operational implementation in other similar/larger cases Leader: TYPSA Participants: Within the consortium: TYPSA, ATOS, INTECS External: ACA, ICC, Comissió de Protecció Civil Slide 42 21

22 Pilots (4 of 4) Assessment of Risks generated by Ship Traffic Activity in the German Bight-Wadden Sea Area Objectives: Assess and quantify the multi-environmental risks which are generated by ship traffic activity around the German Bight coastal zone region Provide access to risk management spatial information to the German Bight stakeholders and other users using Orchestra Architecture Leader: BMT Participants: Within the consortium: BMT, AMRIE, DATAMAT, IITB External: Federal Maritime and Hydrographic Agency of Germany (BSH), Trilateral Wadden Sea Secretariat, Schleswig-Holstein (Ministry for Agriculture, Environment and Rural Areas), The Central Command for Maritime Emergencies (Havariekommando) Slide 43 22