Project No. 249024 NETMAR Open service network for marine environmental data

walkingceilInternet και Εφαρμογές Web

22 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

135 εμφανίσεις






Project No. 249024


NETMAR


Open service network for marine environmental data




Instrument:

Please tick

CA


STREP

IP

NOE



ICT
-

Information and Communication Technologies Theme




D2.2.1
NETMAR

s
ystem
a
rchitecture
d
esign



First version

Refere
nce:
D2.2.1_Sy
stem_Architecture_Revised



Due date of deliverable (as in Annex 1): M0 + 9

Actual submission date:

11 November 2010



Start date of project:

1 February 2010





Duration: 3 years




Coastal and Marine Resources Centre (CMRC), University Coll
ege Cork, National University of Ireland



Revision
1





Project co
-
funded by the European Commission within the
Seventh Framework Programme (2007
-
2013)

Dissemination Level

PU

Public


PP

Restricted to other programme participants
(including the Commiss
ion Services)


RE

Restricted to a group specified by the consortium
(including the Commission Services)

X

CO

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






NETMAR

Open service network for marine environme
ntal data

Project Reference: 249024

Contract Type: Collaborative Project

Start/End Date: 01/03/2010
-

31/01/2013

Duration: 36 months


Coordinator: Prof. Stein Sandven

Nansen Environmental and Remote Sensing Center

Thormøhlensgate 47, Bergen, Norway

Tel.:

+47 55 20 58 00

Fax. +47 55 20 58 01

E
-
mail:
stein.sandven@nersc.no



Acknowledgements

The work described in this report has been partially funded by the European Commission under the
Seventh Framework Progr
amme, Theme ICT 2009.6.4 ICT for environmental services and climate
change adaptation.


Consortium

The
NETMAR

Consortium is comprised of:



Nansen Environmental and Remote Sensing Center (NERSC), Norway (coordinator).

Project Coordinator: Prof. Stein Sandve
n (
stein.sandven@nersc.no
)

Deputy Coordinator: Dr. Torill Hamre (
t
orill.hamre@nersc.no
)

Quality Control Manager: Mr. Lasse H. Pettersson (
lasse.pettersson@nersc.no
)



British Oceanographic Data Centre (BODC), National Environment Research Council, United
Kingdom

Contact: Dr. Roy Lowry (
rkl@bodc.ac.uk
)



Centre de documentation de
recherche et d'expérimentations sur les pollutions accidentelles
des eaux (Cedre), France.

Contact: Mr. François Parthiot (
Francois.
Parthiot
@cedre.fr
)



Coastal and Marine Resources Centre (CMRC), Universit
y College Cork, National University of
Ireland, Cork, Ireland.

Contact: Mr. Declan Dunne (
d.dunne@ucc.ie
)



Plymouth Marine Laboratory (PML), United Kingdom.

Contact: Mr. Steve Groom (
sbg@pml.ac.uk
)



Institut français de recherche pour l'exploitation de la mer (Ifremer), France.

Contact: Mr. Mickael Treguer (
mickael.treguer@ifremer.fr
)



Norwegian Meteorological Institute (METNO), N
orway.

Contact: Mr
.

Jan Ivar Pladsen (
janip@met.no
)


Author(s)



Anthony Patterson, CMRC,
a.patterson@ucc.ie




Torill Hamre
, NERSC,
t
orill.hamre@nersc.no



Declan Dunne, CMRC,
d.dunne@ucc.ie




Peter Walker, PML,
petwa@pml.ac.uk



Document approval



Document status:
Revision 1



WP leader

approval:
2010
-
11
-
10



Qual
ity Manager approval:
2010
-
11
-
11



Coordinator approval:
2010
-
11
-
11

NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

i









© 2010 NETMAR Consortium


EC FP7 Project No. 249024


Revision History


Issue

Date

Change records

Author(s)

Draft 1

2010
-
09
-
03

Topic outline

A.

Patterson

Draft 2

2010
-
10
-
01

Issued for review at Cork meeting

A.

Patterson

Draft 3

2010
-
10
-
18

GENESIS
and
GIGAS
descriptions added

T. Hamre

Draft 4

2010
-
10
-
2
0

SEIS, INSPIRE, SISE sections added

D. Dunne

Draft 5

2010
-
10
-
21

Executive summary and conclusion

A. Patterson

Draft 6

2010
-
11
-
10

Feedback from external reviewer

incorporated

A. Patterson

T
. Hamre

P. Walker

1

2010
-
11
-
11

Final version approved by the coordinator

T. Hamre

Revised 1

2011
-
05
-
17


A.

Patterson

Revised 2

2011
-
05
-
25

Added section on portal

T. Hamre


NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

ii









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

Executive Summary


NETMAR aims to develop a pilot European Marine Information S
ystem (EUMIS) for
searching, downloading and integrating satellite, in situ and model data from ocean and
coastal areas.
This report addresses the NETMAR objective
of
using the
ISO/IEC 10746
RM
-
ODP (Reference Model for Open Distributed Processing)
standard

to define
the
NETMAR architecture

using an
incremental

and

iterative approach.


The report focuses on the process followed so far in producing the artefacts required of an
RM
-
ODP compliant system. It makes recommendations for how that process may be
conti
nued and adapted to provide an architecture which will be of use, in particular to other
European Marine Information Systems.


The RM
-
ODP defines the system architecture through five complementary but consistent
viewpoints:

1.

The
enterprise viewpoint
, which
has focus on the overall purpose, scope and
policies for the system, and describes its business requirements and how these can
be met.

2.

The
information viewpoint
, which defines the semantics of the information that the
system will handle

and the needed info
rmation processing. This viewpoint describes
the information handled by the system as well as the structure and type of supporting
data.

3.

The
computational viewpoint
,
which specifies the system as a set of objects (or
services) interacting through interface
s. This view describes the functionality of the
system and the functional decomposition.

4.

The
engineering viewpoint
, which focuses on the mechanisms and functions
required to support distributed interaction among objects in the system.

5.

The
technology viewpo
int
, which describes the techn
o
logies chosen to implement
the system.


This report presents a first version of
these viewpoints for the EUMIS pilot, with emphasis on
the semantic requirements and ontology search operation for one of the targeted user
commu
nities, the International Coastal Atlas Network (ICAN).
Specifically, we have
described the objectives of the ICAN community, the key use case (ontology term search),
and an Information Viewpoint consisting of invariant and variant metadata schemas that ar
e
central to support the ontology search use case. We have also identified a first set of
services and views in the Computational Viewpoint, and an example technologies used for
ontologies and an example of a physical deployment model for one selected serv
ice for the
Technology and Engineer
i
ng Viewpoint, respectively.

As the project progresses, the system
architecture will be extended and elaborated to meet the requirements of the other user
communities of the NETMAR project.


The report is intended to be u
nderstood by a wide, and not necessarily technical
, readership
.

However, a familiarity with the high
-
level concepts of RM
-
ODP will greatly facilitate
understanding, as these concepts are used repeatedly throughout the report. Similarly, some
familiarity wi
th the Universal Modelling Language (UML) will be of benefit in understanding
the examples given.


NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

iii









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

Contents


1

INTRODUCTION

................................
................................
................................
...........................

1

1.1

B
ACKGROUND

................................
................................
................................
...........................

1

1.2

O
BJECTIVE OF THIS REP
ORT

................................
................................
................................
...

1

1.3

T
ERMINOLOGY

................................
................................
................................
..........................

1

1.4

O
RGANISATION OF THIS
REPORT

................................
................................
.............................

2

2

DESIGN DECISIONS

................................
................................
................................
...................

3

2.1

P
ROCESS
C
HAINING

................................
................................
................................
.................

3

2.1.1

Combining Satellite and Model Data

................................
................................
...........

3

2.1.2

Chaining Editor and Orchestration Engine

................................
................................
.

3

2.2

S
EMANTIC
W
EB
S
ERVICES AND
O
NTOLOGIES

................................
................................
.......

3

2.2.1

Discovery

................................
................................
................................
..........................

3

2.2.2

Facets

................................
................................
................................
...............................

3

2.
2.3

Usage Metadata

................................
................................
................................
..............

3

2.3

U
SER
I
NTERFACE

................................
................................
................................
.....................

3

2.3.1

Portal

................................
................................
................................
................................
.

3

3

NETMA
R REFERENCE MODEL

................................
................................
...............................

7

3.1

P
ROCESS
C
HAINING

................................
................................
................................
.................

7

3.1.1

Combining Satellite & Model Data

................................
................................
...............

7

3.1.2

Chaining Editor & Orchestration Engine

................................
................................
.....

8

3.2

S
EMANTIC
W
EB
S
ERVICES AND
O
NTOLOGIES

................................
................................
.......

9

3.2.1

Discovery

................................
................................
................................
..........................

9

3.2.2

Metadata

................................
................................
................................
........................

10

3.3

U
SER
I
NTERFACE

................................
................................
................................
...................

14

3.3.1

Portal

................................
................................
................................
...............................

14

3.4

R
ESEARCH
O
BJECTIVES

................................
................................
................................
........

19

4

PROCESS

................................
................................
................................
................................
....

20

4.1

U
SE OF
RM
-
ODP

................................
................................
................................
...................

20

4.1.1

Benefits of RM
-
ODP

................................
................................
................................
.....

20

4.1.2

Incremental & Iterative Approach

................................
................................
...............

20

4.1.3

Communication

................................
................................
................................
.............

21

4.2

T
OOLING

................................
................................
................................
................................
.

21

4.2.1

MagicDraw

................................
................................
................................
.....................

21

4.2.2

Git

................................
................................
................................
................................
....

23

4.3

C
OMPARATIVE
A
NALYSIS

................................
................................
................................
.......

23

4.3.1

INSPIRE

................................
................................
................................
.........................

23

4.3.2

SEIS and SISE

................................
................................
................................
..............

24

4.3.3

GENESIS & GIGAS

................................
................................
................................
......

25

4.3.4

W3C, OMG & OASIS

................................
................................
................................
...

26

5

CONCLUS
IONS

................................
................................
................................
..........................

27

6

REFERENCES

................................
................................
................................
............................

28



NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

1









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

1

Introduction

1.1

Background

NETMAR aims to develop a pilot European Marine Information System (EUMIS) for
searching, downloading and inte
grating satellite, in situ and model data from ocean and
coastal areas. It will be a user
-
configurable system offering service discovery, access and
chaining facilities using OGC, OPeNDAP and W3C standards. It will use a semantic
framework coupled with ont
ologies for identifying and accessing distributed data, such as
near real
-
time, model forecast and historical data. EUMIS will also e
n
able further processing
of such data to generate composite products and statistics suitable for decision
-
making in
diverse

marine application domains.


Since NETMAR has as an objective the publication of a reference architecture for systems
within the framework of GMES and SISE, it has been recommended
[DAP+10]

that the
system be rigorously documen
ted using the Reference Model for Open Distributed
Computing
[ISO10
]
. Furthermore, in line with the recommendations of the ORCHESTRA
Reference Model
[O
GC07]
, NETMAR will adopt an incremental and iterative process whe
n
defining Abstract and Concrete Service Platforms, and their implementation in terms of
Service Networks.

1.2

Objective
of this report

The aim of this report is to outline a methodology for using the principles of enterprise
architecture to promote a shared u
nderstanding of the
NETMAR

system of systems.
We use
the language of RM
-
ODP to describe the system, in a standard, semantically consistent way
from a number of complementary viewpoints.

We use the standard UML profile for RM
-
ODP
in order to provide a consi
stent graphical representation of the system. We use tools which
understand the UML profile so that we may have automatic validation of the conformance of
the system description to the RM
-
ODP specification.


The shared understanding we are trying to promot
e has two important facets. In order to
build a system that satisfies the user requirements, the partners must have a common vision
of high
-
level technical goals and how each partner’s contributions help to meet those goals.
In addition,
NETMAR
, as a resea
rch project, has the objective of communicating to external
parties who might be considering implementing a similar system of systems how they might
reproduce
NETMAR
’s successes, or avoid its mistakes.


In recognition of the fact that architectures are sel
dom static and that we will need to change
many of our assumptions about how the system will be built as we make steps to build it, we
describe how we plan to evolve the system through a number of iterations. We also describe
how we plan to keep in step wi
th evolving standards and technologies, particularly those
identified as being important in the Review of EIS Standards and Technologies

[DAP+10]
.


1.3

Terminology


Enterprise



An undertaking, especially one of some scope, complica
tion, and risk
.


Enterprise

architecture



A
rigorous description of the structure of an enterprise
.


UML Profile



A
generic extension mechanism for customizing
UML

models for particular
domains

and platforms.


NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

2









© 2010 NETMAR Consortium


EC FP7 Project No. 249024


1.4

Organisation of this report

Chapter 2: Desi
gn Decisions

We illustrate the concrete design decisions made in NETMAR’s first year of operation in
terms of the use
-
cases they address. These design decisions will form the basis for all future
development on NETMAR.


Chapter 3
:
NETMAR Reference Model

We

provide worked examples of describing each of the architectural views using RM
-
ODP,
UML4ODP, and MagicDraw. We describe the Enterprise View in terms of Communities and
Objectives and illustrate their interactions in terms of Use cases. We show examples of

Invariant and Static Schemas in the Information View. The Computational View illustrates
some of the Views and Services which will make up the
NETMAR

implementation. The
Technology View is expected to be the most dynamic and is therefore currently the lea
st
complete, but we illustrate this view with as selection of ontologies expected to be useful in
NETMAR
. Finally, the Engineering View shows an example
of a Service N
etwork
deployment in support of the channel Observatory use case.


Chapter 4: Process

We
describe the expected benefits of using RM
-
ODP and its associated UML profile,
UML4ODP. We describe the tooling we use for the system architecture, in particular the
MagicDraw UML tool. We outline the incremental and iterative approach to be taken to the
N
ETMAR architecture, and we describe how we plan to communicate the architectural
description and analysis. A comparison is provided with other relevant standards and
initiatives in order to show how NETMAR stands in relation to these and plan how it will t
ake
them into account.


NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

3









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

2

Design Decisions

2.1

Process Chaining


2.1.1

Combining Satellite and Model Data


2.1.1.1

Use cases

2.1.1.2

Components

2.1.1.3

Rationale

2.1.2

Chaining Editor and Orchestration Engine

2.1.2.1

Use cases

2.1.2.2

Components

2.1.2.3

Rationale

2.2

Semantic Web Services and Ontologies

2.2.1

Discovery


2.2.1.1

Use cases

2.2.1.2

Components

2.2.1.3

Rationale

2.2.2

Facets


2.2.2.1

Use cases

2.2.2.2

Components

2.2.2.3

Rationale

2.2.3

Usage Metadata


2.2.3.1

Use cases

2.2.3.2

Components

2.2.3.3

Rationale

2.3

User Interface

2.3.1

Portal


NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

4









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

The EUMIS portal must offer all of its products and services through a common user
interface. The user interface (UI) must sa
tisfy the following requirements:



It must be consistent, i.e. have a common look and feel throughout all pages of the
portal. (This requirement has a high priority.)



It must be easy to navigate and find relevant information, whether it is about specific
pr
oducts or services, or on the technologies that have been used to set up EUMIS.
New users must be able to quickly find what they are looking for. (This requirement
has a high priority.)



It must easy to operate the pilots, also for new users. (This requirem
ent has a high
priority.)



The UI must be visually appealing. (This requirement has a medium priority.)


2.3.1.1

Use cases

The first operation a new user will perform is to look up information about the products and
services offered by EUMIS. The user must be able
to look up this information by topic (e.g.
application domain) or by searching using free text. When navigating by topic and subtopics,
the users must always be able to return to the previous or top level with one mouse click.


Users may also want to ask q
uestions to the service providers, and enter the EUMIS forum
to check if someone else has already discussed the same issues. If not, the user posts his
question in the forum, and returns after a while to see if his questions have been answered.


Once a use
r has identified which pilot is of interest, he will access it and start looking at
products and services being offered. He can select which types of products he wants, and
EUMIS will display it on in a GIS map viewer. He can also choose to run a processin
g
service and when the result is ready, EUMIS will notify the user, and the computed
parameter can be displayed in the GIS viewer together with the previously retrieved
products.


2.3.1.2

Components

The Wiki will hold all information about products, services and t
echnologies for the pilots
(
Figure
2
-
1
). It will support easy navigation through the wiki pages, which are organised in a
hierarchy (
Figure
2
-
2
), as well as free text search. The service developers can
update their
respective pilot pages, and users can be permitted to post comments to the content. The
Wiki is publicly available.


The Forum will hold the Questions and Answers for topics that users want more information
about. The Forum will allow users to

post questions and developers to reply to these. A user
must be registered to post questions, but also guest users can read its content.


Pilots are comprised of a GIS map viewer component, and optionally a search and discovery
client, a service chaining
editor and a workflow engine. Together these components provide
the functionally requested by the targeted users in the application domain (e.g. Arctic sea ice
monitoring and forecasting).


2.3.1.3

Rationale

The criteria for choosing a portal framework have been:



It must support the leading portlet standards, notably JSR
-
168 and JSR
-
286. This will
ensure a high degree of flexibility in developing portlets, e.g. that a number of
programming languages can be used to develop EUMIS components.

NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

5









© 2010 NETMAR Consortium


EC FP7 Project No. 249024



It must be an open source

framework. This to ensure that new service provides can
set up their own portal based on it, and that the developed portal and components
can be sustained.


Based on this, we have chosen the Liferay Community Edition version 6, which is an open
source fra
mework which is being actively developed. Liferay has a large user and developer
base, offers a number of portlets built into the distribution (including e.g. wiki and forum),



Figure
2
-
1

The Wiki home page shows the top level wiki pages; one page for each pilot and
two supportive wiki pages for metadata and technologies&tools. Clicking on the heading for
pilot 3 (marked with arrow) will take the user to
the wiki page for this pilot.


NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

6









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

a)


b)


Figure
2
-
2

The wiki page for pilot 3, Ocean colour


Marine Ecosystem, Research and
Monitoring has a Table of Contents at the top allowing user to quickly jump to to
pics of
interest. By clicking on the heading for Ecosystem modelling (marked with arrow in (a)), the
browser will scroll to this topic (b). Note that current location in the wiki is always shown at
the top of the screen so the user can quickly go back to e
arlier topics or the wiki home page.


NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

7









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

3

NETMAR Reference Model

3.1

Process Chaining

3.1.1

Combining Satellite & Model Data

The expected results of the W
estern
E
nglish
C
hannel
O
bservatory

pilot include making
interoperable datasets and online comparison and tools avai
lable to a wide audience in order
to facilitate the use of advanced data analysis which can be used in peer
-
reviewed journals.
This is presented in our model by the Role of Data Scientist.


The Data Scientist requests, through the portal, one of a number o
f possible graphical
analyses of a combined dataset. The Orchestration Server hides from this user the details of
how the datasets are combined
. Under the covers, the Orchestration server combines the
results of a combination of data services and processin
g services to produce the end result.
The satellite data must undergo a change in resolution before being combined with the
model data and passed to the statistical analysis services.

The result is passed to the Data
Scientist as a graphical image which ap
pears in the appropriate window of the portal (
Figure
3
-
1
).


Figure
3
-
1

Combining Satellite & Model Data


NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

8









© 2010 NETMAR Consortium


EC FP7 Project No. 249024


Figure
3
-
2

Matchup Servic
e Engineering View



3.1.2

Chaining Editor & Orchestration Engine

In order to achieve the above transparency for as wide a user base as possible, and to be
able to do this in a reasonable amount of time, there is a supplementary Role of technical
Scientist. This

represents a user who has a good grasp of the science being done by the
Data Scientist, but also enough knowledge of the technical characteristics of the services
being combined to be able to easily design process chains with the help of the right tools.


The Technical Scientist constructs Process Chains through a series of edits, each of which
attempts to couple two existing services together. Based on the services capabilities, the
Semantic Web Services make a decision on whether the services inputs and
outputs are a
correct match

Figure
3
-
3
.

This compatibility test can be based on a number of factors, e.g.
the dimensions of the parameters (Kilograms, metres, seconds, etc.) or the type of
measurement being made (e.g. Water Leavin
g Radiance v. Suspended Particulate Matter).


NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

9









© 2010 NETMAR Consortium


EC FP7 Project No. 249024


Figure
3
-
3

Process Chain Editing



3.2

Semantic Web Services and Ontologies

3.2.1

Discovery

Coastal web atlases (CWAs) in the ICAN network deal with a variety of thematic

