Habitats deliverable 4.4.1

European Commission

Information Society and Media

This project is partially funded under the ICT Policy Support Programme as part of the Competitiveness and Innovation Framework Programme by the European Commission http://ec.europa.eu/ict_psp This document reflects only the author's views and the European Community is not liable for any use that might be made of the information contained herein. © HABITATS Consortium, 2010

DELIVERABLE

Project Acronym: HABITATS

Grant Agreement number: CIP- ICT-PSP-2009-3-250455

Project Title: Social Validation of INSPIRE Annex I II Data Structures in EU Habitats

D-4.4.1 HABITATS Service Toolkit

Document identifier: D4-4-1-HABITATS service toolkit

Date: 24.02.2012

Nature: P

Dissemination level: PU

WP Lead Partner: Graz University of Technology

Revision Final

Project co-funded by the European Commission within the ICT Policy Support Programme

Dissemination Level

PU Public X

RE Restricted to a group specified by the consortiu m (including the Commission Services)

CO Confidential, only for members of the consortium (including the Commission Services)

Date: 24/02/2012 HABITATS service toolkit

Doc. Identifier: D4-4-1

Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

02/04/2012 - 2 -

Abstract:

This deliverable presents the background of invoking services and their relevance to the HABITATS projects and examines the basic networking architecture and specific tools that are considered. The focus of this intermediate report is on the application of these aspects within the Reference Laboratory while the final report (D4.4.2) will also include the invoking of services at the level of the different pilots.

Key Words:

Invoke, service toolkit, architecture design, workflow management, Reference Laboratory

Authors: (in alphabetical order)

Raitis Berzins

Peteris Bruns

Jachym Cepicky

Karel Charvat (HSRS)

Patrick Höfler (TUG)

Lisa Maurer (TUG)

Michal Sredl

Martin Vlk

Premysl Vohnout

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.




02/04/2012 - 3 -

Revision History

Revision Date Organization Description

01 28.11.2011 TUG First structure, document focus

02 10.12.2011 HRSR Additions, invoking services, extensions

03 05.01.2012 TUG Additions, comments

04 01.02.2012 HRSR Comments, additions

05 08.02.2012 NSI Comments and suggestions

06 9.2.2012 TUG Editing

07 9.2.2012 MAC Editing suggestions.

08 14.2.2012 HSRS WMS coordinate transformation added, small comments provided, answer on Ana comments

09 20.2.2012 TUG Summary, final editing




02/04/2012 - 4 -

Project Officer: Krister Olson

Address:

European Commission

DG Information Society and Media

Project Officer

DG INFSO – E06

Office: EUFO – 01/177

L – 2920 LUXEMBOURG

Phone: +(352) 43 0134332

Fax: +(352)

E-mail: [email protected]

Project Manager: Mariano Navarro de la Cruz

Address: C/ Julian Camarillo, 6b, 28037, Madrid, Spain

Phone: + 34 91 322 65 21

Fax: + 34 91 322 63 23

E-mail: [email protected]




02/04/2012 - 2 -

TABLE OF CONTENTS

1. INTRODUCTION ......................................................................................................................................... - 3 -

1.1. OBJECTIVE AND CONTEXT OF THIS DOCUMENT ........................................................................................ - 3 - 1.2. ORGANISATION OF THE DOCUMENT .......................................................................................................... - 3 -

2. INVOKING SERVICES ............................................................................................................................... - 4 -

2.1. INVOKING SERVICE REQUIREMENTS AND RECOMMENDATIONS ............................................................. - 5 -

3. HABITATS NETWORKING ARCHITECTURE AND REFERENCE LABORATORY .................... - 7 -

3.1. HABITATS NETWORKING ARCHITECTURE ................................................................................................. - 7 - 3.2. REFERENCE LAB ....................................................................................................................................... - 8 -

4. HABITATS INVOKING SERVICES ....................................................................................................... - 10 -

4.1. INVOKING OF DISCOVERY SERVICES ........................................................................................................ - 10 - 4.2. INVOKING OF VISUALISATION SERVICES ................................................................................................. - 11 -

4.2.1. HSLayers 3.3 .................................................................................................................................. - 11 - 4.2.2. Invoking of WFS and WCS ............................................................................................................. - 17 - 4.2.3. Filter Encoding Filtering WFS Layers ........................................................................................... - 21 -

4.3. WPS INVOKING ...................................................................................................................................... - 26 - 4.4. HSLAYERS SOS CLIENT ......................................................................................................................... - 29 - 4.5. HSLAYERS EMBED COMPONENT ............................................................................................................ - 30 -

5. PROCESSING WORKFLOW MANAGEMENT .................................................................................... - 33 -

5.1. ORCHESTRATION ENVIRONMENT ............................................................................................................ - 33 - 5.1.1. Workflow Management System ....................................................................................................... - 33 - 5.1.2. Business Process Execution Language ........................................................................................... - 33 -

5.2. ENGINES AND WORK-FLOW MANAGERS .................................................................................................. - 33 - 5.2.1. Apache ODE ................................................................................................................................... - 34 - 5.2.2. Orchestra ........................................................................................................................................ - 34 - 5.2.3. Taverna Server ............................................................................................................................... - 35 -

5.3. WORKFLOW DESIGNERS .......................................................................................................................... - 36 - 5.3.1. 52°North WPS Workflow Modeller and Orchestration API ........................................................... - 36 -

5.4. ECLIPSE BPEL ..................................................................................................................................... - 37 - 5.4.1. HUMBOLDT Workflow Design and Construction Service ............................................................ - 38 - 5.4.2. Taverna Workbench........................................................................................................................ - 40 -

6. CONCLUSION ............................................................................................................................................ - 43 -

7. REFERENCES ............................................................................................................................................ - 44 -




02/04/2012 - 3 -

1. INTRODUCTION

1.1. OBJECTIVE AND CONTEXT OF THIS DOCUMENT

The aim of WP4 (Network service architecture) is to define SDI network services to enable trans-European sharing of habitats-related spatial data between public authorities and other stakeholders in the community (HABITATS DoW 2010) and sharing of such data across regions and across countries. This work builds on the data modelling of WP3 and also refers to the user requirements and scenarios developed in WP2 and in cooperation with the pilots of WP5. The prototype versions of the single services are on the other hand again relevant for the developments in the social validation process and will therefore provide valuable feedback.

The development of the network service architecture process of WP4 is initiated through a state of the art analysis of existing SDI, to find out more about already existing infrastructures and to examine how data should be shared and what services are required to enable sharing. When designing the networking architecture, a set of specific networking service applets was deployed and tested for data sharing within the project. Also the potential for re-use of existing application was taken into account.

The Task 4.4 deals with the tools for invoking of Geospatial Services that arise within the HABITATS network architecture, interlinking different data sources and also interlinking data sources from different INSPIRE thematic areas. This is first version of the document, the update and final version will be released in Month 27.

1.2. ORGANISATION OF THE DOCUMENT

The document is divided into five chapters”

• Introduction describing general problem of invoking services and implementation of invoking services in INSPIRE (Chapter 2)

• Basic description of Habitats Networking Architecture and Habitats Reference Laboratory (Chapter 3)

• Principles of basic services that are invoked in reference laboratory (Chapter 4)

• Analysis and Processing of Workflow Management for Spatial Data (Chapter 5)

• Conclusion and tasks for next period of development inside of Habitats (Chapter 6)




02/04/2012 - 4 -

2. INVOKING SERVICES

The definition of spatial data services included in the INSPIRE directive1 is the following: ‘spatial data services’ means the operations which may be performed, by invoking a computer application, on the spatial data contained in spatial data sets or on the related metadata. ISO 19119 define also taxonomy for Geospatial services2:

• Geographic human interaction services

• Geographic model/information management services

• Geographic workflow/task management services

• Geographic processing services

o Geographic processing services – spatial

o Geographic processing services – thematic

o Geographic processing services – temporal

o Geographic processing services – metadata

• Geographic communication services

• Geographic system management services3

