Geoportal implementation overview

bookmarkalikeInternet and Web Development

Dec 14, 2013 (3 years and 5 months ago)

67 views


INSPIRE

Infrastructure for Spatial
Information in Europe




INSPIRE geoportal


Discovery and view service clients

architecture and implementation overview



Title

INSPIRE Geoportal: Discovery and View Service Clients
architecture and implementation over
view

Creator

European Commission DG Joint Research centre

Creator date

09/21/2009

Date of last revision

10
/
1
/
2009

Subject

INSPIRE Geoportal Discovery and View Service Clients
architecture and implementation overview

Status

Draf
t

Publisher

European Commission

Description

This document briefly discusses the architecture and
technologies used for the implementation of the discovery and
view clients of the INSPIRE geoportal

Contributor

Hong Cao, Gianluca Luraschi, Angelo Quaglia,
Ioannis
Kanellopoulos

Rights

Restricted to the European Commission, Initial Operating
Capability Task Force, INSPIRE National Contact Points,
INSPIRE Committee

Language

EN

Identifier

INSPIREGeoportal_ImplementationOverview_v301_IK_AQ_
HC.doc




TABLE OF CONTENTS
1. OVERVIEW
................................
................................
................................
................................
................
3

2. INSPIRE
-
GEOPORTAL N
-
TIERS ARCHITECTURE A
ND TOOLS
................................
................
3

3. DISCOVERY
................................
................................
................................
................................
..............
4

3.1. Presentation tier
................................
................................
................................
................................
.........
5

3.2. Application tier
................................
................................
................................
................................
..........
6

3.2.1.
Web layer
................................
................................
................................
................................
................
6

3.2.2.
Business layer
................................
................................
................................
................................
.........
6

3.2.3.
Data access layer
................................
................................
................................
................................
.....
7

3.3. Service tier
................................
................................
................................
................................
.................
7

4. VIEW
................................
................................
................................
................................
...........................
8

4.1. Presentation tier
................................
................................
................................
................................
.........
8

4.2. Application tier
................................
................................
................................
................................
..........
9

4.2.1.
Web layer
................................
................................
................................
................................
................
9

4.2.2.
Data access layer
................................
................................
................................
................................
.....
9

4.3. Service tier
................................
................................
................................
................................
.................
9


FIGURES
Figure 1: INSPIRE geoportal architecture overview
................................
................................
..
3

Figure 2: Discovery N
-
tier architecture
................................
................................
......................
5

Figure 3: Component diagram of the View se
rvice client
................................
..........................
8


1.

O
VERVIEW

The INSPIRE geoportal is an Internet site providing access to the INSPIRE network

services,
which according to the INSPIRE Directive the Member States shall establish

and operate
within the framewor
k of the infrastructure for Spatial Information in Europe

(INSPIRE)
Directive
1
. The scope of this document is to briefly describe the implementation model of the
prototype INSPIRE geoportal for what concerns the discovery and view services clients
(
http://www.inspire
-
geoportal.eu
). It
presents the overall structure of the implementation
model, the decomposition of the software into n
-
tiers and subsystems in the implementation
model, and any architecturally si
gnificant implementation elements. Technology choices and
justification for implementation decisions are also discussed. The implementation of the
discovery and view clients is based on the architectural model of the INSPIRE geoportal as
illustrated in
Figure
1
.


Figure
1
: INSPIRE geoportal architecture overview

2.

I
NSPIRE
-
GEOPORTAL N
-
TIERS ARCHITECTURE A
ND TOOLS

The system is implemented as a JEE (Java Platform Enterprise Edition) multi
-
tier application.
E
ach tier is responsible for specific tasks. When the tasks are completed, the result is handed
over to the next responsible tier. Due to the nature of the tasks appropriate technologies are
chosen for each tier. The whole architecture is made up of 3 main
parts: the Presentation tier,
the Application tier and Service tier. The Presentation tier contains the components that run
on the client machine and handles simple tasks such as input validation, layout and map
presentation. The Application tier contains
components that run on the server and handles
more complex tasks such as processing the search logic and retrieving data from persistent
objects. Service tier contains the servers that provide the Database Service, Web Map Service
(for the map used for dis
covery) and Discovery Services from the Member States.




1

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)


The architecture is implemented using
Apache Struts
(version 1.29)
-
Java Web Application
Framework. The purpose of using Struts is to follow the Model
-
View
-
Co
ntroller ('MVC')
Design Pattern that separates the model (application logic that interacts with a database) from
the view (HTML pages presented to the client) and the controller (instance that passes
information between view and model). Furthermore, Struts
offers the internationalization
feature that can be used to implement multilingual application.

Struts components used in this layer are Struts JSP Tag library (View), Struts Servlet
(Controller) and Struts JavaBeans (Model).

The Web Server on which the
application tier is deployed is
Apache Tomcat 5.5
running on
JDK 1.6.

The Presentation tier of both Discovery and View applications are implemented using the
following technologies:

-

HTML

-

JavaScript (DOM, Ajax)

-

CSS

-

XML, geoRSS