priorities
and can be tailored to address the needs of a particular user group. Coastal mapping plays
an important role in informing decision makers on issues such as national sovereignty,
resource management, maritime safety and hazard assessment. While
CWAs contain a
diverse range of datasets, the inclusion of both real
-
time and historical data products from
the operational oceanography and remote sensing communities has been more limited,
often because such data has been difficult to access in terms of
both data policy and data
interoperability. To help progress CWA development, the ICAN community is interested in
connecting to such data streams, but also connecting CWA datasets to the web
-
based EIS
(Environmental Information System), therefore adding va
lue.


NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

10









© 2010 NETMAR Consortium


EC FP7 Project No. 249024


Figure
3
-
4


ICAN Ontology T
erm Search


3.2.2

Metadata

The metadata invariant schema

(
Figure
3
-
5
)

constrains the way in which the
NETMAR

data
providers supply metadata records in
support of data and services. It does this in order that
the implementers of the system may make reasonable assumptions about how what
metadata is available. It forms part of the contract between
NETMAR

and the providers of
data to
NETMAR
.


The following i
s are examples of the types of constraint to be imposed by the
NETMAR

metadata invariant schema;



metadata element names are bound to a unique meaning and type specif
ied in ISO
19115

or 19119.



metadata values are bound to a published element name (and t
here
fore to a
meaning and type)



a Service must hav
e an associated metadata record

NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

11









© 2010 NETMAR Consortium


EC FP7 Project No. 249024



a Feature may op
tionally have a metadata record



a metadata record must be attached to either a datas
et or a dataset series, or both



the set of metadata elements used for semantic

discovery and chaining is a subset of

the published metadata records



the set of metadata elements used for uncertainty propagation is a subset of the set
of metadata elements used for semantic discovery and chaining
.


It is expected that an authoritative
set of constraints agreed by all partners will form part of
deliverable D2.
2.2

(
NETMAR system architecture design


final version
)
.


Figure
3
-
5

illustrates how some of these constraints can be captured in terms of UML:



The OCL co
nstraint {self.metaDataElement
-
>isUnique(name)} specifies that each
MetadataElement

that belongs to an EU
MIS must have a name property which
form
s a unique string within that EU
MIS.



Each MetadataElement has only one MetadataType (cardinality of 1).



A Serv
ice has an association with a MetadataRecord of cardinality 1.



A Feature has a cardinality of 0..1 with respect to MetadataElement, meaning it can
have no MetadataElement or 1, i.e. optional.



SemanticRecord is a generalisation of MetadataRecord.



Figure
3
-
5


Metadata Invariant Schema


The Semantics Invariant Schema
(
Figure
3
-
6
)
is intended to meet the objectives of the
Semantics use
-
cases, e.g. Ontology Term Search. It outlines a s
et of Information Object
s

related to the Artefact
s

outlined in the
ontology term search
Process.


NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

12









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

A Term in this schema may be linked with another Term by a TermRelation.
This is indicated
in the diagram by an aggregation relation with cardinality 2, i.e.,

each TermRelation relates
exactly two terms.
Terms and TermRelations may be combined together in a TermGraph.

This is shown by an

aggregation relation going fro
m TermGraph to Term, and another going
from TermGraph to TermRelation.

TermGraph, TermRelation a
nd Term are decorated,
respectively, with the stereotypes <<owlO
ntology>>, <<objectproperty>> an
d
<<owlIndividual>> from the Ontology Definition Metamodel
[OMG09a]

to indicate that

TermRelations may be related to predicates in an RDF vocabu
lary, e.g. SKOS. A Term has
an associated Type and Description.



Figure
3
-
6


Invariant Schema for Semantic Framework



NETMAR

Core is the minimum set of metadata elements that should be supported by
anyone
wishing to publish data on the
NETMAR

platform. It is an ISO19115 profile.


The ISO 19139 XSD files have been reverse engineered using MagicDraw. The
NETMAR

Core Static Schema will contain an instance for each ISO 19139 element which forms part of
the
NETM
AR

Core. The intention is to allow for an easy way of verifying
NETMAR

Core
compliance using the UML tool. This will be illustrated using the
Marine Information Digital
Atlas

(
MIDA
)

metadata example.


Please note that the diagram
(
Figure
3
-
7
)
shown is not a complete specification of
NETMAR

Core.

A subset of NETMAR Core has been selected in order to illustrate

the relationship
between the XSD
-
generated types and the types selected as belonging to NETMAR Core.

NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

13









© 2010 NETMAR Consortium


EC FP7 Project No. 249024


Figure
3
-
7

Static Schema for
NETMAR

Core


MIDA Metadata is a superset of
NETMAR

Core used by the MIDA Marine Atlas.

Figure
3
-
8

illustrates metadata from an example MIDA dataset [Dwy10]. Relationship w
ith
NETMAR

Core is illustrated by whether metadata items are allocated to instances of
ISO19115 classes already created within the
NETMAR

Core static schema, or external to
this schema.
E.g. the instance named minimumNorthing is a MIDA
-
specific extension
i
ntended to show extents in Irish National Grid coordinates.



Figure
3
-
8

MIDA Static Schema


NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

14









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

3.2.2.1

Facets

3.2.2.2

Usage Metadata

3.3

User Interface

3.3.1

Portal

Our first level of componentisation splits
NETMAR

into Services & View
s

(
Figure
3
-
9
)
.
Services are responsible for the 'heavy lifting', while Views should implement only
presentation logic. The Views will be implemented as a portal and associated portlets, but at
this stage we are trying to preserv
e independence from specific containerisation decisions.


Services that will eventually be described in the Computational Viewpoint include feature
Access Services, Map and Tiling Services, Catalogue Services, User management Services,
Authentication, Auth
orisation and Auditing Services, and any other services needed to
support the end
-
user experience.



Figure
3
-
9

NETMAR

Computational View Specification

Figure
3
-
10

shows a more detailed view of some of the NETMAR view components,
illustrating both internal interactions between view components and calls to external services.


The diagram illustrates a container object ‘Views’ such as might be used within a port
al
architecture to contain Portlets. It shows the pattern of delegation between the contained
objects, the container and the service interfaces to which the services will bind. In the
example, a Discovery object binds to a Login object in order to get info
rmation about an end
user form a user information service. It then uses this user information as context to request
a Graph (e.g. a Graph of discovery
-
related terms) from the container, which in turn
delegates this request to a service bound to the graph i
nformation service.

NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

15









© 2010 NETMAR Consortium


EC FP7 Project No. 249024


Figure
3
-
10

View Components with Interfaces



The Semantic Framework
(
Figure
3
-
11
)
incorporates the Ontology term search use case
from ICAN. In order to simpli
fy the interface, we apply the Composite pattern

[GHJV95
]

to
the TermType from the information view
. Because the TermType is a generalisation of Term
(
Figure
3
-
13
)

we can treat th
e TermType

as another term and the
refore treat the list of term
types as a specialised graph. Therefore the client
-
server interaction condenses

to a simple
repeated workflow of requesting a graph for a specific resource in a specific context
.

Fi
gure
3
-
12
)

shows s
ome of the interface signatures stereotyped as
<<CV_OperationInterfaceSignature>>, including some derived form the Orchestra
specification
[O
GC07]
.