From INSPIRE Networking architecture, there are basic Networking services

1. Discovery Service (discovery): Is a service that makes it possible to search for spatial data sets and services on the basis of the content of the corresponding metadata and to display the content of the metadata.

2. View Service (view): Is a service that makes it possible, as a minimum, to display, navigate, zoom in and out, pan or overlay viewable spatial data sets and to display legend information and any relevant content of metadata.

3. Download Service (download): Is a service that enables copies of spatial data sets, or parts of such sets, to be downloaded and, where practicable, accessed directly.

4. Transformation Service (transformation): Is a service that enables spatial data sets to be transformed with a view to achieving interoperability.

5. Invoke Spatial Data Service (invoke): Is a service that allows defining both the data inputs and data outputs expected by the spatial service and a workflow point of view 4

The INSPIRE Spatial Data Service and Invoke Service – Draft, implements rules defining that Invoke service has to be accessible via Internet and offers a mean to invoke the linked spatial data services.

Invoke shall support in order to allow clients invoking spatial data services. Taking into account the potentially wide diversity of interfaces and protocols, invoke services are services that allow access to sufficient service metadata to enable the activation or execution of the spatial data service. The document updated the basic INSPIRE architecture scheme and defined sets of requirements for INSPIRE Invoking services.

1 Commission of the European Communities, Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE). 2007, Commission of the European Communities: Brussels. 2 INSPIRE Invoke Services, Roberto Lucchi, Michel Millot, European Commission, Joint Research Centre, Institute for Environment and Sustainability 3 HABITATS, CIP- ICT-PSP-2009-3-250455, Social Validation of INSPIRE Annex III Data Structures in EU Habitats, D-3.2a – HABITATS - 250455 4 INSPIRE Spatial Data Services and Invoke Service – Draft, implementing rules, Draft_IR_SDS_and_Invoke_1.0.doc




02/04/2012 - 5 -

The requirements are divided into two groups of requirements:

• IR Requirement - Are requirements that are reflected in the Implementing Rule on interoperability of spatial data sets and services are shown using this style.

• SDS Requirement - Requirements that are not reflected in the Implementing Rule on interoperability of spatial data sets and services are shown using this style.

Document INSPIRE Spatial Data Services and Invoke Service define also set of recommendation

2.1. INVOKING SERVICE REQUIREMENTS AND RECOMMENDATI ONS • IR Requirement 1 The implementing rules are restricted to spatial data services that relate to

spatial data sets in themes in Annex I-III, or to their related metadata. • Recommendation 1 There shall be no other requirements applicable to ALL spatial data

services than the establishment of discovery metadata. • Recommendation 2 A spatial data service in this context shall have clearly defined interfaces

for machine-to-machine communication. A Geographic Information System or other systems, understood as a set of tools for collecting, processing and storing spatial data, should not be considered an invokable spatial data service from the perspective of the relevant Implementing Rules. But any specific functionality included in it, and with a well-defined and exposed interface, could be an invokable spatial data service.

• IR Requirement 2 Interoperability arrangements in the INSPIRE context shall be related to invokable spatial data services.

• IR Requirement 3 Requirements for interoperability arrangements are only mandatory for spatial data services operating upon harmonised data (i.e. spatial data sets conformant to the regulation for IDSS).

• IR Requirement 4 A spatial data service conformant to interoperability arrangement shall support coordinate reference systems according to Annex II.1 of the Commission Regulation (EC) No 1089/2010 .

• IR Requirement 5 The default temporal reference system referred to in point 5 of part B of the Annex to Commission Regulation (EC) No 1205/2008 shall be used, unless other temporal reference systems are specified for a specific spatial data theme in Annex I-III.

• IR Requirement 6 A spatial data service conformant to the interoperability arrangement shall be available 99% of time.

• IR Requirement 7 A spatial data service conforming to interoperability arrangement returning spatial objects as part of the output, shall encode those spatial objects according to Article 7 of Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing




02/04/2012 - 6 -

Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services.

• IR Requirement 8 All spatial data services conformant to the interoperability arrangements shall include a Get Service Metadata operation.

• IR Requirement 9 Newly developed spatial data services operating upon harmonised data or their metadata shall be conformant with interoperability arrangements.

• IR Requirement 10 Any harmonised spatial data service shall follow the interoperability arrangements.

• IR Requirement 11 Any harmonised spatial data service shall have minimal performance criteria defined in the same way as network services, i.e. performance, capacity, and availability. The values will depend upon the character of the type of service.

• Recommendation 5 The gazetteer service should be related to harmonised datasets conforming to Addresses, Geographical names and Administrative boundaries. i.e. Location instances should be fetched from these three themes, and correspondingly the Location type should be either an address, a geographical name, or an administrative polygon.

• IR Requirement 12 A registry service shall be compliant with ISO 19135:2005, Geographic information -- Procedures for item registration.




02/04/2012 - 7 -

3. HABITATS NETWORKING ARCHITECTURE AND REFERENCE L ABORATORY

3.1. HABITATS NETWORKING ARCHITECTURE

The HABITATS Networking Architecture has the goal of defining a system able to ensure the interoperability and security of provided data and services. In particular, since integration with the INSPIRE initiatives is needed, it is based on:

• A methodological approach able to define a system architecture that is scalable and adaptable to the specifications and standards currently being defined;

• The adoption of a Service Oriented Architecture based on Web Services and SOAP technology.

The platform neutral networking architecture of HABITATS and the basic set of networking services can be seen as an extension of existing INSPIRE services, for the management, discovery, sharing and processing of spatial planning data by public and commercial sector, NGOs, citizens, private sector, education and science, and all those who play an important role in biodiversity and see region protection and also exploitation. (HABITATS D4.2.1 2010)

As already described in D4.1, the architecture design is realised on the basis of a Reference Model of Open distributed Processing (RM-ODP) (ISO/IEC 10746-1) The use of RM-ODP will give us two opportunities: To define the basic design of the solution as platform neutral and to support different local implementation, and to build on positive experiences of previous European research projects, as this methodology is used by most European (mainly research) projects and some recommendations already exist. The architecture design provides an overall conceptual framework for building geo-processing services for biodiversity, sea region protection and for effective management and utilisation of sensitive areas. (HABITATS D4.2.1 2010)

The HABITATS networking services will be ultimately applied on two levels: The HABITATS Reference Laboratory (see also chapter 3) as a central portal with the support of global data, but also supporting cross scenarios implementations, and the HABITATS pilot applications, as implementations of single HABITATS pilot cases, which will also be used for testing the sharing of local data and metadata. (HABITATS D4.3.1 2011)

The inter-linkage of the Reference Lab and the pilot implementations is visualized in the illustration below (taken from HABITATS D4.2.2 2011).




02/04/2012 - 8 -

The reference laboratory has the following roles:

• To offer a possibility for testing new services

• To offer access to global data for pilots • To support implementation of cross-pilot scenarios

• To make the Habitats services discoverable for external platforms

The pilot implementations will implement only the functionality required by the respective pilot users, the Reference Laboratory will implement the full functionality. (HABITATS D4.2.2 2011)

The RM-ODP divides all processes of architecture design into five generic and complementary steps, which are called viewpoints of the system and its environment. These viewpoints are the:

• Enterprise viewpoint: Focusing on the analysis of pilot scenarios and the definition of a limited number of generic use cases,

• Information viewpoint: Focusing on the basic data and metadata sets that could be shared among the different scenarios

• Computational viewpoint: Focusing on generic components that could be reused for more scenarios

• Engineering viewpoint: Defining a generic scheme that can be reused for all pilot implementations

• Technology viewpoint: Defining basic architecture modifications for single scenarios and suggesting potential technical implementations

3.2. REFERENCE LAB

The reference laboratory, as already mentioned in the previous chapter, is the central hub of the HABITATS Networking Architecture. It consists of several layers, which are (HABITATS D4.2.2 2011):




02/04/2012 - 9 -

• Data layers – management data and files on storage, eventually guarantee access to external sensors • Server (engine layer) – defines tools, which guarantee basic services on the server side – supplying service • Client layer – is client side of Web services, which guarantee access of users to services