The Presentation tier communicates with the Application tier using asynchronous HTTP
POST requests and receives XML data. It is decoupled from the server side technology with
which the Web tier is implemented since the only requirement is on th
e XML data that is
received.

It makes use of the following open source third party libraries:

-

OpenLayers 2.7
: JavaScript library that is capable of communicating with OGC Web
Map Servers and display geographical m
aps in a web page.

-

Ext JS 2.2.0
: JavaScript library, which specializes in producing an advanced
Graphical User Interface inside a web browser.

-

Mapfish Client 1.
1
: A web 2.0 JavaScript framework that builds upon OpenLayers
and Ext JS. It defines new objects on top of those offered by OpenLayers and Ext JS
that integrate the two like, for example a layer tree, which lists the layers that have
been added to the map
.

Both Discovery and View components have access to an Oracle RDBMS 10g Release 2
database.

3.

D
ISCOVERY

The n
-
tier architecture of the Discovery component and the technologies used to implement it
are illustrated in the figure 2.

.



Figure
2
: Discovery N
-
tier architecture



3.1.

Presentation tier

The Web Client Layer is composed of two parts: (1) The
Discovery
G
raphical
U
ser
I
nterface
(GUI) that

is
built
on top of
the MapFish Client JavaScript
framework
and (
2) a Web Browser
(browsers
tested
: Firefox 3.0.13, Internet Explorer 7.0 and Safari 4.0.3) that renders the pages
received from the server.

The GUI consists of the javascript files, the css property files, the html pages such as the
Search/ Browse page, th
e Search Result page, the Record Detail page. The Search/ Browse

page contains t
he input
S
earch
/ Browse layout, the Map layout and the R
esult layout
. The
Javascript files contains Javascript functions to validate the input fields in the Search/ Browse
page
, to invoke the Mapfish API to render the map and to customize the main layout, to
manipulate the style in the html pages, to send the Ajax requests to the servers, to parse the
response file in
geoR
SS fo
rmat, rendering it in a result table and showing the bounding boxes
on the map, etc. The css files contain the style properties of the html pages.

When the Discovery application is started,
the web client
sends a get map request (
Figure
2
-

0b) to the WMS server
to render
the map
in the M
ap layout region. When a user searches or
browses for Metadata or when the system auto
-
suggest
s
a list of keywords an Ajax
asynchronous request is sent to the server without loading the whole map f
or each request
(
Figure
2

-
1b).
The response received from the server is an html result page attached with a
customize geoRSS file URL that contains the metadata records. We have decided to use
geoRSS format, as it can be easily
rendered in any web map client. However, being entirely
compliant with geoRSS requires each metadata record to have only one associated bounding
box, whereas the ISO profile allows 0 to n bounding boxes for each metadata record. To solve
this incompatibili
ty issue, we have created a customized geoRSS where we attach a parameter
with the bounding box array to the
<link>
element of the geoRSS and use javascript to extract
the parameter value to render them on the map.

3.2.

Application tier

3.2.1.

Web layer

This is the in
termediate layer between the Web Client layer and the Business layer. It
interprets the request received from the client, does some basic business logic processing and
invokes the business layer for more complex business processing.

3.2.2.

Business layer

This lay
er consists of two components: Discovery Proxy and Discovery Core. Both are
implemented as standalone Java applications. The justification for this implementation choice
is to make the system more scalable and maintainable.

The Discovery Core is used by t
he Web Layer and the Discovery Proxy. When the Discovery
Core is invoked by the Web layer it accesses the data from the
Hibernate
session (
Figure
2



5b
) to process the requests and retur
ns the results to the Web layer.

The
Discovery
proxy is the major component of the system when it comes to federated
search.
The proxy provides the means to access distributed community metadata discovery
services for datasets, series and services, perform
the query, collect the response and update
the cache.

A proxy implementation is defined by: the federation strategy implemented and the
catalogue/application profiles that it supports.

Three possible Federation strategies have been evaluated: “real time”,
“full cache” and
“partially cache”.


Real
-
time

distributed access means that a user driven query is routed to one or more
federated catalogue services. The results of these federated queries are added to the result list
and send to the user. The advanta
ge of this approach is that the received metadata sets are up
-
to
-
date. The disadvantage is that the response time of the overall query could be very slow,
because it depends on several performance factors: network connections, federated catalogue
services,
availability of the services, and complexity of the queries.

These disadvantages provide a means to cache the content of a federated catalogue.

In

full cached

federation strategy, the proxy caches not only the elements necessary to make
the metadata dis
coverable, but the whole metadata record. The proxy sends a request to the

catalogue to receive any metadata set that could be requested, and it stores them in its local
storage (together with an indicator of where the metadata set is originated). The init
ial cache
is an asynchronous process that is triggered by the administrator. The advantage of this
approach is that it is very fast, as a query does not depend on the run time behaviours of
different federated catalogues, but only depends on the performanc
e of inspire
-
geoportal
components. The disadvantage is that cached metadata sets may not be up
-
to
-
date, and
updating policy has to be defined.