An unresolved issue relates to the usage of Orchestra versus OGC
Services; as much of
the Orchestra specification is being adopted by OGC, we will in future
be referring to the OGC equivalent of the Orchestra interface where appropriate.


NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

16









© 2010 NETMAR Consortium


EC FP7 Project No. 249024


Figure
3
-
11


Service Components with Interfaces



Fi
gure
3
-
12

Interface Signatures


NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

17









© 2010 NETMAR Consortium


EC FP7 Project No. 249024


Figure
3
-
13

D
atatypes for the
NETMAR

Computational Specification


The Technology View is the most dynamic of the architectural

views in NETMAR. It is also
the one which has the strongest dependency on input from all the NETMAR partners. In this
report we limit the descriptive effort devoted to describing the technologies to an example of
the ontologies proposed for use in NETMAR,

illustrated in terms of the Onto
l
ogy Definition
Metamodel (ODM)
[OMG09a]

(
Figure
3
-
14
).


Some of the technologies whose usage in NETMAR will

be described fully in the final
architecture deliverable include
;



SKOS

(Simple Knowledge Organisation System)
[IS09]



OWL ( Web Ontology Language)
[MH04]



SPARQL query language for RDF
[PS08]

NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

18









© 2010 NETMAR Consortium


EC FP7 Project No. 249024


Figure
3
-
14

NETMAR Ontologies



W
e consider the matchup service being provided by PML with regard to supporting
distributed interaction.

The matchup service will allow data from different NETMAR data
services to be combined based upon position and time. For instance EO data held in WCS
or

in OpeNDAP could be queried to find any measurements matching a ferrybox series held
in a Web Feature Server, the combined results could then be supplied to another service for
further analysis. As it is often the case that EO pass times can differ consid
erably from the
times of the in situ measurements and the resolution will also vary, the service will provide
quality metadata listing these differences and will allow the user to define how restrictive the
matchup should be.


In defining the physical depl
oyment model in terms of a service oriented architecture, we
have chosen our mappings differently than would have been the case in a distributed object
architecture for example. The NV_Node stereotype

(
Figure
3
-
2
)
, in our example, r
epresents
an ownership boundary, rather than a physical server. The ownership boundary is assumed
to coincide with the domain associated with the service endpoint. The NV_Capsule
encapsulates a set of related functionality which is assumed to have its own
internal process
communication which it is beyond the scope of the
NETMAR

architecture to describe. An
NV_BEO (Basic Engineering Object) represents a capability which can be exposed to the
outside world by means of an NV_Channel.


The In Situ data is serve
d by the provider as WFS or SOS. We choose WFS for the
purposes of illustration, but as this data is consumed internally by PML, rather than being
exposed as
-
is, the choice of service binding will be of no architectural significance in this
case.

NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

19









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

3.4

Research
Objectives

NETMAR architecture development will follow the Constructive Research methodology
[Crn10]
[Crn10]
[Crn10]
[Crn10]
. The practical relevance of the research comes from the
real
-
world use
-
cases supplied by the NETMAR partners, and from the quality attributes
prioritised by the partners describing how they want the system to be built. Several
theoretical areas are relevant to the research, including architectural description languages
and v
iews, tradeoff analysis, design patterns and pattern languages, and metadata
harmonization and interoperability design. We will construct a model of the proposed
solution to the problems. We will conduct ATAM analysis which will be captured in the
architec
ture wiki in order to couple the design to the prioritised quality attributes. The
practicality of the solution will be demonstrated by the construction of the NETMAR
demonstration system. This will consist of existing software adapted to meet the NETMAR
o
bjectives and new software, in particular a portal which can be shown to a variety of end
-
users. It will not be feasible to demonstrate every aspect of the solution in this way. Where
there are gaps we will attempt to suggest practical future roadmaps for
implementing the
solution.


During the lifetime of the project, selected best practices will be submitted for review to an
appropriate external forum. The analysis tools and the knowledge base resulting from the
analysis process will be made available in t
he public domain.


Figure
3
-
15

NETMAR Methodology




NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

20









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

4

Process

4.1

Use of RM
-
ODP

4.1.1

Benefits of RM
-
ODP

All software projects of any significant size benefit from having a simplified version of the
system to be built i
n order that all stakeholders can ensure that they share a common set of
assumptions about the problem to be solved. Small co
-
located teams can get away with
relatively informal tooling such as paper, whiteboards, general purpose drawing tools and
presenta
tion software. The bigger and more geographically dispersed the team, and the
more complex the problem domain, the more benefit there is to using formalised approaches
to the description of the system. The main benefits are reduction in misunderstanding
th
rough the use of a set of concepts with well
-
defined semantics, and the availability of off
-
the
-
shelf tooling built around those concepts.


Complex systems also benefit from being viewed at different levels of abstraction and from
different stakeholder per
spectives. This reduces the cognitive load on any given stakeholder
by hiding information which is not relevant in the context of her needs and skills. Hence the
popularity of view based models and architectures such as 4+1
[Kru95]
, Z
achman
[Zac87]
,
DoDAF
[DOD03]

and of course RM
-
ODP.


NETMAR can be considered a highly complex system for a number of reasons; a large
number of geographically distributed partners with a wide variety of use
-
cases, a larg
e body
of standards and legislation to be complied with, many and varied business drivers and
policies, and a dependence on rapidly changing technologies.


RM
-
ODP provides a rigorous model for understanding such a complex distributed system. It
has a sound

theoretical underpinning based on ideas in philosophy, systems thinking and
mathematics [Lin10]. First published in 1995, it has been tested on many distributed systems
and has proved to be a simple effective and elegant way of communicating systems
archi
tectures.


4.1.2

Incremental & Iterative Approach

In order to maximise learning during the design of the NETMAR Architecture we shall adopt
an approach of taking vertical slices and working through the architectural process as fully
as practical in a series of i
terations [Mar99]. For example, we describe the ICAN ontology
term search use case in the Engineering View, then attempt to follow through the
implications of this use case in terms of Information View and Computational View. This
allows us to make early d
ecisions on each aspect of designing the NETMAR Architecture
and solicit feedback from all stakeholders on the quality of those decisions. In this way we
can more easily identify risks associated with specific decisions.


Ideally, each vertical slice would

begin with a specific use case and culminate in the design
and implementation of actual working code as this would give us the best possible feedback
on how well the architectural decision
-
making process had worked. It is recognised,
however, that it may
not always be possible to schedule workloads between partners in order
to make this possible. Resolving the tension between the need to provide an authoritative
reference architecture for EUMIS and the need to meet specific project deadlines will be one
of

the challenges of architectural governance. The approach taken so far is to select a slice
and work through it to the extent possible, then select another and do the same, returning to
the former slice when input from one of the partners makes it possible

to progress further.


NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

21









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

Furthermore, taking a purely top
-
down approach may not always be the most practical
approach. In constructing the Engineering View, we took advantage of the fact that PML had
furnished some very useful information on the services the
y were providing. As this mapped
very well to a SOA definition of a physical deployment model, we chose to start in the middle
and work outwards for this particular slice. Since the driver is to produce visible artefacts that
can be used to measure progres
s against overall objectives, we need to be as pragmatic as
possible in how we arrive at those artefacts.