• Application layer is some form of wrapping elementary client services into application or into such form, which could be used by other Web tools • Presentation layer contain such web tools, which allow to combine and publish single objects from the application level as part of Web presentation

The illustration below (taken from HABITATS D4.2.2 2011) shows the different layers of the HABITATS Networking Architecture.




02/04/2012 - 10 -

4. HABITATS INVOKING SERVICES

In Habitats we are dealing with the broader understanding of Invoking Services. We will consider this as a possibility to invoke any type of geospatial services according to ISO19119 classification with platform. This means running services without the necessity to have any application on the client side. In this first version of the deliverable we are dealing with invoking service using Reference Laboratory. In the final version (D4.4.2. - due June 2012) we will extend this approach also to the pilot platform.

4.1. INVOKING OF DISCOVERY SERVICES

The reference laboratory uses its own catalogue, but there are also possibilities to invoke another catalogue from a remote platform into the system. There are two possibilities:

• To harvest metadata into the reference laboratory

• To provide direct search of remote catalogues

For both possibilities it is necessary to register the remote catalogue in the metadata system of the reference laboratory. This can be done using the Import functionality of the remote catalogue services.

After registration of these services, this catalogue could be used for harvesting or multi-searching on the side of the Reference Laboratory discovery services.




02/04/2012 - 11 -

4.2. INVOKING OF VISUALISATION SERVICES

Visualisation services WMS (similar to WPS5 or SOS) are invoked through HSlayers on Reference Laboratory

4.2.1. HSLayers 6 3.3

HSLayers combines capabilities of ExtJS (part of Sencha7) and OpenLayers and several helping scripts to establish truly Web GIS applications. The development started in 2007. In 2009, after 2 years of development, it was released under conditions of the GNU General Public License 3.

OpenLayers8 is a JavaScript toolkit for the creation of mapping applications in the web browsers. OpenLayers is in some ways more powerful than Google Maps toolkit:

• It can show maps based on various raster and vector formats.

• It has connectors to many standards and quasi-standards such as MapServer, OGC Web Mapping Service, ArcIMS, simple Image layer, GML, GeoRSS, KML, Text and others and Google, Yahoo and VirtualEarth for commercial data providers.

• The user – creator of mapping applications – does not need to take care about differences between various web browsers and their JavaScript implementation or between various data formats.

ExtJS is a multi-browser JavaScript library for building rich internet applications. It consists of customisable User Interface widgets, ready to be used by designers of Graphical User Interface, similar to desktop widgets, which among others are text field and text area input controls, date fields with a pop-up date-picker, numeric fields, list box, radio and checkbox buttons, wysiwyg html editor, text grids, suitable for spreadsheets, trees, tab panels, toolbars, menus and sliders. ExtJS was originally

5 http://opengeospatial.org/standards/wps 6 http://bnhelp.cz/hslayers 7 http://sencha.com 8 http://openlayers.org/




02/04/2012 - 12 -

built as an add-on library extension of Yahoo UI, but now it is a standalone project. In HSLayers, we are still using ExtJS version 3.x.

HSLayers features are coming up from OpenLayers and therefore their characteristics are as follows: • Portrayal of various types of data:

• Raster: OGC WMS(-T), Image (PNG, JPEG, GIF), … • Vector: OGC WFS(-T), GML, GeoRSS, KML, GPX, GeoJSON, … • Data sources from commercial servers: Google Maps, Virtual Earth, Yahoo Maps, …

• The user interface (use control) adheres to current conventions in web map portals. • Information about queried objects in text bubbles.

HSLayers additional functions include: • Dynamic adding of OGC (Open Geospatial Consortium) services into map - clients for WMS,

WFS, WCS, KML, GeoRSS and others. • Basic WFS filtering • Transformation (warping) of services, with different coordinate reference system. • Portrayal of independent data sources on the client side. Map composition is composed on the

basis of requests to various servers. It is thus not necessary to install a map server. • Saving of map composition according to WMC (Web Map Context) OGC specification on

user computer for repeated future use or for sharing between users. • Extension of compute functions based on WPS (Web Processing Service9) OGC service -

according to user needs – generic WPS Client available. • Multilingual environment • Map requests to various types of data stored on various servers, with automatic processing of

results • Work with micro-formats • Search on the map using various Gazetteers services. • Connection of the application with catalogue client (OGC CSW) in the geoportal, which

enables display of the searched service from catalogue directly on the map. • Vector editing function including snapping to chosen layers on the server. • Possibilities for advanced configuration of user requests • Advanced measuring of length and surfaces • Printing of map compositions - possibility of large print outs (up to A0 format), user

configuration of print settings using HTML templates. PDF output as well as various image formats.

4.2.1.1. LayerSwitcher

LayerSwitcher has now a two panel interface, which makes it easy for the user to manipulate a large list of layers in the map application. The first panel represents the “logical view” on the layer list – layers can be organized into folders and so user can keep logical structure of displayed data. The second panel represents the “physical view” - order of layers, displayed in the map window in the stack. Usually, aerial photos are organized at the bottom of the stack, and cadaster maps are displayed at the top of the stack and their organization into folders does not make much sense.

9 http://en.wikipedia.org/wiki/Web_Processing_Service




02/04/2012 - 13 -

This version of HSLayers also brings the ability to hide used components to side panel of the application (dock) and whenever needed, it can be undocked again into a separate window. Users on smaller screen resolutions can enlarge some tool they need to use and so they are not limited to the size of the side panel.

4.2.1.2. Copyrights

HSlayers also support publishing of information about copyrights related to single services. Information is taken from metadata




02/04/2012 - 14 -

4.2.1.3. Invoking of view (WMS) services

The WMS services can be invoked into the visualisation client in two ways: The first is to discover WMS services from catalogues and visualise WMS services directly from catalogues.

The second possibility is to add the WMS url directly to the visualisation client HSlayers. The URL could be added using OWS services.




02/04/2012 - 15 -

4.2.1.4. WMS coordinate transformation

In the real-life, we are often facing a problem, how to display map from the server, which does not support coordinate system of the displayed map. This is implemented with help of Proxy4OWS (described later in this document). It is assumed, that Capabilities document is already parsed, it is expecting GetMap request from the client to Proxy4OWS directly. The GetMap request is expected to have - next to original WMS parameters - also three add-on options:

� owsService - this is going to be WMS

� owsUrl - URL of the original service, which is expecting to handle the GetMap request

� fromCRS - CRS of the original coordinate system, from which shall the result of GetMap be transformed to.

Proxy4OWS generates MapServer's mapfile on-the-fly. Only one layer is attached to the mapfile - layer of type WMS. MapServer then formulates the necessary request, fetches the data from remote server and provides image transformation on them. Result is always little bit distorted, because the resolution is not always fine enough, but the it can be used and displayed in the mapping application.

WMS Sequence diagram.




02/04/2012 - 16 -

Thanks to Proxy4OWS, we can now display seam-less data from several WMS resources, which do not support coordinate system of the map, displayed in user's browser.

4.2.1.5. Invoking of Map Compositions – Web Map Con text

The important new issue is the support for Web Map Context (WMC). Web Map Context (WMC) describes how to save a map view comprised of many different layers from different Web Map Servers. A 'context' can be encoded and saved so that Web maps created by users can be automatically reconstructed and augmented by the authoring user or by other users in the future. A Context document is structured using eXtensible Markup Language (XML). Potential uses for context include creating default initial views for Web maps for different hazards, saving the state of a user's work on a viewer client to preserve information such as how geospatial layers are added or modified, and saving the state of a client session for sharing with other users. This mechanism is valuable for efficiently communicating across shift transitions. Also, context documents can be catalogued and discovered for reuse by others; this allows analysts to benefit from lessons learned in previous episodes. 10

In URM there is now implemented strong support for discovery and defining new WMC based on information displayed on portal. The system allows to:

• Define WMC on the base current composition on portal