The “partially cache” is a combination of the two previous strategies. Only the metadata
elements described in th
e “INSPIRE metadata regulation” have been cached, it implies that
the search functionality is based on the cached metadata, but when the user requests the
metadata details a “real time” query is sent to the source catalogue.

From a user point of view all t
he solutions are transparent, because cached entries in the result
list are indicated as being originated from a federated catalogue service same as it is the case
for a real time distributed access.

The inspire
-
geoportal proxy is based on the “partially c
ache” federating strategies and it is
based on the OGC ISO AP as recommended in the INSPIRE Technical Guidance for
discovery services
2

The Proxy is a JEE application that has access to metadata discovery service to the HTTP
POST binding protocol. It update
s the Geoportal Cache using the Hibernate framework. It
manages the metadata by
dom4j
, an open source library for working with XML, XPath and
XSLT and with full support for DOM, SAX and JAXP.

3.2.3.

Data access layer

This lay
er contains
Hibernate
mappings, Hibernate configuration and persistent objects (pojo
package). Hibernate provides an API for performing basic Create, Read, Update and Delete
operations on objects of persistent
cl
asses
. Most queries and transactions are carried out
through the API, which makes the system more m
aintainable
(less code is required). Querying
on objects of persistent
classes
is faster than querying on the database, which enhances the
performance. Chan
ging the database in Hibernate does not require a lot of code modification.

In order to generate the persistent classes, we use Hibernate Reverse Engineering tool. It
generates automatically Hibernate configuration file, the persistent classes (pojo packag
e) and
the mapping files between the persistent classes and the database tables.

When the application is started a Hibernate session is initialized (
Figure
2


1c)
. It loads data
from the database to the persistent class objects
(
Figure
2


2c, 3c, 4c)
, which then become
available in the session to be accessed by other components.


3.3.

Service tier

This tier contains a set of services that run independently of the system, but are accessed by
the system. These
services are:

-

Discovery services:
Operated by the Member States

-

View
Service
for the map used in the search and browse interface
:
The
GUI
renders the map (sources: EuroGlobalM
ap
,
©Eurogeographics
and VMAP0
) used in
the search interface from a Web Map Ser
vice
OGC WMS 1.3
.
0


-

RDBMS Oracle 10g Release 2.




2
Technical Guidance Discovery Services


4.

V
IEW

The View Service Client in addition to the standard functionality provided by the Openlayers
it offers the ability to search for layers offered by the View Services and display them in a
web browser.



Figure
3
: Component diagram of the View service client


The user searches for layers by entering one or more free text keywords. To perform a fast
search, the data contained in the metadata (getCapabilities in the case of OGC WMS
) of the
view Services is processed beforehand and stored in a cache.

Other customisations include the “layer tree” and support for ISO 19128 (OGC WMS 1.3.0)
in addition to OGC WMS 1.1.1.

An overview of the components of the View Service Client is illustr
ated in
Figure
3
.

4.1.

Presentation tier

The presentation tier executes in the user’s web browser and contains the following user
interface components:

“Search for layers”; Allows the user to specify one or more keywords that will be
matched
with the (cached) information derived from the capabilities documents of the view services
known to the view service client.

“Select view service”; Displays the list of view services known to the view service client from
which the user can choose.

“Select view service layers”; Displays the list of layers offered by a single view service from
which the user can choose one or more to display.


“OpenLayers map visualizer”; Displays the layers chosen by the user. It contacts the remote
view services dir
ectly from the user's web browser.


4.2.

Application tier

4.2.1.

Web layer

The web layer performs the following tasks:



retrieves the capabilities document from the view Service and populates the cache
with information related to each layer (e.g. layer title, layer abs
tract, etc. )



sends back a rephrased XML document to the presentation layer.

To avoid contacting the same View Service many times for the same capabilities document, a
small short
-
lived raw cache is maintained. Note that this cache is different to the one
kept for
the search purposes.


The following Java logging libraries are used:
:

-

SLF4J 1.5.8
: It is a façade that makes it possible to abstract from the actual logging
framework
used.

-

Log4j 1.2.14
: It is a widely used logging framework for Java.

4.2.2.

Data access layer

The search functionality needs to cache data read from WMS capabilities in order to
minimize the time required
to run the queries requested by the user.

This tier is implemented using the Java Persistence Architecture API, which is part of the
Enterprise Java Beans 3.0 specifications.

JPA defines interfaces to operate on relational data abstracting from the relati
onal database
actually used.

Since JPA defines only interfaces a concrete implementation is required.

Apache OpenJPA
has been chosen because of the easiness of deployment into a Tomcat Web
Server and also because
it is the default persistence provider of Apache OpenEJB which
might be used at a later stage.

Hibernate or TopLink would have been equally good choices, the former for its overall
performance across different database implementations, the latter because i
t is the native
implementation for the Oracle RDBMS.

However, the beauty of JPA is that it is very easy to switch between different
implementations and between different database implementation.

4.3.

Service tier

This tier contains a set of services that run in
dependently, but are connected to the system.
These services are:

-

View Service:
View

S
ervices
operated by the Member States (currently supports
standard WMS 1.1.1 and ISO 19128 (WMS 1.3)

-

RDBMS
is Oracle 10g Release 2.