4.1.3

Communication

MagicDraw has a Web Publisher Collaboration tool which allows us to publish as much of
the UML model as we wish to a Tomcat server. We
used this to share the design on a
continuing basis with the partners. In addition we set up a Dokuwiki instance to provide
additional information on the diagrams, approach taken, etc. Dokuwiki was chosen because
it is a lightweight, easily usable wiki wit
h good access control options.


4.2

Tooling

4.2.1

MagicDraw

It was decided to use UML to implement the
RM
-
ODP

specification of t
he NETMAR
Architecture and the
UML4ODP [ISO09] UML Profile was chosen

for this purpose. The
MagicDraw (
http://www.magicdraw.com
) UML editor was chosen because it is a well
-
regarded UML tool with a good feature set, and because there is a free plugin available
which supports RM
-
ODP development (
http://w
ww.jrromero.net/tools.html
).


The plugin allows the user to create from scratch a project containing the main specifications
for UML4ODP.
Figure
4
-
1

shows the mandatory specifications for an RM
-
ODP compliant
model. These are the specifications for the Enterprise, Information, Computational,
emgineering and Technology Viewpoints, and the minimum set of correspondences between
them.


MagicDraw impo
rts the UML4ODP Profile and provides a set of specialised diagrams for the
specifications, and icons for the UML4ODP stereotypes. A UML stereotype is a way of
extending UML for a specific domain or purpose [OMG05]. Stereotypes in UML are often
represented
as text, e.g. <<Enterprise_Spec>>, but can also be linked to a graphical
representation, giving an extra visual cue to help the user understand what is being depicted
in the UML diagram.

NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

22









© 2010 NETMAR Consortium


EC FP7 Project No. 249024


Figure
4
-
1


MagicDr
aw ODP System Specification