10 � Orchestra http://www.eu-orchestra.org/TUs/Standards/en/html/Unit4_learningObject6.html

WMS transformation result - left map coordinate system, right - transformed result from EPSG:4326 source.




02/04/2012 - 17 -

• Save composition on local disk • Save composition with metadata on server • Open composition from local disk

• Open composition from server • Open composition from remote servers using metadata description

The implementation of the WMC concept presents a new way to the future upcoming solution, when the system will support easier collaboration and sharing of results. It also supports the reuse of results of work done on portal by other applications.

4.2.1.6. Printing

HSLayers includes printing setup, so that content of the map can be printed at any printer or used in other desktop GIS workstation. The printing client enables the user, to choose between printing a map to a pre-defined template or saving the content of the map into a raster image.

When the user makes a choice, that he wants to create a raster image with the map’s current content, he can either directly click the button, and a copy of the map window will be displayed, according to the selected image format (which can be one of PNG, JPEG, GIF and geo-referenced GeoTIFF). The desired scale and region can be set as well.

When a user chooses to print a map to a pre-defined template, a new box is drawn, representing the paper box. Users can move the paper over the map and define the desired region. The size of the paper box is always adjusted according to the selected scale. Additional information can be added as well (map title, description, icon). The map is then layed out according to selected pre-defined template to PDF or HTML output. The template is prepared as a HTML page.

Printing is provided by a server script, which is able to work with standard WMS services, tiled-layer, vector data and other inputs.

4.2.2. Invoking of WFS and WCS

For the invoking of WFS and WCS for visualisation proxy4ows is used. When working with large vector datasets, we are usually facing limits of current browsers. Google Maps 1 for example has




02/04/2012 - 18 -

limited the number of displaying vector features to 1000. In OpenLayers 2, there is no limit for the number of features used, but displaying e.g. cadastral map makes browsers often freeze. An advantage of working with vector data directly is (among others), the direct possibility of editing vector data, a more interactive way of user experience and speed (when dealing with reasonable amounts of data).

While vector data can be displayed using current technologies, some popular raster data formats, such as GeoTIFF, cannot be. According to W3C 3, only few formats for raster data are supported, none of them is really used or usable in GIS, usually because of the compression method they are using. In the internet, raster graphics format focus on possibly low amount of data transferred from the server to the client, while losing the accuracy of the data being transferred. In GIS, we are focusing on data quality, regardless of file size.

Raster and vector data are usually distributed using OGC OWS standards. Vector and raster data are distributed via OGC Web Feature and Raster Service respectively. Both services are offering lists of datasets and metadata.

Another problem might occur, when some OGC Web Mapping Service does not offer a coordinate reference system, in which the web mapping application is configured. Some middle-ware has to be established between the map application and the server, which will transform the images from server coordinate reference system to the one accepted by the client.

Proxy4ows is a server script, which is between the client mapping application and OGC OWS server (WCS, WFS or WMS). It is transforming OGC WMS request types from the client, into WCS or WFS requests, so that the target server can accept them. On the way back, it downloads the data distributed by the server (raster or vector), creates image and sends it back to the client.

It also transforms the GetCapabilities request-response pair, so that the (WMS) client can deal with it.

As result, data is processed on the server, into the form, common web browser mapping application are able to display without big demands on system resources.

HSlayers.Layer.WCS and WFS are derived from Layer WMS. As proxy between the client (the map) and the WFS|WCS server, OWSProxy is placed. OWSProxy transforms WMS requests coming from the client into WFS|WCS calls and also responses are transformed to WMS responses or images, displayable in the web browser.

Proxy4ows can also deal with OGC WMS service in the way, that it transforms the coordinate reference system of the original service into the client-preferred one in the case the server does not support the coordinate system of the client. The resulting image is usually slightly distorted, but displayable.

Proxy4ows is written in the Python programming language. The following libraries are used: MapServer 4:

4http://mapserver.org




02/04/2012 - 19 -

MapServer is the core of Proxy4ows. Proxy4ows generates the Map object configuration and after that dispatch method of MapServer is used, which deals with the request, downloads all necessary data from servers and generates the resulting image.

From the client-point of view, it is used for working directly with vector data (deals as OGC WFS client).

GDAL/OGR 5

GDAL is used for reading OGC WFS and OGC WCS service metadata, so that the WMS response from Proxy4ows to the client, has all of the necessary information.

While for OGC WFS service, MapServer is directly acting as a client, OGC WCS is configured as GDAL data source.

Also for WMS transformation service, WMS interface of GDAL is used, as it is able to deal with tiled requests, preserving the large dataset exceptions issue.

OWSLib 6

OWSLib is Python library, which acts as OWS client. With the help of OWSLib, metadata of particular target services are being collected easily.

Once again: Proxy4ows acts as WMS server to the client and acts as WFS, WCS or even WMS client to the target server.

GetCapabilities

When a GetCapabilities request arrives from the client, Proxy4ows checks for an existing cached directory with mapfile, or creates a new one, if it doesn’t exist.

GetMap

When a GetMap request arrives, an image is generated based on the previously generated mapfile, using OWSDispatch method. At this point, a WFS filter is applied, if the target server is WFS.

In both cases, Proxy4ows is looking for existing MapServer MapFile (it creates one, if it does not exist) and lets MapServer do the work. Proxy4ows takes care of the proper MapFile configuration.

5http://gdal.org 6http://sourceforge.net/apps/trac/owslib/wiki




02/04/2012 - 20 -

When a WMS GetCapabilities request arrives, OWSProxy generates a MapFile with list of layers, corresponding to either feature types (WFS) or coverages (WCS) of the target service. For configuring the MapFile properly, GDAL, OGR and OWSLib libraries are used.

WFS Layers are configured, using MapServer as WFS Client, while WCS layers are using GDAL as WCS Client.

Then MapFile is generated, OWSDispatch method is called and the Capabilities response arrives.




02/04/2012 - 21 -

When the WMS GetMap request arrives, OWSProxy finds the existing MapFile (creates it anew, if it does not exist) and performs OWSDispatch function of MapServer, which generates the output image and sends it back to the server.

4.2.2.1. Invocation

Proxy4ows was originally designed as a WMS server. But it can also be used as WFS or WCS server, so that it can only transform original data into a coordinate system unsupported by the target server. Therefore, the client can use basically any type of OWS request using proper parameters. In addition to this, two more parameters will have to be appended to the request URL:

• owsservice notes the target server service type (WCS, WFS or WMS)

• owsurl is the URL of original server

4.2.2.2. Further development

Currently, when full featured Capabilities response is sent back from the server to the client, for some servers, with high amounts of data, this can take a long time.

For WFS for example, GetCapabilities, DescribeFeatureType and sometimes even GetFeature requests are to be called, before all necessary metadata are filled to MapFile. This certainly makes the Capabilities response come back after a long time. In the future, we would like to eliminate this, so that only the smallest amount of requests (GetCapabilities) would have to be requested, and WMS Capabilities response could possibly be returned faster. Of course, when a user chooses the particular layer to be displayed, additional non-standard calls would have to be done, in order to get addition attributes, so that the client has all of the necessary information (which can be normally taken from the Capabilities document).

Also up to now, virtually no configuration caching is created. For each GetCapabilities request, new temporary MapFile configuration is established. A proper way would be to use already existing MapFile for a particular service if it is already generated, and to evaluate the difference between the cached version and the potentially upgraded service.

Proxy4ows is not caching any data. It is open for further investigation, if it would make sense to pre-cache some original data at the Proxy4ows side, in order to make the performance better.

4.2.3. Filter Encoding Filtering WFS Layers Filter Encoding is an Open Geospatial Consortium standard11 defining the syntax of expressions used to filter data provided by the geospatial web services. It describes a rich predicate language that enables to filter data based on their IDs, type-specific properties, geospatial properties, and to combine filters using logical expressions, call server-defined functions, encode arithmetical expressions and more.

Filter Encoding is defined in XML. Often it is referred to as FE or FES, with S standing for 'Standard' or 'Specification'.

4.2.3.1. FE Examples: 12

Simple comparison filter can look like that:

<Filter>

<PropertyIsLessThan>

11 http://www.opengeospatial.org/standards/filter

12 All the examples in here are using FES 1.1.0, unless specified otherwise




02/04/2012 - 22 -

<PropertyName>DEPTH</PropertyName>

<Literal>20</Literal>

</PropertyIsLessThan>

</Filter>

Example 1.

Spatial filter can, among other things, define a polygon that the desired features should overlap:

<Filter>

<Overlaps>

<PropertyName>Geometry</PropertyName>

<gml:Polygon

srsName="http://www.opengis.net/gml/srs/epsg.xml#63266405">

<gml:outerBoundaryIs>

<gml:LinearRing>

<gml:posList> ... </gml:posList>

</gml:LinearRing>

</gml:outerBoundaryIs>

</gml:Polygon>

</Overlaps>

</Filter>

Example 2.

Logical filter allows to combine filters:

<Filter>

<And>

<PropertyIsLessThan>

...

</PropertyIsLessThan>

<Overlaps>

...

</Overlaps>

</And>

</Filter>

Example 3.

More examples can be found in the Filter Encoding standard.

4.2.3.2. Filter Encoding and WFS

Filter Encoding was originally designed as part of the Web Feature Service standard, but then it was separated into a standalone document as it can serve also for filtering of other services, such as Web Coverage Service, Gazetteer or Web Registries .




02/04/2012 - 23 -

When filtering data is provided by Web Feature Service, several WFS operations are involved:

GetCapabilities

As a part of GetCapabilities response, Filter_Capabilities of the server are announced. This section specifies the filter capabilities of the particular server. It can look as follows:

<ogc:Filter_Capabilities>

<ogc:Spatial_Capabilities>

<ogc:GeometryOperands>

<ogc:GeometryOperand>gml:Point</ogc:GeometryOperand>

<ogc:GeometryOperand>gml:LineString</ogc:GeometryOperand>

<ogc:GeometryOperand>gml:Polygon</ogc:GeometryOperand>

<ogc:GeometryOperand>gml:Envelope</ogc:GeometryOperand>

</ogc:GeometryOperands>

<ogc:SpatialOperators>

<ogc:SpatialOperator name="BBOX"/>

<ogc:SpatialOperator name="Equals"/>

<ogc:SpatialOperator name="Disjoint"/>

<ogc:SpatialOperator name="Intersect"/>

</ogc:SpatialOperators>

</ogc:Spatial_Capabilities>

<ogc:Scalar_Capabilities>

<ogc:LogicalOperators/>

<ogc:ComparisonOperators>

<ogc:ComparisonOperator>LessThan</ogc:ComparisonOperator>

<ogc:ComparisonOperator>GreaterThan</ogc:ComparisonOperator>

<ogc:ComparisonOperator>LessThanEqualTo</ogc:ComparisonOperator>

<ogc:ComparisonOperator>GreaterThanEqualTo</ogc:ComparisonOperator>

<ogc:ComparisonOperator>EqualTo</ogc:ComparisonOperator>

<ogc:ComparisonOperator>NotEqualTo</ogc:ComparisonOperator>

<ogc:ComparisonOperator>Like</ogc:ComparisonOperator>

<ogc:ComparisonOperator>Between</ogc:ComparisonOperator>

</ogc:ComparisonOperators>

<ogc:ArithmeticOperators>

<ogc:SimpleArithmetic/>

<ogc:Functions>

<ogc:FunctionNames>

<ogc:FunctionName nArgs="1">SIN</ogc:FunctionName>

<ogc:FunctionName nArgs="1">COS</ogc:FunctionName>

<ogc:FunctionName nArgs="1">TAN</ogc:FunctionName>

</ogc:FunctionNames>

</ogc:Functions>




02/04/2012 - 24 -

</ogc:ArithmeticOperators>

</ogc:Scalar_Capabilities>

<ogc:Id_Capabilities>

<ogc:EID/>

<ogc:FID/>

</ogc:Id_Capabilities>

</ogc:Filter_Capabilities>

Example 4.

DescribeFeatureType

Properties that can be used to filter features of a specific type are advertised in the response to the DescribeFeatureType request. In the example below, four properties can be used to filter the features of the type location: DEPTH, SURFACE, AREA and CODE.

<complexType name="locationType">

<complexContent>

<extension base="gml:AbstractFeatureType">

<sequence>

<element name="msGeometry" type="gml:SurfacePropertyType" minOccurs="0" maxOccurs="1"/>

<element name="DEPTH" type="Integer"/>

<element name="SURFACE" type="Character"/>

<element name="AREA" type="Real"/>

<element name="CODE" type="Character"/>

</sequence>

</extension>

</complexContent>

</complexType>

Example 5.

GetFeature

When the filter capabilities of the server are known as well as the properties of the particular feature type, the filter can be created following the FE standard. Consider the filter from Example 1, this time extended with the namespaces. It selects all the features whose DEPTH property is less than 20. To the GetFeature request the FILTER parameter is added and the filter is provided as the value:

http://localhost/cgi-bin/ows?REQUEST=GetFeature&VERSION=1.1.0&SERVICE=WFS&TYPENAME=location&FILTER=<ogc:Filter xmlns:ogc="http://www.opengis.net/ogc"><ogc:PropertyIsLessThan><ogc:PropertyName>DEPTH</ogc:PropertyName><ogc:Literal>20</ogc:Literal></ogc:PropertyIsLessThan></ogc:Filter>

Example 6.




02/04/2012 - 25 -

In the Habitats Geoportal, Filter Encoding is used to filter WFS layers. To do it, first add a WFS layer to your map. Then right-click on the layer name in the Layer Switcher and select Filter:

The filter window appears with a form for simple comparison filter. From the first drop-down list select a property that will be used for filtering (these have been parsed out from the DescribeFeatureType response). From the second drop-down list select the operator that will be used. (The list of available operators has been parsed out from the GetCapabilities response.) In the text field the value to compare it with is entered. Click 'Apply' and the layer will be filtered.




02/04/2012 - 26 -

4.2.3.3. Implementation

Implemenation of the Filter Encoding is shown on the following illustration:

The processing works as follows:

WFS layers are displayed as WMS in the HSLayers Web Client (see Proxy4ows for details).

1. WFS GetCapabilities request is sent directly to the WFS server. Capabilities document is parsed and filter capabilities are saved.

2. WFS DescribeFeatureTypes request is sent directly to the WFS server. Reply is parsed and properties of the feature type are saved.

3. User creates the filter in the GUI, saved information from steps 1-2. is used.

4. User-created filter is written to FES and new WMS request is sent to Proxy4ows, accompanied with the filter in an additional parameter.

5. Proxy4ows takes the filter, creates new WFS request involving the filter, and sends it to the WFS server. Server replies with filtered layer.

6. Proxy4ows transforms the returned WFS layer to WMS and sends it to the client.

4.2.3.4. Next Steps

In terms of standards, FES 1.0.0 and FES 1.1.0 is supported. From various types of filters, only the comparison filter is currently supported by the GUI. As next steps, more filter types can be added. That covers logical filter enabling to combine various filters, spatial filter, expression editor, filtering based on feature IDs, support for server-side functions and filtering based on time.

4.3. WPS INVOKING

In HSLayers, a new class WPSClient was introduced. The class implements generic OGC WPS client with graphical user interface. HSLayers WPSClient performes GetCapabilities request on the server and creates a list of available processes. Processes are rendered into a drop-down menu. When a user chooses the process he wants to run, DescribeProcess is called. Based on ProcessDescription response,




02/04/2012 - 27 -

a generic input form is generated. After all input data is specified, and when users click the button, an Execute request is called, and when it is finished, an execute response is parsed and outputs of the form are filled.

Complex input and BoundingBox input are relatively easy to be implemented. Writing the complex data handler in the web environment is a real challenge. Generic HSLayers WPS Client. Form is generated automatically.