The RM
-
ODP Plugin also allows the user to validate the system against the RM
-
ODP
constraints (
Figure
4
-
2
). This provides a useful checklist that prevents simple errors from
creeping into the system sp
ecification, e.g. omission of a model, failure to place an element
of a specific stereotype (e.g. <<EV_Community>>) in the correct place in the containment
hierarchy (e.g. <<EV_CommunityContract>>, etc.

NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

23









© 2010 NETMAR Consortium


EC FP7 Project No. 249024


Figure
4
-
2

ODP System Validation


The reverse engineering functionality of MagicDraw was also employed to good effect in
producing UML models of various XML Schemas, e.g. ISO 19139. This made it easier to
trace the conformance of our metadata profiles to ISO1
9115.

4.2.2

Git

The Git distributed version control system was chosen in order to track changes to the
MagicDraw project files (
http://git
-
scm.com/
). As every Git clone is a repository in its own
right, this gave us the flexib
ility to work standalone without network connection, while still
being able to easily push the latest revisions to a remote branch for sharing or backup. The
flexibility of Git allows us to synchronise the repository easily to a USB flash drive or a
remote

server.


4.3

Comparative Analysis

A number of iniatives, standards and technologies have already been identified as being
relevant to NETMAR’s architecture
[DAP+10]
. We compare a selection of these with
NETMAR with the objective of

finding potential points for information sharing.


4.3.1

INSPIRE

An expected impact of
NETMAR

is to
support

the implement
ation of the INSPIRE Directive.
It is therefore
required
that the NETMAR ar
chitecture specification dovetail with
INSPIRE
’s

common principle
s
,
implementation rules
and
guid
ance documents.
The Directive requires
that common implementation rules are adopted in a number of sp
e
cific areas (
i.e. m
etadata,
d
ata
s
pecifications,
n
etwork
s
ervices,
d
ata and
s
ervice
s
haring
,
and
m
onitoring and
r
eporting)
.
NETMAR as an ICT project is specifically focusing on the areas of m
etadata,
d
ata
s
pecifications,
and n
etwork
s
ervices
.
To assist implementation, technical guidance
documents are provided
by INSPIRE. These
documents
an
d related supporting materials
give
d
etailed technical documentation
concerning
the relevant
implementation rule
s
.



NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

24









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

Table
4
-
1

lists the current (October 2010) status of relevant INSPIRE g
uidance
d
ocuments
.
As INSPIRE
guidance documents

are updated during the course

of the NETMAR project, it
is also necessary to incorporate these changes into the NETMAR system architecture if and
as appropriate.


I
mplementation
R
ule

Guidance document

Status

Version

Date of last
revision

Metadata

Technical Guidelines based on


ISO 19115 and ISO 19119

Version 1

v
1.2

2010
-
06
-
16

Data
Specifications

Annex I Data Specifications

(9 documents)

Version 3

v3
.0.1

to v3.1

2010
-
04
-
26

Annex I
I

Data Specifications


(4 documents expected)

V2:April
2011

V3:
May

2012

-

-

Annex I
I

Data Specifications


(21 documents expected)

V2:April
2011

V3:
May

2012

-

-

Network
Services

Discovery Services

Version 2

v2.12

2010
-
06
-
17

View Services

Version 2

v2.12

2010
-
06
-
16

Download Services

Draft

v2.
0

25
-
09
-
2009

Coordinate Transformation
Services

Draft

v2.1

2010
-
03
-
15

Schema Transformation
Service

Draft


2
010
-
06
-
1
1

Table
4
-
1

Guidance documents (October 2010)



4.3.2

SEIS and SISE

The
Shared Environmental Information System f
or Europe (SEIS) was
proposed

by the
European Commission

i
n January 2008
.
It is a collaborat
ive initiative of the European
Commission and the European Environment Agency (EEA) to establish with the Member
States an integrated and shared pan
-
European environmental information system. The
proposal will offer a legal basis for an integrated and sust
ainable EU
-
wide eReporting
System which will be built as a partnership between European Institutions (European
Commission/EEA) and the Member States. The
SEIS

concept is based on the principles of a
decentralised system

and builds
upon
the experience with
the implementation of the
INSPIRE Directive and the U
.
S
.

EPA eReporting System
.
This system will better integrate all
existing data gathering and information flows related to EU environmental policies and
legislation. A major challenge is to organise the l
arge amount of environmental data and
information and to integrate these, where desirable, with existing social and economic data.
This data should be made available together with tools tha
t allow experts to do their own
analyses and to communicate their r
esults in ways which policy makers and the public can
easily understand

[SEIS]
.


The
Single Information Space in Europe for the Environment (SISE)

was
proposed

by the
European Commission’s
DG Information Society and Media (INFSO)

during th
e preparation
of FP7 Work Programmes
.
The aim of SISE has an ICT research vision to enable

[Hreb09]
:




real
-
time connectivity between multiple environmental resources;



seamless cross
-
system search;



cross
-
border, m
ulti
-
scale, multi
-
disciplinary data acquisition, pooling and sharing;



service
-
chaining on the web, thereby stimulating data integration into innovative
value
-
added web services.


NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

25









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

T
opics
such as
service
-
oriented architecture (SOA)
,
web services
,
process cha
ining and
uncertainties
,
real
-
time mapping and modelling
,
controlled vocabularies
,
data interoperability
,
open standards
,
open source software
,
model driven communities
,
web communities
,
data
visualisation

and
SISE deployment models

are
all
central to impl
ementing SISE
[
SISE
2
]
.



The
SEIS and SISE initiatives
are seen as complementary. SEIS is
taking a more top
-
down
approach which is
focus
ing

on the
establishment of an
environmental
information system for
the E
uropean Environment Agency, European Commission and EU member states. In
contrast
, SISE is taking a more bottom
-
up approach which is focused on ICT research to
achieve better integration of environmental information

systems
.
However, b
oth
initiatives
rely
on INSPIRE for providing the overarching Spatial Data Infrastructure (SDI) framework.

Currently, there is no EU budget dedicated specifically to SEIS.
Instead,
European Union
actively supports the concept of SEIS t
hrough its research programmes
(e.g. FP6
,
FP7).


NETMAR is specifically funded by
DG Information Society and Media (INFSO)
, where
expected impact is to contribute to SISE through improved systems connectivity and
semantic interoperability. NETMAR is liaising with relevant SISE cluster projects fun
ded by
INFSO

such as
UncertWeb (
http://www.uncertweb.org
)
,
ENVISION (
http://www.envision
-
project.eu
), etc. to help achieve better leverage towards SISE. NETMAR is als
o expected to
contribute to the development of SEIS where
the outputs of
such
ICT research
(e.g. system
architecture) is

seen as essential for supporting the implementation of SEIS.


4.3.3

GENESIS & GIGAS

The GENESIS

project uses RM
-
ODP to describe the architec
ture of its six thematic pilots:



Air quality pilot in London (UK)



Water Quality Pilot on Bodensee/Constance Lakes (Germany)



Air quality pilot on Bavaria (Germany)

[DLR09]



Water quality pilot on Oder Estuary (
Baltic Sea)

[SGH09]



Water quality pilot on Villerest Reservoir (France)


Air and Coastal Water Quality Pilot on French Riviera

[ACRI09]

While the applicatio
n domains for the pilots are different from those of NETMAR, their
system architecture descriptions provide valuable information on how to describe the
architecture for a pilot EIS. While the first version of the GENESIS pilots focus on a limited
number of

use cases and services, as can be expected, these documents contain detailed
descriptions of the planned functionality as well as the needed input data and the generated
output data. Some categories of services, such as data standardisation and metadata
g
eneration are also relevant for NETMAR, with modifications of details on implementation to
meet the needs of the NETMAR pilots.


The GIGAS project analysed the system architectures of INSPIRE, GMES and GEOSS
using RM
-
ODP
[GC09a]

[GC09b]

[GC09c]

[GC09e]

[GC09d]
. These specifications provid
e
detailed information about the system architectures of these key SDI initiatives and as such
serve as reference information for NETMAR. The GIGAS project formally ended in May
2010, but the GIGAS Consortium initiated the European GEO SIF
1

to continue coo
rdination
of European requirements for GEO and GEOSS related activities. Updates to the analysis of
system architectures resulting from this initiative should also be followed closely by
NETMAR.





1

http://www.thegigasforum.eu/sif

NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

26









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

4.3.4

W3C, OMG & OASIS

A number of standards not specific to NETMA
R’s application domain will be monitored for
possible relevance to the NETMAR architecture.


SoaML
[OMG09]

is a UML profile and metamodel designed to support service modelling and
design in a model
-
driven development approach. The NETMAR
Description of Work does
not specifically prescribe a model
-
driven development approach, so the choice of adopting
model
-
driven development will be left to the NETMAR partners, unless strong reasons for
adoption are discovered by analysis of the system’s q
uality attributes. Even if MDD is not
widely adopted by the project partners, the use of a standard notation for describing services
will fit well with the project’s overall objectives, and should be considered.


The Business Process Modeling Notation (BPM
N)
[OMG08]

is intended to provide a
standard notation for modelling business processes that is understandable by all users and
also to provide a standard visualisation of XML
-
based process languages. As NETMAR’s
service chaining editor wil
l use a graphical representation of a business process, this
standard will be relevant.


The Rules Interchange Format (RIF)
[W3C10]

is a W3C working group whose charter is to
look at various rules languages with the aim of providing a stand
ardised language for
declarative rules and production rules. One possible area of relevance to NETMAR is in the
semantic matching aspect of service chaining. Although it is clear that simple implicit rules
(such as always accepting a narrower term than the

one specified as an input parameter) will
allow us to go a long way in terms of functionality, it may become necessary to handle more
complicated edge cases, or define more fine
-
grained error
-
handling. In this case, the output
of this standardisation effo
rt may be relevant.


The OASIS Reference Model for Service Oriented Architecture (SOA
-
RM)
[OAS06]

provides
a common language for describing service oriented architectures. It details high level
concepts that are relevant to a service orie
nted architecture, and as such may be used to
clarify terms that we use when describing NETMAR services.

NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

27









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

5

Conclusions


This report outline
s the planned approach for using RM
-
ODP to document the NETMAR
system architecture. It provides examples of RM
-
ODP vie
ws reflecting the known current
state of the architecture. It documents the process used so far to communicate the
architecture to all NETMAR partners. It makes proposals for how a full authoritative
architectural specification will be produced according t
o the project schedule. It provides a
basis for
discussion of an architectural governance proposal which will ensure that the
authoritative architectural specification will be both useful and an accurate representation of
the NETMAR system of systems.


The

architectural descriptions and other documentation provided in this report are not
intended to be exhaustive. They are intended to illustrate an overall approach, in order that
feedback on that approach may be i
ncorporated into the next phase

of the archi
tectural
design process. In choosing candidate components for architectural analysis, we have
prioritised those which have the greatest potential for either illustrating the benefits of the
methodology we have chosen, or exposing its weaknesses.


The next
phase of the architectural design process will consist of broadening the scope of
the architectural analysis to include all of NETMAR’s

use cases
, while conducting a deeper
analysis of those components considered to be most relevan
t

in producing the author
itative
specification. In order to do this effectively, continuous feedback from all project partners will
be crucial, as each partner has its own area of unique expertise vital to the overall analysis
of the project.

The culmination of this effort will be

an authoritative architectural specification
which can be used as input for other SISE projects or standardisation efforts.

This phase will
be overseen according to the guidelines put in place by the architectural governance plan,
which will reflect polic
ies driven by feedback from this report.


NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

28









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

6

References


[ACRI09]

ACRI, 2009. D8100.3
-

Coastal Water and Air Quality Thematic Pilot Specification
Document. GENESIS Deliverable D8100.3, issue 1.0, 15/07/2009. Online at
http://genesis
-
fp7.eu/publications

(accessed 6 April 2010).


[Bej09]

Béjar, R.,
2009.
Contributions

to

the

modelling

of

spatial

data

infrastructures

and their portrayal services
.
PhD Dissertation, Computer
Science and Systems Engineering Depart
ment, University of

Zaragoza
,
Spain.

[Crn10]

Crnkovic,

G.
Constructive Research and Info
-
Comp
utational Knowledge
Generation,

Model
-
Based Reasoning in Science and

Technology, pp.
359
-
380, 2010
. [Online].

[DAP+10]

Dunne, D. et al. 2010.
Review of projects, initiatives & technologies addressing
system architectures for distributed Environmental Information Systems (EIS).
NETMAR

(Open service network for marine environmental data) Deliverab
le
D3.2. European Commission Information Society and Media Directorate
-
General
Grant Agreement Number 249024.

[DOD03]

US Dept of Defence, 2003. DoD Architecture, Volume 1: Definitions and
Guidelines, Version1

[DLR09]

DLR, 2009. D2100.3
-

Air Quality Themati
c Pilot Specification Document.
GENESIS Deliverable D2100.3, issue 1.0, 15/07/2009.


Online at
http://genesis
-
fp7.eu/publications

(accessed 6 April 2010).

[Dwy10]

http://isde.ucc.ie/geonetwork/srv/en/iso19139.xml?id=10

[GHJV95
]

Gamma, Helm, Johnson, Vlissides. Design Patterns: Elements of reusable
object
-
oriented software, Addison
-
Wesley, 1995

[GC09a]

GIGAS Consortium, 2009a. GIGAS T
echnology Watch Report Summary
Techn
i
cal Note. Deliverable reference D2.2b, revision 103, 10.12
-
2009. Online at
http://www.thegigasforum.eu/cgi
-
bin/download.pl?f=354.pdf

(accessed 2
6 March
2010).

[GC09b]

GIGAS Consortium, 2009b. GIGAS Comparative Analysis Technical Note.
Deli
v
erable reference D2.3b, revision 200, 14
-
12
-
2009. Online at
http://www.thegigasforum.e
u/cgi
-
bin/download.pl?f=359.pdf

(accessed 26 March
2010).

[GC09c]

GIGAS Consortium, 2009c. GIGAS Cross
-
Initiative Scenarios. Deliverable
Re
f
erence D2.2b, revision 104. Online at
htt
p://www.thegigasforum.eu/cgi
-
bin/download.pl?f=350.pdf

(accessed 26 March 2010)

[GC09d]

GIGAS Consortium, 2009d. GIGAS Technology Watch Report Architecture
Technical Note. Deliverable reference D2.2b, version 103, 15
-
11
-
2009. Online at
http://www.thegigasforum.eu/cgi
-
bin/download.pl?f=345.pdf

(accessed 26 March
2010).

[GC09e]

GIGAS Consortium, 2009e. GIGAS Comparative Analysis Annex. Deliverable
reference D2.3b (Annex), version 200,

14
-
12
-
2009. Online at
http://www.thegigasforum.eu/cgi
-
bin/download.pl?f=360.pdf

(accessed 30 March
2010).

[Hreb09]

Hřebíčeka, J., Pillmannb, W. 2009, Shared Environmental Informati
on System
and Single Information Space in Europe for the Environment: Antipodes or
Associates?, Opportunities of SEIS and SISE: Integrating Environmental
NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

29









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

Knowledge in Europe, European conference of the Czech Presidency of the
Council of the EU TOWARDS eENV
IRONMENT. Online at


http://www.epractice.eu/files/SEIS%20and%20SISE%20for%20the%20Environm
ent_Antipodes%20or%20Associates.pdf

(acces
sed 19 April 2010).


[IS09]

Isaac, A., and Summers, E.: SKOS Simple Knowledge Organization System
Primer. W3C Working Group Note 18 August 2009. Available online at:
http://www.w3.org/TR/skos
-
primer/
.

[ISO
09]

Use of UML for ODP system specifications.
ITU
-
T Recommendation X.906 |
ISO/IEC 19793

[ISO10
]

ITU
-
T X.903 | ISO/IEC 10746
-
3 Information Technology


Open Distributed
Processing


Reference Model


Architecture

[Kru95]

Kruchten, P.B. 1995. The 4+1 View M
odel of Architecture
,
IEEE Software

12 (6)
p. 42
-
50

[Lin10]

Linington, Peter.

The Reference Model of Open Distributed Processing :
Foundations , Experiences and Applications. Computer Standards & Interfaces

[Mar99]

Martin, R, 1999.
Iterative and Incrementa
l Development (IID)


[MH04]

McGuinness, D., and Harmelen, F.: OWL Web Ontology Language: Overview.
W3C Recommendation. 10 February 2004. URL: http://www.w3.org/TR/owl
-
features/.

[OAS06]

OASIS, 2006. Reference Model for Service Oriented Architecture 1.0

[O
GC07]

Open Geospatial Consortium, 2007. Reference Model for the ORCHESTRA
Architecture (RM
-
OA) V2 (Rev2.1)

[OMG05]

Object Management Group. Unified Modeling Language: Superstructure

[OMG08]

Object Management Group, 2008.
Business Process Modeling Notation,

V1.1

[OMG09]

Object Management Group 2010.
Service oriented architecture Modeling
Language (SoaML)
-
Specification for the UML Profile and Metamodel for Services
(UPMS)

[OMG09a]

Object Management Group, 2009. Ontology Definition Metamodel
. V1.0

[PS08]

Prud’
hommeaux, E., and Seaborne, A.: SPARQL Query Language for RDF. W3C
Recommendation. 15 January 2008. URL:
http://www.w3.org/TR/rdf
-
sparql
-
query/
.

[PTS+10]

Pladsen, J.I. et al.
Use case specification a
nd schedule for testing
.

NETMAR
(Open service network for marine environmental data) Deliverable D3.2.
European Commission Information Society and Media Directorate
-
General Grant
Agreement Number 249024.

[
SISE
2
]

Towards a Single Information Space for the Environment in Europe, Experts
Consultation Workshop
. Online at
http://cordis.europa.eu/fp7/ict/sus
tainable
-
growth/workshops/ws
-
20080215_en.html

(accessed 19 April 2010).

[SEIS]

Shared Environmental Information System (SEIS). Online at


http://ec.europa.eu/environment/seis/index.htm

(acce
ssed
20

October

2010).

[SGH09]

SGH, 2009. D3100.3
-

Fresh Water Quality Thematic Pilot Specification
Doc
u
ment. GENESIS Deliverable D3100.3, issue 1.0, 15/07/2009. Online at
http://genesis
-
fp7.eu/publication
s

(accessed 6 April 2010).

[W3C10]

RIF Use Cases and Requirements

(
http://www.w3.org/2005/rules/wiki/UCR
)

[Val
01]

Vallecillo
,
Antonio
, 2001.
RM
-
ODP: T
he ISO Reference Model for Open
Distributed Processing

NETMAR Deliverable

D2.2.1: NETMAR system architecture design


First version

30









© 2010 NETMAR Consortium


EC FP7 Project No. 249024

[Zac87]

Zachman, J. A., 1987. A framework for info
rmation systems architecture, IBM
Systems Journal, 26 (3)