4.3.1.1. HSLayers WPSCLient ComplexData handler

First, input is identified as raster or vector. Then, the map layers are scanned and HSLayers.Layer.WCS (for rasters) HSLayers.Layer.WFS and OpenLayers. Layer.Vector (for vectors) are identified and added to the drop-down select box. The Custom URL option is attached, for custom raster or data link pasting (e.g. for direct WFS or WCS request) and, if the input data shall be vectors, also Custom drawings option is added, so that the user can define some geometry on the map by hand.

When an Execute request is called, HSLayers collects URLs for HSLayers.Layer.WFS or HSLayers.Layer.WCS with GetFeature or GetCoverage request types – the client is not sending the data, but only reference to the data (which is possible according to OGC WPS).

HSLayers.Layer.WFS and HSLayers.Layer.WCS are special types of layers, used in HSLayers. They are based on OpenLayers.Layer.WMS class, but they are not working with WCS or WFS server directly, but communicating via server-side proxy called Proxy4ows 13[6] (more on other place). Proxy4ows is sitting between the client (generic web browser) and the server (WCS or WFS) and is transforming the requests and responses into a form that can be handled in the web environment. GeoTIFFs are transformed into PNG and JPEGs, GML's are transformed into picture (PNG) form. Using this approach, there is virtually no limit to the amount of features, which can be displayed in the client or any image format issues.

13 http://redmine.ccss.cz/project/owsproxy




02/04/2012 - 28 -

HSlayers.Layer.WCS and WFS are derived from Layer WMS. As a proxy between the client (the map) and the WFS|WCS server, Proxy4ows is placed. Proxy4ows transforms the WMS requests coming from the client into WFS|WCS calls and also the responses are transformed to WMS responses or images, displayable in the web browser.

Features in vector layers (which are handling vector data, not raster representation) are transformed into the format, desired by the user, according to the server-supported MimeType (this is very vague estimation, see above). Usually this is GML and the data are then sent to the server as part of the XML-encoded request.

When a response arrives, HSLayers WPSClient does prefer reference to output data, so it can be handled more easily (as Reference=True). When vector data are send back (usually in GML format), they are added to the map as features of OpenLayers.Layer.Vector. The GML is parsed using OpenLayers tools. Direct link for downloading is also provided. Raster data (usually GeoTIFFs) are only available for downloading.

Client does not send a direct link to the original WFS or WCS server, but the link to Proxy4ows. One of key features of Proxy4ows is, that it ensures the data it is providing will be in the same projection as the web mapping application.

Further development is moving towards a closer usage of already described Proxy4ows. Raster and Vector data will be stored on the HSLayers-server and client will consume their in web browser usable rasterized form (PNG image).

GetCapabilities and DescribeProcess are parsed directly with OpenLayers tools. For the Execute request with complex data, a reference to Proxy4ows is used. The WPS Server gets reference to Proxy4ows and not to the original server, because Proxy4ows makes sure, resulting data will have the same coordinate reference system as the map application has.

As a result, HSLayers does contain a generic OGC WPS 1.0.0 version client. The client is capable to parse capabilities, to generate automatically from based on ProcessDescription response and is able to submit Execute requests and to parse the response.




02/04/2012 - 29 -

It works with raster and vector data displayed in the mapping application. It is also possible to submit external dataset (using URL). The result can either be added to the map or can be downloaded and storeed on the local hard drive.

The displaying of output vector or raster complex data is only limited. If e.g. GeoTIFF is returned back as a result, it can be only downloaded. Proxy4ows will be modified, so it does accept GeoTIFF file and produces PNG out of it.

The development of the input form, based on ProcessDescription document, needs to be more robust. Also the literal value type of data needs to be controlled according to input type (integer, string, date, ...).

Even some patches based on this are already accepted in OpenLayers, a more robust WPSExecute patch will be prepared and submitted into OpenLayers code base.

4.4. HSLAYERS SOS CLIENT

The SOS client in HSLayers is a component which can be used for browsing data from any OpenGIS Sensor Observation Service (OGC SOS) compliant services. The component can be used together with map application based on HSLayers, or independently with any non map application.

Th actual version of component supports only operations from OGC SOS Core Profile which must be implemented in every OGC SOS compliant services.

Operations supported in the actual version are:

• GetCapabilities - returns a service description containing information about the service interface and the available sensor data

• DescribeSensor - returns a description of one specific sensor, sensor system or data producing procedure

• GetObservation - provides pull-based access to sensor observations and measurement-data via a spatio-temporal query that can be filtered by phenomena and value constraints

Future versions of components will contain also operations from OGC SOS Enhanced Profile and will offer more functionality for working with data from OGC SOS services.

4.4.1.1. How does it work

• User invokes HSLayers SOS Client UI dialog

• User inputs URL of required OGC SOS

• HSLayers SOS Client sends GetCapabilities request to OGC SOS, parses its response and displays available information about OGC Service (name, abstract) in UI

• User selects offering and all parameters for required observations (procedure, observed property, date-time interval)

• User invokes getting observations

• HSLayers SOS Client sends GetObservation request with all passed parameters to OGC SOS, parses its response and display all obtained data in table and chart

• If HSLayers SOS Client is used within map application based on HSLayers, user can displays location of obtained observations in map




02/04/2012 - 30 -

4.5. HSLAYERS EMBED COMPONENT

HSLayers contains the component Embed for inserting map into any HTML pages. User can create a map in a Geoportal or in any map application which is based on HSLayers and contains the Embed component. Users can also define parameters which affect how the map will be look in the target HTML page.

There are three types of a resulting inserted map window: • Pure HTML – this type is based on pure HTML and does not contain any other UI

components • Simple ExtJS – this type uses ExtJS library for generating UI container • Advanced ExtJS – this type uses ExtJS library also as Simple ExtJS type and also contains

another UI components (tree with list of all layers in map)




02/04/2012 - 31 -

The HSLayers Embed component consists of several parts on the client and on the server side.

• Embed Generator – this part is responsible for displaing the UI form to enter the parameters affecting the resulting inserted map window. When the user enters all required parameters, the actual map is serialized and sent to the Status Manager on the server. The Status Manager is an external service which is responsible for saving actual state of any component and getting it back later.

• Embed Client – this part is responsible for rendering map windows in target HTML page in dependence on parameters entered by user.

• Embed Script – this part is responsible for rendering main HTML part of map window and for calling Embed Client in target HTML page.

4.5.1.1. How does it work

Generating HTML code 1. User invokes UI to enter the parameters of inserted map window. 2. User inputs parameters affecting map window (type of map window, size of window). 3. Embed Generator serialize actual map and send it to Status Manager. 4. Status Manager returns URL for later accessing state of actual map (when it will be rendered

in target HTML page). 5. Embed Generator returns complete HTML code. User can paste this HTML code to any

HTML page.




02/04/2012 - 32 -

4.5.1.2. Rendering map window in target HTML page 1. Target HTML page renders initial JavaScript code which creates new IFRAME element. URL

of this IFRAME element is set to Embed Script and contains all parameters. 2. When IFRAME is activated, the Embed Script is called. The Embed script generates the main

part of HTML code for IFRAME. This HTML code contains references for all required JavaScript files and Cascade Style Sheets (CSS) files. These files are different in dependence on type of map window.

3. HTML code in IFRAME calls the Embed Client for creating the map window. 4. Then it reads the state of the map from the Status Manager and restores the complete map

from this state.




02/04/2012 - 33 -

5. PROCESSING WORKFLOW MANAGEMENT

The objective of this chapter is to provide information about available orchestration and workflow management tools. It also explains the tool functionalities and possibilities to integrate and use with Habitats services for complex chained service orchestration and deployment.

5.1. ORCHESTRATION ENVIRONMENT

We assume that we will use Open Geospatial Consortium (OGC) compliant Web Processing Service 1.0.0. standard services provided by GeoServer WPS extension, 52north WPS solution and byWPS as input sources in orchestration and work flow management.

Another assumption is that in the future different service chaining will be able to be developed also by non technical and IT highly skilled personnel.

5.1.1. Workflow Management System

Workflow Management System (WMS) is a piece of software that provides an infrastructure to setup, execute, and monitor scientific workflows. In other words, the WMS provide an environment where in experiments can be defined and executed.

An important function of a WMS during the workflow execution or enactment is the coordination of operation of individual components that constitute the workflow – the process also often referred to as orchestration.

As research becomes more data-intensive and more reliant on the use of computers, larger volumes of experimentation data are recorded quicker and with greater precision. This trend has spurred a significant increase in the complexity of scientific simulation software. Many tools only perform a small well-defined task, thus necessitating that several of them are joined in a pipeline to model a useful experiment.

Additional difficulties arise from the need to deal with the incompatible data formats that various services produce or consume. It is evident that considerable amount of computer science knowledge is required to overcome the outlined problems. However, domain scientists across disciplines do not have sufficient relevant expertise.

Scientific workflows and WMSs have emerged to solve this problem and provide an easy-to-use way of specifying the tasks that have to be performed during a specific in silico experiment. The need to combine several tools into a single research analysis still holds, but technical details of workflow execution are now delegated to Workflow Management Systems.

5.1.2. Business Process Execution Language

Business Process Execution Language (BPEL), short for Web Services Business Process Execution Language (WS-BPEL) is an OASIS standard XML based executable language for specifying actions within business processes with web services. Processes in Business Process Execution Language export and import information by using exclusively web service interfaces. It defines a set of basic control structures like conditions or loops as well as elements to invoke web services and receive messages from services. BPEL's messaging facilities depend on the use of the Web Services Description Language (WSDL) 1.1 to describe outgoing and incoming messages. Message structures can be manipulated, assigning parts or the whole of them to variables that can in turn be used to send other messages.

5.2. ENGINES AND WORK-FLOW MANAGERS

To make tests we collected several workflow execution engines and managers. From the collected engines the biggest part is using BPEL and only one of the solutions is oriented on data flow execution.




02/04/2012 - 34 -

5.2.1. Apache ODE � Name: Apache ODE + Eclipse Plugin � Version: 1.3.5 � Platform: Java � Standards: WS-BPEL 2.0 � Vendor: Apache Software Foundation, OASIS � Licence Apache ODE: Apache Software License (ASL), version 2.0. � Licence Eclipse BPEL: Incubation phase, version 0.5 � Homepage: http://ode.apache.org/

Apache ODE (Orchestration Director Engine) executes business processes written following the WS-BPEL standard. It talks to web services, sending and receiving messages, handling data manipulation and error recovery as described by your process definition. It supports both long and short living process executions to orchestrate all the services that are part of your application. ODE comes with easy to use web-based management interface (Figure 1).

Ode can be deployed in three different environments: � As a simple Web Service in Axis 2, ODE is bundled in a WAR than can be deployed in any

application server and is invoked using plain SOAP/HTTP. � As a JBI service assembly, ODE is bundled in a ZIP that can be deployed in any JBI container

and is invoked using the NMR. � SMX4 OSGi bundle

5.2.2. Orchestra � Name: Orchestra � Version: 4.7.1 � Platform: Java � Standards: WS-BPEL 2.0 � Vendor: OW2 - Object Web � Licence: LGPL 2.1 � Homepage: http://orchestra.ow2.org/

Orchestra is a complete solution to handle long-running, service oriented processes. It provides out of the box orchestration functionalities to handle complex business processes. It is based on the OASIS standard BPEL.




02/04/2012 - 35 -

In Orchestra server is bundled with web based workflow management Console (Figure 2).

5.2.3. Taverna Server � Name: Taverna Server � Version: 2.2a1 � Platform: Java � Standards: - � Vendor: myGrid, OMII-UK � Licence: LGPL � Homepage: http://www.taverna.org.uk/

Taverna Server enables you to set up a dedicated server for executing workflows remotely. Server is using workflows designed by Taverna Workbench. The Server exposes REST and SOAP APIs; either can be used to access the functionality of the Server.

As demonstration manager the Taverna Demonstrator interface is used written in Ruby language. The demonstrator is simple GUI to manage workflow execution and can be used as inspiration for custom and more complicated workflow management solution development. (Figure 3) Taverna Demonstrator can not be used in a production environment.




02/04/2012 - 36 -

5.3. WORKFLOW DESIGNERS

An integral part of orchestration engines and workflow managers are designers to prepare executable workflow documents.

5.3.1. 52°North WPS Workflow Modeller and Orchestra tion API � Name: 52°North WPS Workflow Modeller � Version: WPS 2.0-RC6, Revision 1647 � Platform: independent, language Java � Vendor: 52north � Licence:GPL � Homepage: http://52north.org/

The open source software initiative 52°North is an international network of partners from research, industry and public administration. Its mission is to foster the development of new concepts and technologies in Geo-informatics through a common innovation process.

All software developed within this collaborative development process is published under an open source license.

The 52°North partners have a long and outstanding record in the Geo-IT domain. They are actively contributing to the development of international standards, e.g. at W3C, ISO, OGC or INSPIRE.

The Geoprocessing community aims at designing a pluggable web service architecture for orchestrating and executing geo-processes, as well as researching innovative spatio-temporal data analysis processing techniques.




02/04/2012 - 37 -

The WPS Workflow Modeller allows the visual modeling of geoprocessing workflows. In a lightweight Browser environment, WPS services can be easily chained and equipped with literal or complex data inputs from i.e. other OGC services such as WFS.

This graphical WPS Workflow Modeller is based on the WPS Orchestration API which allows the programmatically chaining of WPS in a very straight forward manner.

The work was has been conducted in cooperation with Sejong University through funding from the Seoul R&BD program(10540)

The Workflow Modeller uses a standard Openlayers implementation to visualize input and result layers (Figure 4). Along with this standard implementation comes the default controls for panning and zooming as well as a layer switcher to turn on/off overlay layer and to select base layers (see section 1.1). In the following the specific functions of the Workflow Modeller to interact with the map are described.

5.4. ECLIPSE BPEL � Name: Eclipse BPEL � Version: WS-BPEL 2.0 � Platform: independent, language Java � Vendor: The Eclipse Foundation � Licence: Eclipse Public License (EPL) � Homepage: http://www.eclipse.org/bpel/

BPEL Project adds comprehensive support to Eclipse for the definition, authoring, editing, deploying, testing and debugging of WS-BPEL 2.0 processes. WS-BPEL (Web Services Business Process Execution Language), or BPEL, is a vendor-neutral specification being developed by OASIS to specify business processes as a set of interactions between web services.

The goal of the BPEL Project is to add comprehensive support to Eclipse for the definition, authoring, editing, deploying, testing and debugging of WS-BPEL 2.0 processes. WS-BPEL (Web Services Business Process Execution Language), or BPEL, is a vendor-neutral specification being developed by OASIS to specify business processes as a set of interactions between web services. By providing these tools, this project aims to build a community around support for BPEL in Eclipse.




02/04/2012 - 38 -

The implementation will be extensible to third-party vendors in a number of ways. The editor will be extensible to support new activity types, property pages for extensibility of existing constructs, an extensible palette, and product-specific branding capabilities. The runtime deployment framework will be extensible so that third parties may add support for a variety of runtime engines. The model will support extensions to provide new activities or attributes, and the validator will allow for validation of these extensions.

The Key Features are: � Designer. A GEF-based editor that provides a graphical means to author BPEL processes

(Figure 5). � Model. An Eclipse Modeling Framework (EMF) model that represents the WS-BPEL 2.0

specification. � Validation. A validator which operates on the EMF model and produces errors and warnings

based on the specification. � Runtime Framework. An extensible framework which will allow for deployment and

execution of BPEL processes from the tools into a BPEL engine.

5.4.1. HUMBOLDT Workflow Design and Construction Se rvice � Name: HUMBOLDT Workflow Design and Construction Service � Version: svn � Platform: independent, language Java � Short description � Vendor: NATURE-SDI project � Licence: � Homepage: http://community.esdi-humboldt.eu/wiki/5

The HUMBOLDT Workflow Design and Construction Service consists of two sub-systems, a graphical user interface, called the Workflow Editor, allowing users to compose geo-processing components into workflows. Second, a web service, called the Workflow Repository Service, that accepts requests for workflows and delivers them to clients (in HUMBOLDT, the Mediator Service).




02/04/2012 - 39 -

Basic Functionality of the WDCS: � Allow users to visually compose the workflow graph out of geo-processing components (out

of WPS / java processes / WSDL?) and data sources � Manual Workflow Definition, Automated Execution � Allow users to register processes to the system � Exports such workflows in different workflow dialects via a WSDL / SOAP interface

(priority: the dialect used by the HUMBOLDT Mediator Service) � Help the user in the composition process, by: � type checking inputs and outputs when connecting � type checking user entered input values � Some small graphical features that make the composition process easier

The Graphical User Interface of the WDCS, called the Workflow Editor, can be used by users to register processing components and to specify chains / compositions of such components (i.e. workflows). The GUI offers therefore quite a similar functionality as e.g. the GUI of the ArcGIS Model Builder or a BPEL Workflow Designer but additionally provides assistance to the user in the composition process by e.g. comparing the input/output type definitions of the components to be connected. For example, this prevents users from connecting components processing raster data with processing component accepting vector data and hence reduces the risk of runtime errors when executing the composition. Currently, the processes to be composed can either be exposed as OGC WPS Processes or directly implemented in java and accessible to the HUMBOLDT Mediator Service.

The Workflow Editor acts as a client application to the Workflow Repository and allows users to deploy the workflows such that they will be subsequently offered via the web service interface of the Workflow Service.

The geo-processing workflows to be built with the Workflow Editor follow the structure of dataflow graphs, a well-know concept in software engineering. A dataflow graph is a graph G = (V,E) with V=GD being a set of nodes and E= (D×GG) a set of directed edges. G is the set of processing nodes associated with computational components, in the case of the workflow editor, geo-processing components. D is the set of data-providing nodes associated with data providing components. A directed edge E connects a node associated with a data providing or computational component to another computational component. In case a computational component has multiple inputs (often called input ports), there can be multiple edges pointing to it, each one associated with a different input. In case a processing node has multiple outputs or the output shall be pushed as input to multiple input ports of a single or multiple other processing nodes, several edges from such a processing node might exist.

The computational components represented by the nodes G in a dataflow graph are required to be function-like in the sense that they generate the same output given the same input and do not depend on some changing states (such as a global variable that is not a direct parameter). Further, the direct edges represent the dataflow between nodes. A node in a dataflow graph can be “executed”, if the data of all other input nodes that provide the input via a dataflow edge is available. Due to the function-like nature of the processing nodes, the outcome of a whole dataflow graph of such components is determined solely by the input passed to it and can therefore be treated similar as a simple or atomic node and composed.




02/04/2012 - 40 -

This project collects the HUMBOLDT Service Integration Framework sub-projects, specifically:

� the Mediator Service (MS), a harmonization work-flow execution engine, � the Workflow Construction and Design Service (WDCS), an harmonisation needs analysis and

workflow construction component, � the Model Repository (MR), a conceptual schema and mappings repository, � the Context Service (CS), a service for managing product descriptions for transformation

results and � the Information Grounding Service (IGS), a bridge component to existing catalogue services.

5.4.2. Taverna Workbench � Name: Taverna Workbench � Version: 2.2 � Platform: independent, language Java � Vendor: myGrid, OMII-UK � Licence: LGPL � Homepage: http://www.taverna.org.uk/

Taverna is an open source and domain independent Workflow Management System – a suite of tools used to design and execute scientific workflows and aid in silico experimentation.

Taverna has been created by the myGrid team and funded through the OMII-UK. The project has guaranteed funding until 2014.

The Taverna suite is written in Java and includes the Taverna Engine (used for enacting workflows) that powers both the Taverna Workbench (the desktop client application, Figure 7) and the Taverna Server (which allows remote execution of workflows). Taverna is also available as a Command Line Tool for a quick execution of workflows from a terminal.

Taverna allows you to define how your data flows between the services, without having to worry how you are going to invoke these services. It will automate and pipeline processing of data.




02/04/2012 - 41 -

Suite of tools to design, edit and execute workflows

� Workflow design and execution in Taverna Workbench � Command line execution of workflows � Remote execution of workflows on a Taverna server � Invoke workflows from the Internet

Wide range of services and extensible architecture � Service discovery � Various service types available: WSDL-style and RESTful Web services, BioMart, BioMoby,

SoapLab, R, Beanshell, Excel and csv spreadsheets, pyWPS � Service creation for external tools or Java libraries � Extensible service plug-in architecture for adding new service types

Secure � Support for secure services � Secure management of users’ credentials

Versatile Workbench � Tabs for finding, designing and executing workflows � Fully graphical workflow design � Drag and drop workflow components � Comprehensive undo/redo � Built-in help facility � Annotations for describing workflows, services, inputs, outputs � Workflow validation and debugging

Create your own or start from existing workflows � Easy design of new workflows � Load existing workflows (from a disk, myExperiment or a URL) � View workflow layout and logic � Modify existing workflows




02/04/2012 - 42 -

� Load workflows in off-line mode (when disconnected from the Internet) � Nested workflows (sub workflows) � Workflow validation during design time for debugging while composing a workflow � Built-in detection when a service’s interface changes or a service go off-line during design

time Find workflows created by others and share yours

� Full myExperiment search options for browsing workflows � Publish workflows on myExperiment for use by others

Execute and debug your workflows � Execute workflows � Remember previously used workflow inputs � Save workflow input values used to a file � Load workflow input values from a file � Pipelining and streaming of data � Implicit iteration of service calls � Conditional and repeated calling of services � Customizable looping over a service � Failover and retry of service calling � Parallel execution and configurable number of concurrent threads � Improved error handling and reporting for debugging during run time � Monitor workflow execution � Pause/resume or cancel workflow execution � Manage previous runs and workflow results � View intermediate results and debug workflows at run time � Filter and save intermediate and final workflow results

Track workflow runs and results � Record workflow execution provenance � Review provenance of previous workflow runs




02/04/2012 - 43 -

6. CONCLUSION

This report gives a brief overview of the tools for invoking Geospatial Services that arise within the HABITATS network architecture. Invoking services are described and a few examples of invoking services in the Reference Laboratory are demonstrated, and possibilities of Workflow management are analysed.

Basically the architecture design is realised on the basis of a Reference Model of Open distributed Processing (RM-ODP), while the HABITATS networking services will be ultimately applied on the two levels of the Reference Laboratory as a central portal and on the level of the pilot cases for local data testing and sharing. This first version of the deliverable examines the invoking services used in the Reference Laboratory. As invoking strongly depends on the used platform, this first report mainly reflects the developments in the reference Laboratory in order to support developers to implement or invoke their services.

In the next phase (which will be reported in D4.4.2) the focus will be on invoking the services at the level of the pilots and on the implementation of workflow management systems for the purpose of HABITATS.




02/04/2012 - 44 -

7. REFERENCES

Güting 2005: Ralf Hartmut Güting, Markus Schneider. Moving Objects Databases.2005, ISBN 978-0120887996. HABITATS DoW 2010: Description of Work, “Social Validation of INSPIRE Annex II Data Structures in EU Habitats” HABITATS D4.2.1 2010: D4.2.1- INSPIRE Networking Architecture Design, 2010 HABITATS D4.2.2 2011: D4.2.2 – INSPIRE Networking Architecture Design, 2011 HABITATS D4.3.1 2011: D4.3.1 – HABITATS networking services ISO/IEC 10746-1 Information technology – Open Distributed Processing – Reference model: Overview, ISO (1998) TAVERNA 2011: Taverna, What is a Workflow Management System? Taverna home page 2011. (http://www.taverna.org.uk/introduction/what-is-a-workflow-management-system/ ).