Open Geospatial Consortium Inc.
Date: 2010-06-04

OGC 10-028r1
Version: 0.5.0
Category: OpenGIS®

Best Practices Document

Editor(s): A. Biancalana, P.G. Marchetti, P. SmitsGIGAS Methodology for comparative analysis of informationand data management systems

Copyright © 2010 Open Geospatial Consortium, Inc.
To obtain additional rights of use, visit http://www.opengeospatial.org/legal/.

Warning
This document defines an OGC Best Practices on a particular technology orapproach related to an OGC standard. This document is not an OGC Standard andmay not be referred to as an OGC Standard. It is subject to change without notice.
However, this document is an official position of the OGC membership on thisparticular technology topic.

Document type:
Document subtype:
Document stage:
Document language:

OGC® Best Practices Document
Approved
EnglishLicense Agreement
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below,
to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property
without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish,
distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to
do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual
Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above
copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTSTHAT MAY BE IN FORCE ANYWHERE IN THE WORLD.
THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULARPURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDEDIN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILLMEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE
UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT
THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OFINTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY
DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTINGFROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH
THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all
copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except asprovided in the following sentence, no such termination of this license shall require the termination of any third party end-user
sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual
Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent,
copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license
without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy orcause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual
Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without
prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may
authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any
LICENSOR standards or specifications.
This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United
Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of thisAgreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable,
and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be
construed to be a waiver of any rights or remedies available to it.
None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported inviolation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction
which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any
regulations or registration procedures required by applicable law to make this license enforceableii

Copyright © 2012 Open Geospatial Consortium

OGC 10-028r1

Contents

Pagei.

Preface......................................................................................................................v

ii.

Submitting organizations ....................................................................................... vi

iii.

Document contributor contact points .................................................................... vii

iv.

Revision history ................................................................................................... viii

Foreword ............................................................................................................................ ix
Introduction ........................................................................................................................ xi
1

Scope ........................................................................................................................1

2

Compliance ..............................................................................................................2

3

Normative references ...............................................................................................2
3.1
Reference Documents..........................................................................................3
3.2
Web References ...................................................................................................34

Terms and definitions ..............................................................................................4

5
5.1

Conventions .............................................................................................................4
Abbreviated terms ...............................................................................................4

6

Methodology objectives ...........................................................................................6

7

Description of Convergence Process .......................................................................88

Methodology ..........................................................................................................10
8.1
Overview ...........................................................................................................10
8.1.1
Introduction to RM-ODP ..............................................................................10
8.1.2
Mapping of RM-ODP to the Methodology...................................................12
8.2
Identification of Convergence Objectives .........................................................14
8.3
Technology Watch ............................................................................................16
8.3.1
Overview .......................................................................................................16
8.3.2
Enterprise Viewpoint ....................................................................................20
8.3.2.1 Objectives ..........................................................................................................20
8.3.2.2 Documentation ..................................................................................................21
8.3.3
Information Viewpoint..................................................................................218.3.3.1 Objectives ..........................................................................................................218.3.3.2 Documentation ..................................................................................................22
8.3.4
Service Viewpoint .........................................................................................23
8.3.4.1 Objectives ..........................................................................................................23
8.3.4.2 Documentation ..................................................................................................23
8.3.5
Engineering Viewpoint .................................................................................25
8.3.5.1 Objectives ..........................................................................................................25
8.3.5.2 Documentation ..................................................................................................25
8.3.6
Technology Viewpoint..................................................................................28

ii

OGC 10-028r1

8.3.6.1 Objectives ..........................................................................................................28
8.3.6.2 Documentation ..................................................................................................29
8.4
Comparative Analysis .......................................................................................30
8.4.1
Overview .......................................................................................................30
8.4.2
Comparative Analysis Section in Technical Note ........................................30
8.4.3
Issues and recommendations.........................................................................31
8.4.3.1 Overview ...........................................................................................................31
8.4.3.2 Criteria ...............................................................................................................32
8.4.3.3 Syntax ................................................................................................................33
9

Annexes..................................................................................................................34
9.1
Annex 1 Use Case Template .............................................................................34
9.2
Annex 2 Example of Architectural Analysis: GEOSS ......................................35
9.2.1
Enterprise Viewpoint ....................................................................................35
9.2.1.1 Summary Table .................................................................................................35
9.2.1.2 High Level Requirements ..................................................................................36
9.2.1.3 Context ..............................................................................................................37
9.2.1.4 Use Cases ..........................................................................................................37
9.2.2
Information Viewpoint..................................................................................37
9.2.3
Service Viewpoint .........................................................................................38
9.2.3.1 Service Metamodel ............................................................................................38
9.2.3.2 List of services...................................................................................................38
9.2.4
Engineering Viewpoint .................................................................................39
9.2.4.1 Component Types..............................................................................................39
9.2.4.2 Distributed Computing Environment ................................................................39
9.2.4.3 Engineering Policies ..........................................................................................40
9.2.4.4 Implementation Architecture .............................................................................42
9.2.5
Technology Viewpoint..................................................................................43
9.2.5.1 Component Implementation .............................................................................44
9.2.5.2 Run-time Environment ......................................................................................44
9.2.5.3 Deployed Service Instances and Networks .......................................................44
9.2.5.4 Standardisation Process .....................................................................................45
9.3
Annex 3 Requirements on Requirements ..........................................................47
9.4
Annex 4 Example of Draft Issue/Recommendation ..........................................50
9.5
Annex 5 RM-ODP in GEO Architecture Implementation Pilot........................52

FiguresPage

Figure 1 Process Overview ........................................................................................................... 8
Figure 2 RM-ODP Viewpoints from ISO/IEC 19793 .............................................................. 12
Figure 3 GEOSS Tiers ................................................................................................................ 42
Figure 4 Example of GEOSS Tiers Instantiation for the European Union............................ 43
Figure 5 SIF Role ......................................................................................................................... 45

Copyright © OGC 2010

iii

OGC 10-028r1

TablesPage

Table 1 Mapping of the RM-ODP Viewpoints to methodology .............................................. 19
Table 2 Example of Comparative Analysis table ...................................................................... 31
Table 3: Enterprise Viewpoint of GEOSS................................................................................. 36
Table 4: OGC Observation and Measurement Model ............................................................. 37
Table 5: Service meta-model and taxonomy ............................................................................. 38
Table 6: OGC Catalogue Service ............................................................................................... 39
Table 7: W3C Web Service Platform ....................................................................................... 40
Table 8: Resource Discovery ..................................................................................................... 41
Table 8 Extract of the Components Registered in GEOSS by September 9th 2009 ............. 45
Table 9 Extract of the Services Registered in GEOSS by September 9th 2009 .................... 45
Table 10 Contents of the RM-ODP Viewpoints for GEOSS AIP............................................ 53

iv

OGC 10-028r1

i.

PrefaceThis document has been written on the basis of a methodology developed within the
GIGAS Support Action financed by the European Commission in order to address theconvergence of global initiatives like GEOSS and the European interoperability
initiatives developed in the context of the GMES programme like HMA - Heterogeneous
Missions Accessibility and the INSPIRE spatial data infrastructure legislation.
The GEOSS, INSPIRE and GMES an Action in Support (GIGAS) promotes the coherent
and interoperable development of the GMES, INSPIRE and GEOSS initiatives throughtheir concerted adoption of standards, protocols, and open architectures.
The methodology has been applied in the GIGAS project for a parallel analysis of
GEOSS, INSPIRE, GMES, FP 6/7 projects and standardisation bodies, see [RD2] and[RD15].

Copyright © OGC 2010v

OGC 10-028r1

ii.

Submitting organizations

The following organizations submitted this document to the Open Geospatial Consortium
Inc.
European Space Agency
European Commission Joint Research Center Institute for Environment andSustainability
ElsagDatamat)
SpacebelConsiglio Nazionale Ricerche
Fraunhofer IITBvi

OGC 10-028r1

iii.

Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:
Name

Organization

A. Biancalana

ElsagDatamat-

Y.CoeneSpacebel

F.Fierens

European Commission Joint ResearchCenter Institute for Environment andSustainability

P.G. Marchetti

European Space Agency

S.Nativi

Consiglio Nazionale Ricerche

G.Percivall

Open Geospatial Consortium

P. Smits

European Commission Joint ResearchCenter Institute for Environment andSustainability

T.Usländer

Fraunhofer IITB

Copyright © OGC 2010vii

OGC 10-028r1

iv.

Revision history
Date

Release

Editor

15-02-2010

1.0.0

AndreaBiancalana

13-5-100.5.0Carl Reed

Primary
clausesmodified

Description

First Issue
VariousPrepare for publication as a BP

Attention is drawn to the possibility that some of the elements of this document may be
the subject of patent rights. The Open Geospatial Consortium Inc. shall not be held
responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of
any relevant patent claims or other intellectual property rights of which they may beaware that might be infringed by any implementation of the standard set forth in thisdocument, and to provide supporting documentation.

viii

OGC 10-028r1

Foreword
Statement from Hugo De Groof – European Commission: Directorate-General
Environment – Chief Scientist, Research and Innovation Unit
The European Union's 6th Environmental Action Programme 2001-2010 has set theframework for knowledge-based environmental policy making and assessment. It was
shown early in the process that priority policy actions related to climate change
mitigation and adaptation, the halting of the loss of biodiversity, environment and healthand more sustainable strategies for natural resource and waste management require
more timely, more accurate and more interoperable sources of information. A number ofthematic strategies on the marine environment, pesticides, soils, air quality and the urban
environment have led to the review and development of new elements of Community law
in these areas, such as the Marine Strategy Directive, the Soils Thematic Strategy, thePesticides Directive and the Clean Air for Europe Directive to name a few. In addition,
following the severe social and economic impacts of natural disasters such as floods andforest fires which occurred with increasing intensity in the last decade, the Community
decided on a legal framework for the management of floods and the further developmentof early warning and disaster response information systems. Together with the more
traditional measures for controlling emissions and pollution at the source, a risk
management and communication based approach has become a prominent part of theCommunities legal framework and initiatives.
To support the implementation of these policies, a number of obstacles related to theavailability and the sharing of the required data sources had to be tackled. The INSPIRE
directive has led to a roadmap of actions through which the necessary spatial data will
become more easily discoverable and accessible for stakeholders having to implement
the required information services. The GMES initiative of the Commission and theEuropean Space Agency tackles issues related to collection of the needed data fromspace and terrestrial observation systems as well as the development of data processing
services, which will enrich the data holdings too which stakeholders will have accessthrough the INSPIRE architecture. Both GMES and INSPIRE fit and contribute to the
GEO/GEOSS initiative as a regional contribution to the global ambition for developing a
Global Earth Observation System of Systems.
The GIGAS project plays an important role in this process as many actors active in theseprocesses need to align their technical developments according to a commonly agreed
framework of standards and architectural principles. A 'global to local' sharedenvironmental information space and system requires a high degree of technicalconvergence and solid guidelines for achieving this are absolutely required.
The GIGAS methodology and comparative analysis is a major contribution to achieving
these goals.

Copyright © OGC 2010ix

OGC 10-028r1

Statement from Jay Pearlman, Co-chair, GEO Architecture and Data Committee
GMES, INSPIRE, and GEOSS, are policies and initiatives that are affecting
environmental information management, in Europe and beyond. INSPIRE and GEOSS
each address a different aspect of the need to have a coherent and sustainableinteroperable data and information system that supports informed decision-making.
Because of their different formations and approaches, there is not a consistent approachto architecture and interoperability between these activities. For example, there arediffering emphases on the degree to which recognized standards play a core role inarchitecture frameworks.
As part of its mission, GIGAS has examined the development of a consensus process thatfacilitates communication between GMES, INSPIRE, GEOSS including other European
and international programs participating in GEOSS. A key to the process is thecoordination with the bodies that develop international standards for geospatial andobservational information. However, an effective process must address not only
standards, but also the methodologies for understanding, implementing and analyzing thearchitectures and frameworks used in systems.
This document defines a methodology to be used for analyzing and comparing different
information and data management systems. This methodology addresses many aspects ofsystem implementation, allowing evaluations in terms of business, enterprise, informationand engineering and technology architecture, as well as their strategic alignment. From
this perspective, the methodology has broad implications for the architecture of systemsof systems, systems themselves and related components. Bringing together INSPIRE,
GMES and GEOSS through the GIGAS project addresses the broad range of application
environments that are necessary to test and validate the many aspects of interoperability.
As a Co-chair of the GEO Architecture and Data Committee, I am pleased to express mysupport for this initiative of the GIGAS project and consortium to promote a methodology
for the comparative analysis of interoperable systems. This is a significant effort in
defining methodologies that supports the path forward in the GEOSS architecture andinteroperability developments and a valuable tool for managing composite and multiactor scenarios..
Ultimately, the existence and convergence of parallel spatial data infrastructure
initiatives, like the ongoing definition of the implementing rules for the INSPIRE
Directive, demands a high level of consistency and accepted methodologies, which at
European level is addressed in the GIGAS Support Action financed by the Directorate
General Information Society of the European Commission.

x

OGC 10-028r1

Introduction
The methodology described into this document is one of the tools that the GIGAS
consortium developed to examining the requirements, architectures and standards appliedin the systems in order to provide an evaluation of them in terms of business, enterprise,
information and engineering and technology architecture, as well as their strategicalignment. It has proven to be useful for analyzing and comparing different systems andidentifying areas of convergence, technology and interoperability gaps and as a tool forthe technical dialogue across different user communities.

Copyright © OGC 2010

xi

OGC® Best Practices Document

1

GIGAS Methodology for comparative analysis of informationand data management systems

1

Scope

Information, including spatial information, is needed for the formulation andimplementation of environmental policies and other European Community (EC) policies,
which must integrate environmental protection requirements in accordance with Article 6of the Treaty. In order to bring about such integration, it is necessary to establish ameasure of coordination between the users and providers of the information so that
information and knowledge from different sectors can be combined.
Measures are therefore required to reduce unnecessary duplication of data collection andto promote their harmonisation and dissemination and use. This should result in increased
efficiency, the benefits of which can be reinvested in improving the availability andquality of information, thus stimulating innovation and supporting e-Governanceservices. Spatial information plays a key-role because it allows information to be
integrated from a variety of disciplines for a variety of uses; it is fundamental building
block of the emerging electronic participatory approach in democracy and public
governance.
Measures are being put in place. Directive 2007/2/EC of the European Parliament and of
the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in theEuropean Community (INSPIRE) lays down general rules to establish an infrastructure
for spatial information in Europe for the purposes of Community environmental policies,
and policies or activities which may have an impact on the environment.
Furthermore Europe is addressing global issues related to the monitoring andmanagement of global change phenomena and the need for security related observations
with the GMES (Global Monitoring for Environment and Security) programme for the
implementation of information services to support decisions concerning environment andsecurity. GMES is based on observation data received from Earth observation satellites
and ground based information. GMES is jointly supported and financed by the European
Commission and the European Space Agency (ESA), which develops the Space
Component of GMES. In COM(2005)565 "GMES: From Concept to Reality", paramountfor the GMES service component is the development of the Spatial Data Infrastructure as
envisaged by INSPIRE.
According to COM(2008) 46 "Towards a Shared Environmental Information System(SEIS)", priority will be given to INSPIRE implementation and further development of
GMES , as a basis for improving respectively the sharing of environment-related data and1

OGC 10-028r1

information within Europe and the provision of services to public policy makers andcitizens.
Moreover, INSPIRE and GMES are contributions of the European Commission to theGroup on Earth Observations (GEO) and the related Global Earth Observation System of
Systems (GEOSS).
It is evident that INSPIRE, GEOSS, GMES and SEIS are policies and initiatives that are
affecting environmental information management, in Europe and beyond. It is imperativethat the information and communication technologies (ICT) underpinning the mentioned
policy areas be aligned in order to interoperate reliably in a single information space. The
project GEOSS, INSPIRE and GMES an Action in Support (GIGAS) contributes to thisaim by promoting the coherent and interoperable development of the GMES, INSPIRE
and GEOSS initiatives through their concerted adoption of standards, protocols, and open
architectures.
This document is one of the tools that the GIGAS consortium developed to examining therequirements, architectures and standards applied in the systems in order to provide anevaluation of them in terms of business, enterprise, information and engineering andtechnology architecture, as well as their strategic alignment. It has proven to be useful for
analysing and comparing different systems and identifying areas of convergence,technology and interoperability gaps and as a tool for the technical dialogue acrossdifferent user communities.
This document has been written on the basis of a methodology developed within the
GIGAS Support Action financed by the European Commission in order to address theconvergence of global initiatives like GEOSS and the European interoperability
initiatives developed in the context of the GMES programme like HMA - Heterogeneous
Missions Accessibility and the INSPIRE spatial data infrastructure legislation.
The methodology has been applied in the GIGAS project for a parallel analysis of
GEOSS, INSPIRE, GMES, FP 6/7 projects and standardisation bodies, see [RD2] and[RD15].
2Compliance

Not Applicable.
3

Normative references

The following normative documents contain provisions that, through reference in thistext, constitute provisions of this document. For dated references, subsequent
amendments to, or revisions of, any of these publications do not apply. For undated
references, the latest edition of the normative document referred to applies.

2OGC 10-028r1
3.1

Reference Documents

RD 1. Reference Model for the ORCHESTRA Architecture (RM-OA) V2 (Rev 2.1)
OGC 07-097
RD 2. GIGAS Technology Watch Report Architecture TN, v104
RD 3. OASIS Reference Model for Service Oriented Architecture 1.0. Committee
Specification 1, 2 August 2006. http://www.oasisopen.org/committees/download.php/19679/soa-rm-cs.pdf
RD 4. SANY Sensor Service Architecture (SensorSA) V2, SANY Deliverable 3.2.2, tobe published at http://sany-ip.eu
RD 5. HMA Architectural Design Technical Note, HMA-DD-DAT-EN-001, Issue 1.7,
14/09/2007
RD 6. ISO-IEC 10746-1/2/3 Information technology, Open Distributed Processing,
Reference model
RD 7. ECSS-E-ST-10-06C 6 March 2009 Space engineering -Technical requirements
specification
RD 8. HMA Requirement Baseline Document, HMA-RS-ASU-SY-0001 Issue 1.6
RD 9. Reference Architecture for Space Data Systems Draft Recommended Practice
CCSDS 311.0-R-1
RD 10. HMA Scenario Technical Note, HMA-TN-ASU-SY-001, Issue 1.8
RD 11. Information technology — Open distributed processing — Use of UML for ODP
system specifications ( ITU-T Recommendation X.906 | ISO/IEC 19793:2008 )RD 12. 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)
RD 13. COMMISSION REGULATION (EC) No 1205/2008, of 3 December 2008,
implementing Directive 2007/2/EC of the European Parliament and of the Council as
regards metadata
RD 14. COMMISSION REGULATION (EC) No 976/2009 of 19 October 2009
implementing Directive 2007/2/EC of the European Parliament and of the Council as
regards the Network Services (Discovery and View)
RD 15. GIGAS Comparative Analysis TN, v101
3.2

Web References[WR1]. GIGAS public website
Copyright © OGC 2010www.thegigasforum.eu
3

OGC 10-028r1[WR2]. GMES public website

www.gmes.info[WR3]. INSPIRE public website

inspire.jrc.ec.europa.eu[WR4]. GEO public website

earthobservations.org[WR5]. HMA public website

wiki.services.eoportal.org[WR6]. ORCHESTRA project websitewww.eu-orchestra.org[WR7]. SANY project public website

www.sany-ip.eu

4

Terms and definitions

Not Applicable
5

Conventions

5.1

Abbreviated terms

CEN

Comité Européen de Normalisation

DGIWG

Digital Geospatial Information Working GroupEO

Earth Observation

FIG

Fèdèration Internationale des Gèometres

FP

Framework Program

GEOSS

Global Earth Observation System of Systems

GIGAS

GEOSS INSPIRE and GMES Action in Support

GMES

Global Monitoring for Environment and Security

ICT

Information and Communication Technology

IEEE

Institute of Electrical and Electronics Engineers

IETF

Internet Engineering Task Force

INSPIRE

Infrastructure for Spatial Information in the European Community

ISO

International Organization for Standardization

IT WG

Interoperability Tools Working Group

4

OGC 10-028r1

OASIS

Organization for the Advancement of Structured Information Standards

OGC

Open Geospatial Consortium

RASDS

Reference Architecture for Space Data Systems

RM-OA

Reference Model ORCHESTRA Architecture

RM-ODP

Reference Model Open Distributed Processing

RST WG

Refine Scope & Target Working GroupSANY

Sensor ANYwhere

SIF

Standards Interoperability ForumTBC,

To Be Completed

TBD,

To Be Defined

TBV

To Be Verified

TDWG

Taxonomic Database Working Group

UML

Unified Modeling Language

W3C

World Wide Web Consortium

Copyright © OGC 2010

5

OGC 10-028r1

6

Methodology objectives

The proposed methodology has been developed taking into account a certain number ofhigh level objectives all aiming at ensuring that convergence efforts are directed towards
consistent objectives.
The proposed methodology shall
1. empower each community with a neutral tool for comparison and convergence
2. require limited resources for its use and exploitation
3. allow a critical analysis to be performed by the initiative owners both atmanagement and technical level so that decision makers can be involved in theprocess
4. be scalable as what concerns the number of systems and initiatives addressed
5. allow to analyse and compare the objectives and business models of systems andinitiatives,
6. allow to analyse high level requirements, scenarios and use cases,
7. provide an identification of interoperability gaps, areas of possible convergence
8. be tuned towards high level analysis and identification of areas of convergence the design of the architectures of the contributing initiatives is outside the scopeof this methodology
9. be based on the re-use of well known and proven methodologies
As a consequence of the above high level objectives and on the basis of experience themethodology has been based on the re-use for analysis and comparison purposes (i.e. notfor system design) of the well known Reference Model for Open Distributed Processing(RM-ODP).
As an example, the applicability of the proposed methodology within the GEOSS context
is twofold;within the GEO Architecture Data Committee (ADC) it may be exploited toperform a characterization and high level analysis of the architectures of theinitiatives and systems contributing to GEOSS thus allowing a more effective
discussion on convergence issues and remedies to identified gaps
within the Standards Interoperability Forum (SIF) the methodology can be
exploited to perform a more in depth analysis of interoperability gaps and issues,

6

OGC 10-028r1

possible areas of convergence and opportunities for harmonisation either among
the standards or the communities adopting them.

Copyright © OGC 2010

7

OGC 10-028r1

7

Description of Convergence Process

The convergence process addressed by this methodology consists of the following steps:
Identification of convergence objectives
Technology Watch
Comparative Analysis
Convergence Management

Figure 1 Process Overview

The identification of convergence objectives is mainly a collection of the high level
requirements aiming to identify the interoperability opportunities among the systems

8

OGC 10-028r1

under analysis. The goal is to refine the scope and targets of the activity. The activity
involves the so-called stakeholders and user communities (e.g. users or customers ordesigners or owners etc.) of the systems under analysis, providing their inputs based on
their needs.
The Technology Watch consists of a parallel monitoring of the target systems in termsof requirements, standards, services, architecture, models, processes and the consensus
mechanisms with the same elements of the other systems under analysis.
The Technology Watch will be based on a study using the RM-ODP methodology andthe related five viewpoints.
Technology watch is followed by a Comparative Analysis on solutions, requirements,
architecture, models, processes and consensus mechanisms of the analysed systems.
The result of the Comparative Analysis will include:
A set of conclusions summarising the result of the study including theidentification of technological gaps among the target systems to be explored;
A list of recommendations/issues for the target systems to be expanded andprocessed in depth in a possible following Convergence Management phase;
An analysis on the schedules of the target systems with Identification of key
milestones or intervention points, in order to match the necessary deadlines, toprovide timely inputs and to receive timely outputs.
Technology Watch and Comparative Analysis result are presented into a technical note.
The Convergence Management is the phase of outreach and possibly shaping. The
results of the analysis mainly in terms of recommendations and issues are made public
and the target systems and stakeholders are addressed. This phase is out of the scope of
this methodology.
The above process may be repeated in several iterations.

Copyright © OGC 2010

9

OGC 10-028r1

8

Methodology

8.1

Overview

8.1.1

Introduction to RM-ODP

The RM-ODP (ISO/IEC 10746-1:1998) [RD6] is an international standard forarchitecting open, distributed processing systems. It provides an overall conceptual
framework for building distributed systems in an incremental manner. The viewpoints of
the RM-ODP standards have been widely adopted: they constitute the conceptual basis
for the ISO 19100 series of geomatics standards (normative references in ISO
19119:2005), and they also have been employed in the OMG object management
architecture.
In addition to the viewpoints, RM-ODP defines a language for each of the viewpoints.
This methodology is not using the RM-ODP Languages. Consideration will be given to
the use of UML in the various viewpoints.
The RM-ODP approach has been used in the design of the OpenGIS Reference Model(OGC 2003) with respect to the following two aspects:
It constitutes a way of thinking about architectural issues in terms of fundamental
patterns or organizing principles, andIt provides a set of guiding concepts and terminology.
Systems resulting from the RM-ODP (called ODP systems) approach are composed ofinteracting objects whereby in RM-ODP an object is a representation of an entity in thereal world. It contains information and offers services.
Based on this understanding of a system, ISO/IEC 10746 specifies an architectural
framework for structuring the specification of ODP systems in terms of the concepts ofviewpoints and viewpoint specifications, and distribution transparencies.
The viewpoints identify the top priorities for architectural specifications and provide aminimal set of requirements—plus an object model—to ensure system integrity. They
address different aspects of the system and enable the ‗separation of concerns‘.
Five standard viewpoints are defined:
The enterprise viewpoint: A viewpoint on the system and its environment that
focuses on the purpose, scope and policies for the system.
The information viewpoint: A viewpoint on the system and its environment that
focuses on the semantics of the information and information processing
performed.
The computational viewpoint: A viewpoint on the system and its environment thatenables distribution through functional decomposition of the system into objects
which interact at interfaces.

10

OGC 10-028r1

The engineering viewpoint: A viewpoint on the system and its environment that
focuses on the mechanisms and functions required to support distributed
interaction between objects in the system.
The technology viewpoint: A viewpoint on the system and its environment that
focuses on the choice of technology in that system.
The distributed aspect of an ODP system is handled by the concept of distribution
transparency. Distribution transparency relates to the masking from applications thedetails and the differences in mechanisms used to overcome problems caused by
distribution. According to the RM-ODP, application designers simply select which
distribution transparencies they wish to assume and where in the design they are to apply.
The RM-ODP distinguishes between eight distribution transparency types. These
distribution transparencies consider aspects of object access, failure of objects, locationof objects, as well as replication, migration, relocation, persistence and transactional
behaviour of objects.
More recently than the initial publication of RM-ODP, the ISO 19793:2008 standard has
been published addressing how to use UML with RM-ODP [RD11]. ISO/IEC 19793
applies UML as an alternative to the viewpoint languages in the original ISO
10746:1998. The ISO 19793 UML is an improvement over the ISO 10746 viewpoint
languages. The UML for RM-ODP are useful for the methodology purposes but will not
be used directly. The UML for RM-ODP does improve our understanding and use of the
RM-ODP viewpoints. In particular two of the summary descriptions from ISO/IEC
19793 are useful for the methodology (See Figure 2):
The engineering viewpoint addresses: "Solution Types and Distribution Infrastructure required to support distribution"
The technology viewpoint addresses: "Implementation - System hardware andsoftware and actual distribution"

Copyright © OGC 201011

OGC 10-028r1

Figure 2 RM-ODP Viewpoints from ISO/IEC 19793

The RM-ODP has been used in the FP6 ORCHESTRA Project [RD1] and in theHeterogeneous Mission Accessibility Project [RD5].
The RM-ODP including the UML version has been used in the GEOSS Architecture
Implementation Pilot.
8.1.2

Mapping of RM-ODP to the Methodology

An RM-ODP-based approach has been selected as a structural framework for theTechnology Watch step of this methodology. The reason for this choice is as follows:
RM-ODP is currently popular and widely used i.e. most of the systems to beanalysed and compared may already be based on RM-ODP,
it supports aspects of distributed processing,it aims at fostering interoperability across heterogeneous systems, andit tries to hide as much as possible consequences of distribution to systems
developers.
However, as most of the systems to be considered have the characteristic of a looselycoupled network of systems and services instead of a ―distributed processing system
based on interacting objects‖, the RM-ODP concepts are not followed literally, theyrather have to be interpreted and tailored for the purpose. For instance, most of theconcepts of the architectures under consideration are not specified in terms of the RM-

12

OGC 10-028r1

ODP distribution transparencies as these are specified in terms of interacting objects
instead of interacting services.
The usage of RM-ODP for Technology Watch is two-fold:
1. Architectural analysis: It is used as a common structural means to describe themajor architectural characteristics of the projects and initiatives underconsideration. This approach enables a comparison and a synopsis of the different
architectures on a high level. It is performed for systems of systems, projects andinitiatives. Its purpose is to identify possibilities but also major obstacles forinteroperability. Furthermore, it identifies the major use cases to be analysed in
more detail.
2. Component Implementation Analysis: It is used as a structural means to describe
how selected use cases of the projects and initiatives are implemented in the
different architectures. This second application of the RM-ODP enables acomparison and a synopsis on a more detailed level. Its purpose is to identify
technological gaps and concrete problems of interoperability. It is therefore
performed only for selected use cases such as access control or the discovery ofservices.
An example of GEOSS architectural analysis is presented in annex 2.
The following table contains a mapping of the RM-ODP viewpoints to the methodology
elements. In detail:The first column provides the original RM-ODP definitions of the viewpoints.
The second column indicates the mapping of the viewpoints to the technology
watch and their interpretation for the next comparative architectural analysis.
The third and fourth columns provide examples of what will be defined in the
viewpoints.

Copyright © OGC 201013

OGC 10-028r1

8.2

Identification of Convergence Objectives

The RM-ODP based analysis is assumed to start after a preliminary activity ofidentification of convergence objectives. This activity is expected to lead to a collectionof high level interoperability requirements.
These requirements shall be collected from the analysis of the technical baselines of thesystems under analysis and from the user needs of the stakeholders and user communitiesof the systems under analysis.
In addition a key element will be the expertise of the analysis team and the know-how on
the systems and on the relevant interoperability issues.
The identification of convergence objectives aims to select candidate/possible situations
where
Elements/components/aspects show similarities among the different systems
allowing an interoperability with (limited) changes
Aspects of single systems with interoperability barriers towards the other systems
which can be removed or bypassed with minor or major effort yielding significant
benefits
A preliminary analysis based on a set of criteria should lead to identify the most attractive
features/aspects to be analysed in the next RM-ODP study phase. Candidate criteria are:Cost-benefit trade-off
Consider the benefits deriving from the enhanced interoperability with respect tothe estimated effort necessary to implement the (technical) solutions needed forremoving or reducing the existing interoperability gaps and barriers.
GovernanceEvaluate the possibility of influencing the systems with the proposed solutions;take into account the level of support provided by the entities governing thesystems.
Analysis team know-how
Select features/aspects which are well known inside the analysis team, with one ormore partners having a solid and consolidated background and expertise acrossdifferent systems, aiming to arrive to successful interoperability solutions.
Schedule
Evaluate if the solutions match with the internal schedule of the systems, i.e. if
there are opportunities to frame the outputs into relevant milestones of thesystems. E.g. if a system is going to choose a standardisation decision at a certain
date, the analysis team may try to propose a solution in time to be adopted by thetarget system.
Previous feedbacks

14

OGC 10-028r1

Consider how the systems have taken into account (e.g. immediate adoption,
rejection, discussion and next adoption with minor/major modifications etc)
previous inputs coming from different sources. Sort the features/aspects giving apriority to those which are envisaged to be accepted by the systems.
Long term perspective and global scenario
Try to understand and/or to guess what is happening at global level and what isgoing to happen not only in the near future but also in the mid-term and in thelong term. Try to prioritise features/aspects leading to solutions with expectedlong term validity. See what happens in other initiatives at world/global level andthe general trends in standardisation bodies.
A further effort (if needed/relevant) shall lead to the definition of other requirements,
filling gaps and completing the picture (e.g. performance, security, safety, operational,
quality).

Copyright © OGC 201015

OGC 10-028r1

8.3

Technology Watch

8.3.1

Overview

The following sections describe how to collect and organize information from thesystems under analysis using the RM-ODP.
The critical analysis of the high level Interoperability requirements extracted at theprevious step aims to drive a study made in parallel on the different systems identifyingarchitectural issues or solutions supporting the scenario in terms ofremoving interoperability barriers,
facilitating convergence,leading to standardisation.
In most cases a complete architectural design is not requested and a basic study
identifying key aspects, solutions and design choices is expected.
A key aspect should be surveying the technologies of the selected looking for similarityand differences. Of particular interest will be when systems have similar requirements but
have chosen differing technologies that prevent interoperability.
In order to perform a proper survey it is recommended to perform an intermediate step ofterminology harmonisation.
The editors are expected to provide contributions to the analysis documents accordingwith the templates described into the following sections and they shall reflect thestructure of annex 2 of this document, with the same sub-sections and the same
framework.
The RM-ODP study shall be made with the aim to provide an output to be compared withsimilar studies on other initiatives/projects.
As a general rule the RM-ODP study of a system shall be focused on interoperability
aspects with the other initiatives.
The example in annex 2 shall be used as a valid input in terms of which structure is
expected and what kind of information shall be provided in each section.
The document contributions shall be organised according the five viewpoints of the RMODP, i.e.
Enterprise viewpoint,
Information viewpoint,
Service viewpoint
Engineering Viewpoint
Technology Viewpoint

16

OGC 10-028r1

The sections for each viewpoint shall be prepared using
the criteria outlined into the following sections ―objectives‖
the templates specified into the following sections ―documentation‖.
The example in annex 2, both in terms of structure and contents, shall be a valid supportand starting point for the analysis.

Copyright © OGC 201017

OGC 10-028r1

Information

EnterpriseViewpoint
Name

Definition according
to ISO/IEC 10746 &ISO/IEC 19793

Mapping to the technology watch
and comparative analysis

Examples for theArchitectural Analysis

Examples for theComponent
Implementation Analysis

Concerned with the
purpose, scope andpolicies governing theactivities of thespecified system
within the organizationof which it is a part.

Refers to the application domain, thesupporting initiative and/or
stakeholders, the purpose and scope of
the architecture, the major design
constraints (system requirements andarchitectural principles) and user
requirements.

Mission of GEO initiative

INSPIRE Metadata
Regulation
INSPIRE Network Services
Regulation for Discovery
and View

Includes policies and rules that govern
actors and groups of actors, and theirroles.

Concerned with thekinds of information
handled by the systemand constraints on theuse and interpretationof that information.

Summarise the modelling approach of
all categories of information thearchitecture deals with including their
thematic, spatial, temporalcharacteristics as well as their
metadata.
Provide the list of standard andproprietary information models thatare applied.

INSPIRE Directive
Terms of Reference for thedevelopment of INSPIRE
Annex II and III data
specifications

Security policy for aselected GMES service

Environmental Risk
Management as theapplication domain of
ORCHESTRA
Application of the ISO/OGC
General Feature Model as
information meta-model
Appliance of a Modeldriven Architecture (MDA)
approach starting with UML
and a defined mapping to
XML schema.

Application of an ebRIM
extension package as metainformation schema of an
OGC Catalogue Service
Specification of access
control permissions in
XACML

Computational

Application of the
Observation andMeasurement model (OGC
06-022r1)
Concerned with thefunctional
decomposition of thesystem into a set ofobjects that interact atinterfaces – enabling
system distribution.

Referred to as “Service Viewpoint”
Summarise the modelling approach ofInterface and Service Types.
Provide the list of standard andproprietary interface and service
specifications.
Organise them in a service/interface
taxonomy.

18

Service meta-model of RMOA (OGC 07-097)

Reference to the OGC
Catalogue Service used

List of OGC Sensor Web
Enablement services
specified by the SANY andthe OSIRIS projects.

List of services supporting
the implementation ofaccess control.

Classified into the ISO
19119 Service Taxonomy

OGC 10-028r1

Engineering

Viewpoint
Name

Definition according
to ISO/IEC 10746 &ISO/IEC 19793

Mapping to the technology watch
and comparative analysis

Concerned with theinfrastructure required
to support system
distribution.

Component Types: allocation
services and data allocatedcomponent types.

Solution Types andDistribution Infrastructure required
to support distribution"

Dynamic:
diagrams

Concerned with the
choice of technology
to support system
distribution.

Use

cases

of
to

interaction

Description
ofthedistributed
computing environment that supports
the interaction between component
instances
Engineering policies: defining a set of
relevant aspects that we are interested
to, e.g. Access control, security, etc.)
Component instances that implement
the component types from theEngineering Viewpoint.
Products that implement thecomponent instances.

Technology

Standardisation process used in theinitiative in order to develop the RMODP design in accordance withinternational standards.

Examples for theArchitectural Analysis

Examples for theComponent
Implementation Analysis

Identification of Component
types for each initiative

Identify the component
types involved in the usecase including the services
and information types
deployed by the components
to meet the use case.

Description of thecomponents in terms ofservices from the service
viewpoint and informationfrom the information
viewpoint.
Characterise service
platforms according to the
OASIS SOA Reference
Model

Sequence diagram to show
the coordination of activities
between the components
needed to meet the use case.

The service viewpoint
describes a catalogue
service, e.g., CSW, that is
deployed in a community
catalogue component type;the Technology viewpoint
lists instances of thecomponent and the products
used, e.g., FEDEO
Clearinghouse and
GeoNetwork V2.0, ESRI
ArcGIS,
Description of the
deployment environment forcommunications: internet,
satellite broadcast, mediadeliveryDescription of how the
GEOSS SIF process.

Table 1 Mapping of the RM-ODP Viewpoints to methodology

Note: In order to highlight the fact, that the architectures under consideration haveoften the nature of a loosely-coupled distributed system based on networked services
rather than a distributed application based on computational objects, the“computational viewpoint” is referred to as “service viewpoint” in the methodology.
Note: The use of RM-ODP shall be tailored in order to take into account that each of
the systems is predominantly, but not exclusively SOA. For example the GEOSS
architecture includes data delivery by broadcast and by media.
CCSDS has produced a tailoring of the RM-ODP for space data systems, the Reference
Architecture for Space Data Systems [RD9]. RASDS provides guidelines for thedescription of space data systems that take into account the realities of operating in thespace environment. RASDS directly addresses the fact that some elements of these
Copyright © OGC 201019

OGC 10-028r1

distributed systems will be operated at great distances from one another with one-way
light times measured in tens of minutes or hours, not milliseconds. These elements may
only occasionally be in contact with one another, typically require use of very expensive
and over-subscribed ground communications assets, and are strongly affected by thephysical environment in which they have to operate. These environmental issues affectwhat must be done to provide reliable communications between elements, how control
interactions may be designed, and how these systems may be operated.
In addition, Annex 5 contains a mapping of the RM-ODP viewpoints on the GEO AIP
viewpoints.
8.3.2

Enterprise Viewpoint

8.3.2.1

Objectives

The Enterprise Viewpoint shall focus on the purpose, scope and policies of the system
under analysis.
The Enterprise Viewpoint represents the system in the context of the businessenvironment in which it operates. It is represented by a community of enterprise objects
and by their roles (e.g. users, owners and providers of information).
The Enterprise Viewpoint starts with the critical analysis and the refinement of the highlevel interoperability requirements identified by the previous phase. The rules specified in
Annex 3 for writing requirements are a valid support for the successful result of thisactivity.
In addition, the chosen approach for enterprise viewpoint is to apply use cases as amodelling tool. The concept of use case is adopted from the UML modelling approach.
For each system under analysis create one or more interoperability use cases.
The use case shall:describe the behavior of the initiatives,
identify external actors/interfaces,
be focused on interoperability issues.
The following topics should be tackled by the use case description, selecting those which
are relevant for the scenario under analysis
Customer identification and needs, high level objectives & requirements
Which are the external actors of the scenario, in particular the final targets of theservice/data; which are their requirements at user level.
Architecture & Interoperability Barriers
Identify specific architecture solutions or issues relevant for the interoperability
scenario; identify barriers preventing or reducing interoperability.
Operational Concepts

20

OGC 10-028r1

Identify any operational issue or constraint which may affect the interoperability
scenario.
Standards, Maturity, Planning, Strategy for Implementation/take-up
Make an inventory of the existing standards relevant for the scenario, evaluate
their completeness and maturity, as well as their or weak points; analyse theirdiffusion, scope and applicability; identify areas needing a (further)standardisation and sketch a possible plan and/or a strategy for implementation or
take-up at the relevant levels.
IPR, Data Policies, Identity Management, Information Security,
Dealing with interoperability of large systems/systems of systems it is ofparamount importance the analysis of issues affecting IPR and data policies aswell security issues in terms of user/identity management and information
security.
Test Conformance,
Identify any issue related to conformance testing, the need of a conformance test
platform, i.e. a persistent testbed, consider sustainability and governance. In caseof standardisation extend the concept of conformance testing to certification.
Governance.
Analyse any aspect of governance also in the perspective of a future shaping.
8.3.2.2

Documentation

The enterprise viewpoint section of the document shall consist of the following
subsections:
Summary Table: a description the system under analysis to be provided using thetable in Annex 2.1, which is self explanatory and provides a top level description.
The summary table is significant for analysis on systems or systems of system; it
is not mandatory for studies at subsystem or component level.
Context: A description of the overall context,
The list of the high level (interoperability) requirements,
The identified interoperability use cases described with the tables based on thetemplate in annex 1.
8.3.3

Information Viewpoint

8.3.3.1

Objectives

The Information Viewpoint shall describe any data/metadata relevant for the scenario
under analysis with a parallel view of what happens in the different initiatives.

Copyright © OGC 201021

OGC 10-028r1

The Information Viewpoint summarises the modelling approach of all categories of
information the architecture of a given project or system deals with. This includes theway how information models are specified, i.e. the set of rules and the notation that isused in order to define information objects and their relations among them. Sometimes
this approach is summarised as a meta-model for information. An example of such ameta-model is the General Feature Model (GFM) as specified in ISO 19109 and appliedin the OGC Reference Model (OGC 03-040).
The resulting information models (sometimes also called application schemas) include
object types (in the GFM called feature types) that include thematic, spatial, temporalcharacteristics as well as their meta-data. It shall be distinguished between models on the
abstract or on concrete service platforms (to be described in the technology viewpoint).
8.3.3.2

Documentation

The information viewpoint of the system under analysis shall be provided by
Identifying the list of information models of the initiative/project which are
relevant for the interoperability scenario under investigation
describing each information model with the same tables in Annex 2.2.
The editor shall provide a description in terms of information models of his system withthe same type of information present in the example in the annex.
The information modelling approach of a project/initiative shall be analysed according to
the following list:
model namecategoryo One of the following categories shall be used22

meta-model for information (e.g. the OGC General Feature
Model), i.e. guidelines and rules how to specify information
models resp. application schemas

meta-model for services (e.g. the ORCHESTRA Service metamodel), i.e. guidelines and rules how to specify services andinterfaces

basic model, i.e. generic application schemas that need refinements
for a specific application domain. Example: OGC Observations &Measurements Model

thematic model, i.e. an application schema for a particularapplication domain (e.g. forest fire risks), built according to themeta-model for information

meta-information model, i.e. the model used for expressing metadata/meta-information. Example: ISO 19115 or ISO 19119

OGC 10-028r1

reference to specificationo reference to a document (if applicable)
standard referenceo reference to a standard (if applicable)
description
o purpose of the modelo list of the major object types
formato specify the model in terms of format, (e.g. the following are examples offormats to be used UML, XML, OWL, database schema, textual etc.)
comment
In addition UML diagrams may be provided on a case by case basis in order to complete
the picture.
8.3.4

Service Viewpoint

8.3.4.1

Objectives

The Service Viewpoint summarises the modelling approach of the Interface and Service
Types. This includes the way how interface and service models are specified, i.e. the setof rules and the notation that is used in order to define services. Sometimes this approachis summarised as a meta-model for services. An example of such a meta-model is themeta-model for services as specified in the Reference Model for the ORCHESTRA
Architecture (RM-OA) [RD1].
The resulting service models include the interfaces of the services, their operations aswell as operation parameters and exceptions. Furthermore, it encompasses metainformation about the services, e.g. OGC capabilities It shall be distinguished between
services on the abstract or on concrete service platforms (to be described in thetechnology viewpoint).
8.3.4.2

Documentation

The service viewpoint of the system under analysis shall be provided by
Identifying the list of services of the initiative/project which are relevant for theinteroperability scenario under investigation
describing each service with the same table used in Annex 2.3.
The partner shall provide a description in terms of services of his project/initiative withthe same type of information present in the example in the annex.

Copyright © OGC 201023

OGC 10-028r1

Before listing the service and interface types, it shall be specified
if and if yes, which service meta-model is being used, i.e. which models and rules
are applied for the specification of services and interfaces.
Example: Reference to ―W3C Web Service Architecture‖ or ―OASIS Reference
Model for Service Oriented Architecture 1.0‖ or ―Reference Model for the
ORCXHESTRA Architecture (RM-OA) OGC 07-097‖
if and if yes which service taxonomy has been applied for the project/initiative.
Example: ISO 19119 Service Taxonomy or SANY Functional Domains
The services of a system shall be analysed according to the following list of items:
name of service or interface type
Geographic Service Categoryo One of the following categories shall be used

Geographic human interaction services



Geographic model/information management services



Geographic workflow/task management services



Geographic processing services



Geographic processing services – spatial

Geographic processing services – thematic

Geographic processing services – temporal

Geographic processing services – metadataGeographic communication services



Geographic system management services

positioning in the project service taxonomy according too ISO 19119:2005 Geographic Information Services
o service category (e.g. as in ORCHESTRA)o project-specific service taxonomy (if applicable, see above)
standard referenceo reference to a standard (if applicable)
description
o purpose of the service (max. 50 words)
format of interface specification

24

OGC 10-028r1

o specify the service in terms of interface format, (e.g. the following are
examples of formats to be used UML, WDSL, Java, textual etc.)
comment
8.3.5

Engineering Viewpoint

8.3.5.1

Objectives

The Engineering Viewpoint focuses on the mechanisms and functions required to support
distributed interactions between resources (e.g. services) in the system.
The engineering viewpoint of each system shouldallocate services and data to component types and instancelist all those major architectural features for which there is a defined workflow,
policy or service interaction model and model them in UML sequence diagrams.
The Sequence Diagrams model the systems and their external interfaces exchanging
messages according with the interoperability schema under analysis.
8.3.5.2

Documentation

In the tailoring proposed by this methodology (see annex 2.4) the Engineering Viewpoint
is assumed to describe:
Component Types: allocation of services and data allocated to component types.
Description of the distributed computing environment that supports the interaction
between component instances
Engineering policies: defining a set of relevant aspects that we are interested to, e.g.
Access control, security, etc.). Their dynamic behaviour may be described in terms of use
cases and service interaction diagrams, e.g. as UML sequence diagrams.
Implementation Architecture: defining the architecture of the system and how the
instances of the component types are allocated and implemented.

8.3.5.2.1

Component Types

This viewpoint describes how the mapping of abstract service specifications andinformation models to the chosen component types.
The component types define the packaging approach for deployment. Systems have insome cases already defined component types so this viewpoint provides a description of
those components by abstracting the implementation details and focusing on theinterfaces and information content.

Copyright © OGC 201025

OGC 10-028r1
8.3.5.2.2

Distributed Computing Environment

This section describes the distributed computing environments used in the systems. In
case of a service-oriented environment it describes the choices of the service platforms
with their major characteristics (e.g. architectural styles).
As a general guideline, the specification of a service platform shall be conformant to the
OASIS Reference Model for Service Oriented Architecture 1.0 [RD3]. This implies thatthe platform is being described according to the SOA-RM by the following predefined
platform properties (examples for a W3C Web Services platform as applied in the SANY
Integrated Project [RD4] are given for the individual properties, respectively):
Platform Name
Name of the platform and if applicable the exact version number of the platform
specification.
In the case of a standard platform, a reference shall be provided.
Example: “W3C Web Services Platform” following the Web Service infrastructure as
defined by the W3C specifications
Reference Model
If the platform specification is based on a specific reference model, the name and theexact version number of the reference model shall be provided.
Example: W3C Web Services ArchitectureInterface Language
Specification of the formal machine-processable language used to define Service
Interfaces. In the case of a standard language, a reference shall be provided.
Example: Web Service Description Language (WSDL), Version 1.1
Execution Context
Specification of the Execution Context. The Execution Context is an agreement between
service providers and consumers. It contains information that can include preferred
protocols, semantics, policies and other conditions and assumptions that describe how aservice can and may be used. This includes, for example, the specification of thetransport and the security layer, the format of the messages exchanged between service
providers and consumers, etc. In the case of a standard Execution Context, a reference
shall be provided.

Example: The execution context of the W3C Web Services Platform is defined by
the following properties:
Transport Protocol and Message Format:
SOAP 1.2 HTTP binding as defined in SOAP Part 1: Message
Framework, Version 1.2 and Hypertext Transfer Protocol (HTTP),
Version 1.1. The message style that shall be used is document/literal
non-wrapped since it is the most widely accepted and interoperable
26

OGC 10-028r1

message style.
Security
Session Information: The transport of session information may be
accomplished by using platform specific mechanisms, for example theinclusion of a session key in the SOAP header.
Encryption: Optional encryption of SOAP messages shall beaccomplished by Web Services Security: 4 SOAP Message Security 1.1.
Schema Language
Specification of the schema language used to define Information Models.
Example: Extensible Markup Language (XML) 1.0
Schema Mapping
Specification of how to map the abstract level (UML) to the schema language used forthis particular platform (if applicable).
Example: ISO 19136 for GML

8.3.5.2.3

Engineering policies

This section is expected to define the engineering policies applied on a set of relevant
aspects that we are interested to.
The engineering policies describe rules, constraints, recommendations or (real-life)
examples of service interactions in order to fulfil a given task, e.g. access control for
operation calls, or monitoring of services. All these policies must rely upon specifications
provided in the Information and/or Service Viewpoint.
These specifications may be
abstract (i.e. platform-neutral) or
concrete (i.e. platform-specific)
depending on the level of abstraction to which the system/component/architecture
specification belongs to.
For instance, a project and/or an initiative may define policies for the following aspects(non-exhaustive list):
resource discovery
service monitoring and management
access control
processing of quality information

Copyright © OGC 201027

OGC 10-028r1
event generation and handling

The Engineering Viewpoint shall describe any processing relevant for the engineering
policies, preferably if available in UML sequence diagrams. An example is a defined
workflow for access control or for the discovery of services based onregistries/catalogues. Each policy of the enterprise viewpoint shall be expanded into one
or more sequence diagrams detailing the interactions among the actors.
Sequence Diagrams model the initiatives and their external interfaces exchanging
messages according with the interoperability schema under analysis, with a parallel viewof what happens in the different initiatives.
The focus shall be on the Interoperability aspects to be modelled, identifying barriers but
also commonalities
If necessary other type of information can be provided as integration in order to provide amore complete picture.
8.3.5.2.4

Implementation ArchitectureThis section describes concrete arrangements of component types following theengineering policies and based upon component implementations and the run-timeenvironment identified and described in the Technology Viewpoint.
The rationale of this section is to describe how the component types are combined into asystem architecture in order to implement data and services/operations described into
information and service viewpoints.
For clarity sake, Section "Component types" lists and describes each type of component
one by one; section "Implementation architecture" describes how the building blocks(component types) are assembled and perform the interactions described into the section"Engineering policies".
Note that this section may be empty if a project or and initiative stays on an abstractarchitectural level. An alternative in this case may be to describe an implementationarchitecture of a pilot application as an example.
8.3.6

Technology Viewpoint

8.3.6.1

Objectives

The technology viewpoint of the system under analysis shall be provided by defining
the run time environment
the status of the standardisation process (if any)

28

OGC 10-028r1
8.3.6.2

Documentation

The Technology Viewpoint deals with the following items relevant for theinteroperability scenario:
Component Implementation
Run-time environment
Deployed Service Instances and Service Networks.
Standardisation processes.
The editor shall provide a description in terms of technology baseline of his
project/initiative with the same type of information present in the example in the annex
2.5.
8.3.6.2.1

Component Implementation

This section shall give implementation details on the components types identified into theengineering viewpoint. Details include:
The tools that support the implementation of the component types;
The products that provide implementations of the component types.
8.3.6.2.2

Deployed Service Instances and Networks

This section contains the listing of the service instances and service networks deployedby the Initiatives. A service network is hereby considered as a set of service instances(also called a domain) that follows a common set of engineering policies as defined in
section 8.3.5.2.3
8.3.6.2.3

Run-time environment

This section shall provide information about the software components (e.g. productname) that is being used as the run-time environment for the service instances and service
networks.
Examples: EJB Application Server for services, ESA SSE for the client applications.
The relevance of the run-time Environment on the scope of the activities will be
evaluated on a case by case basis.
8.3.6.2.4

Standardisation ProcessThis section shall provide information about past, ongoing or planned standardisation
activities of a project or an initiative. The list shall be concrete in the sense that it may be
officially referenced as a new work item, discussion paper, draft specification,
recommendation, request for comment, depending on the rules of the standardisation
body, respectively. Each item in the list shall include the date of the original submission
and the current status accompanied by a date.

Copyright © OGC 201029

OGC 10-028r1

8.4

Comparative Analysis

8.4.1

Overview

The comparative analysis task consists of a critical analysis of the technology watch
reports, i.e. a set of parallel analysis on the different initiatives of features andarchitecture aspects. The comparative analysis expected outputs are
A conclusion at the end of the technical note summarising the result of the study
including the identification of technological gaps and guidelines and objectives
for the harmonisation approach(optional) A list of recommendations/issues to the target systems to be expanded
and processed in depth in a future convergence management (shaping) phase; theissues are based on the analysis on the schedules of the systems in order to matchthe necessary deadlines, to provide timely inputs and to receive timely outputs.
8.4.2

Comparative Analysis Section in Technical Note

The Comparative Analysis section of the technical note consists of a synthesis of thetechnology watch studies performed for the different systems.
The section shall identify the most significant gaps and commonalities coming out fromthe technology watch describing interoperability issues and opportunities.
The section contains the following sub-sections:
Overview
A summary of the previous technology watch report activity, consisting of a short
description of the analysed systems and the most relevant issues detected.
Opportunity for Interoperability
A focus on the most significant interoperability issues coming out from thetechnology watch activity.
Comparative Analysis
A parallel analysis on the systems and on the features candidate forinteroperability. For clarity sake it is suggested to use matrixes withfeatures/systems as rows/columns for an immediate view on gaps andcommonalities. See example in table below from [RD15]
Open issues and future work items
It lists issues remaining open waiting for new studies.

30

OGC 10-028r1

Catalogue/Metadata Comparative Analysis
Information Viewpoint
FeatureDatasetMetadata(GMES term.:
Product)

GEOSS
INSPIREISO 19115:2003 is
identified as ―the‖ standard
for geospatial metadata.
Based on experiences in the
AI Pilot, it is expected that
INSPIRE Profile ofa profile for GEOSS
ISO 19115:2003
metadata will be considered
and informed by thefollowing existing profiles
and packages: ebRIM,
BASIC, CIM and EO.

Series Metadata
Same as for dataset(GMES term.:
metadata
Collection)

Service
Metadata

Specific profiles of ISO
19119:2005 and ISO
19119:2005/Amd 1:2008

GMES CDS EO-DAIL

Metadata Model &Encoding: EO Profile of
GML (OGC 06-080)
Discovery information
model: EO ebRIM EP(OGC 06-131)

Metadata Model: Profile ofISO 19115:2003 (definedin OGC 07-025)
INSPIRE Profile of Metadata Encoding: ISO
ISO 19115:2003
19139:2007
Discovery information
model: CIM ebRIM EP(OGC 07-038)
Metadata Model : Profile
INSPIRE Profile of of ISO 19119:2005/Amd
ISO 19119:2005
1:2008 (defined in OGC
and ISO
07-025)19119:2005/Amd
Metadata Encoding: ISO
1:200819139:2007
Discovery information
model: CIM ebRIM EP

Table 2 Example of Comparative Analysis table

8.4.3

Issues and recommendations

8.4.3.1

Overview

The list of issues (or recommendations) may be extracted as a final result of thecomparative analysis on the basis of a critical analysis of the technology watch reports
based on a set of criteria used.
Issues are suggestions addressed to relevant entities with the purpose of improved
interoperability.
The following types of issues are envisaged:
Revising existing specifications/standards
Perform (additional) testing on subjects
Copyright © OGC 201031

OGC 10-028r1

Further investigation about the subject
Communication
Submission for consideration as reference material
Funding
Research
Governance/Political(Other TBD)
The entities to be addressed are mainly the teams in charge of the target systems.
8.4.3.2

Criteria

The following criteria are envisaged to define issues/recommendations and to identify
priorities:
Cost-benefit trade-off
Consider the benefits deriving from the enhanced interoperability with respect tothe effort necessary to implement the solutions in the issues removing or reducing
interoperability gaps and barriers.
GovernanceEvaluate the possibility of influencing the systems with the proposed issues; take
into account the level of support provided by the entities governing the systems.
Schedule
Evaluate if the solutions specified by the issues match with the internal scheduleof the systems, i.e. if there are opportunities to frame the outputs into relevant
milestones of the systems. Consider also if the study timeframe is compatible
with the time necessary to complete or at least to start-up a successful
standardisation process or a shaping activity.
Previous feedbacks from the systems
Consider how the systems have taken into account (e.g. immediate adoption,
rejection, discussion and next adoption with minor/major modifications etc)
previous inputs coming from different sources. Sort the issues giving a priority tothose which are envisaged to be accepted by the systems.
Long term perspective and global scenario
Try to understand and/or to guess what is happening at global level and what isgoing to happen not only in the near future but also in the mid-term and in thelong term. Try to prioritise issues leading to solutions with expected long term
validity. See what happens in other initiatives at world/global level and thegeneral trends in standardisation bodies.
32

OGC 10-028r1
8.4.3.3

SyntaxThe issues/recommendations shall follow specific rules for a not ambiguous identificationand clear wording.
For the identification a possible schema is the following
REC-[topic-acronym]-[counter] [title of the recommendation]
i.e REC-CAT-001 Harmonising catalogues
In annex 4 it is presented an example of an issue/recommendation generated by the
GIGAS project in a similar context.

Copyright © OGC 201033

OGC 10-028r1

9Annexes

9.1

Annex 1 Use Case Template

Here follows a template to be used for use case compilation
Overview
Short introduction-overview of the use caseInteroperability purpose
Describe the interoperability aspect or goal addressed by the use case.
Actors, external actors and interfaces
Describe the list of actors (systems under analysis) involved in the use case,including any external actor or interface involved in the interactions and providing
inputs or receiving outputs.
Initial Status and Pre-requisites
Describe the initial status and any relevant pre-condition or requisite to be
fulfilled for the correct use case execution/evolution.
Evolution
Make a step by step description of the use case evolution, identifying any causeeffect relationship.
Final Status and post conditions
Describe the final status and any relevant post-condition or requisite to be fulfilled
after the correct use case execution/evolution.
The above elements should be mandatory for the use case compilation which can be
integrated by additional elements (e.g. UML notation, drawings..).

34

OGC 10-028r1

9.2

Annex 2 Example of Architectural Analysis: GEOSSThis annex contains the GEOSS section extracted from the GIGAS architecture TN[RD2] which contains additional descriptions of initiatives, projects and systems ofsystems using this methodology. For readability sake, the section has been reduced insize and contents. The purpose of the example is only to show the templates proposed by
the methodology and which type of information shall be provided for each section. The
validity of the contents of the example is out of the purpose of this document, for any
issue please refer to GEOSS official documents.
9.2.1

Enterprise Viewpoint

9.2.1.1

Summary Table

AspectDescription

Context

GEOSS is an intergovernmental programme, coordinated by Group on Earth Observations(GEO)

Start and End Date2005 – 2015

Home Page

http://www.earthobservations.org

Summary

In June 2009 79 countries and 56 organisations participate in the GEOSS programme. GEOSS
aims to integrate Earth Observation systems into a global system that can be applied to various
areas of environmental science and management. GEOSS is composed of a variety of systems
including those for data collection, processing, discovery and dissemination. Currently the
GEOSS programme is focussing on the following nine societal benefit areas (SBA):
Reduction and Prevention of Disasters
Human Health and Epidemiology
Energy Management
Climate Change
Water Management
Weather Forecasting
Ecosystems
Agriculture
Biodiversity

Reference toarchitecture
specification

GEOSS Architecture Implementation Pilot (AIP) Phase 2: IOC Augmentation: Version
20080626, accessible at http://portal.opengeospatial.org/files/?artifact_id=28934

Source ofRequirements

GEO member countries and participating organisations.

Business rules(model),Interoperability Arrangements ensure that the heterogeneous systems within GEOSS cancommunicate and interoperate. Data, information and service providers within GEOSS are
guided by technical specifications for collecting, processing, storing, and disseminating shareddata, metadata, and products. Interoperability arrangements in GEOSS are based on open
standards, with preference to formal international standards. Within the architecture,
Interoperability arrangements are registered in the GEOSS Standards and Interoperability

Copyright © OGC 201035

OGC 10-028r1
Registry, after assessment by SIF.
Security rules

Access control mechanisms as implemented by each service provider. For example, access to
EO-1 and SPOT imagery is controlled by the respective service providers.

Authority rules forprivileges andpermissions

Each service provider manages privileges and permissions to the resources they provide.

Resource usage rules

Users of resources are expected to abide by rules set by the service provider (for example,
copyright and intellectual property)

Transfer rules,

GEO Task DA-06-01, as the International Council for Science (ICSU), has drafted a White
Paper that provides an overview of international data sharing laws, principles, and policies.
The white paper, which shall be presented at the 5th GEO Plenary meeting in Beijing inNovember 2008, recommends a draft set of implementation guidelines for the GEOSS Data
Sharing Principles as outlined in the GEOSS 10-Year Implementation Plan.

Domain rules

Consortium coordinated by the Group on Earth Observations (GEO)

Important use cases

Practical use cases were described in the GEOSS Common Infrastructure and the Core
Architecture Implementation Report. A generic series of use cases encompassing thesepractical uses cases have been designed in considering different actors (see next paragraph)
The GEO Web Portal allows service providers to register components and services.
A user is able to discover contributed services or components through the GEO Web
PortalThe GEO Web Portal accesses the GEOSS Component and Service Registry to
retrieve metadata about contributed EO and related services.
The GEOSS Component and Service Registry references interoperability
arrangements registered in the GEOSS Standards and Interoperability Registry.
The GEO Web Portal links to GEONETCast and external community resources.
The Clearinghouse is routinely updated with contents of the Service Registry.
The GEO Web Portal, Community portals and other clients search theClearinghouse through a catalogue service interface at a frequency dependent uponuser requests
The Clearinghouse is searched through a combination of 1) harvested metadata held in a
local cache and 2) distributed searches to remote catalogues at the time of the users
searchTable 3: Enterprise Viewpoint of GEOSS

9.2.1.2

High Level Requirements

The following requirements for the GEOSS clearinghouse were recommended to be mandatory in the Core
Architecture Implementation Report:
Shall provide a catalog service interface conformant with OGC CSW 2.0.2.
Shall provide catalog client interfaces conformant with OGC CSW, ISO 23950.
Shall provide a registry for the GEOSS Community Catalog Service metadata and others.

36

OGC 10-028r1
Shall have a CSW interface to Service registries hosted at the GEO Secretariat.
The clearinghouse shall be available at least 99% of the time, i.e., approximately 7 hours of down time amonth.
Shall be hosted on a computer hosted at the GEO Secretariat which shall provide access to the Internet.
Maintenance of the content of Clearinghouse registers shall be performed by the GEO Secretariat.
Geo Secretariat to host the register with instances from the contributing organization.
Maintenance of the software of Clearinghouse shall be performed by the contributing organization.
TBC with common requirements and requirements on single GCI components

9.2.1.3

Context

GEOSS is a 10 year global programme that aims to provide to the broad environmental science and user community
decision-support tools and aid the monitoring, analysis and modelling of various environmental phenomena through the
integration of existing and future sources of earth observation information. This document presents the enterprise,
information, engineering, computational and technology viewpoints of the GEOSS Architecture.
TBC with other descriptions and diagrams describing the GEOSS context.

9.2.1.4

Use Cases

TBC List of Use Cases and actors following template in annex1

9.2.2

Information Viewpoint

AspectDescription

Model name

Observation & Measurements (O&M) model

Category

basic model

Reference tospecification

See standard referenceStandard reference

OGC Document 07-022r1, October 2007

Description

Describes a framework and encoding for measurements and observations. The aim is todefine a number of terms used for measurements, and the relationships between them. It
discusses observation, measurement, result, procedure, feature of interest, observed
property, property type, coverage and related terms,

Format

UML, XML

Comment

Model is required specifically for the Sensor Observation Service and related components ofan OGC Sensor Web Enablement capability, and also for general support for OGC
compliant systems dealing in technical measurements in science and engineering.

Table 4: OGC Observation and Measurement Model
TBC with one table for each data model as in the previous example

Copyright © OGC 201037

OGC 10-028r1
9.2.3

Service Viewpoint

9.2.3.1

Service Metamodel

AspectDescription

Service meta-model

Reference Topic 12 - The OpenGIS Service Architecture 4.3, document 02-112 , (this is
identical to ISO 19119, Actually derived from ISO 19119)
Referenced in Section 4.2.4 of Annex B of the AIP-2 CFP

Service Taxonomy

Classification of geographic services:
Geographic human interaction services
Geographic model/information management services
Geographic workflow/task management services
Geographic processing services
Geographic processing services – spatial
Geographic processing services – thematic
Geographic processing services – temporal
Geographic processing services – metadata
Geographic communication services
Geographic system management services

Table 5: Service meta-model and taxonomy

9.2.3.2

List of services

AspectDescription

Service nameCatalogue Service

Geographic Service
Category

Geographic model/information management services

Project Service
Category

None (project specific)

Reference tospecification

Annex B of GEOSS AIP-2 CFP

Standard reference

OGC Document 07-006r1 OpenGIS Catalogue Service Implementation Specification

Description

Catalogue services support the publishing and searching of collections of metadata
relating to datasets, services, and other information resources. A user or application
is able to query a catalogue service and be presented with metadata describing
resource characteristics. Catalogue services are the principal resource discovery
tools within a spatial data community. The specification allows for bindings using
CORBA, Z39.50 and HTTP. The Z39.50 binding is based on ISO 23950. The HTTP
binding of the Catalogue service specification is also known as the Catalogue
Service for the Web (CSW).

FormatXML, Z39.50

Comment

Various application profiles of CSW have been published, the following are those identified
in the AIP-2 CFP as relevant to GEOSS:

38

OGC 10-028r1

AspectDescription•

Earth Observation Application Profile of CSW•

ISO Metadata Application Profile of CSW•

ebRIM Application Profile of CSW•

BASIC package•

Cataloguing for ISO Metadata (CIM)

Table 6: OGC Catalogue Service

TBC with one table for each service as in the previous example
9.2.4

Engineering Viewpoint

GEOSS is made up of components and the components expose services. A component represents amodular part of a system that encapsulates its contents and whose manifestation is replaceable within its
environment. Components offer business functions as services. A component is modelled throughout thedevelopment life cycle and successively refined into deployment and run-time. Conceptually, component
types are design concepts that encapsulate information objects and provide services on the information
through interfaces. Component instances are developments that have been deployed and are accessible ata network address.

9.2.4.1

Component Types

The following are GEOSS component types:
Main GEO Web site: Earthobservations.org
GEO web portals: A single point of access to information, internal or external to GEOSS, relevant
to all SBAs and is of interest to various types of users
GEOSS Registry: Component and Service Registry (CSR), Standards and Interoperability Registry(SIR), GEOSS Best Practices Wiki, GEOSS User Requirements Registry
GEOSS Clearinghouse : Provides search access to high-level metadata from all catalogs
registered in the CSR through remote harvest of metadata or provision of distributed search.
Indexes all CSR entries
TBC with other GEOSS components.

9.2.4.2

Distributed Computing Environment

AspectDescription

Platform name

―W3C Web Services Platform‖ following the Web Service infrastructure as defined by the
W3C specifications

Reference Model

W3C Web Services ArchitectureInterface Language

Web Service Description Language (WSDL), Version 1.1

Copyright © OGC 201039

OGC 10-028r1

Execution Context

The execution context of the W3C Web Services Platform is defined by the following
properties:
Transport Protocol and Message Format:
SOAP 1.2 HTTP binding as defined in SOAP Part 1: Message Framework, Version 1.2 andHypertext Transfer Protocol (HTTP), Version 1.1. The message style that shall be used is
document/literal non-wrapped since it is the most widely accepted and interoperable
message style.
Security
Session Information: The transport of session information may be accomplished by using
platform specific mechanisms, for example the inclusion of a session key in the SOAP
header.
Encryption: Optional encryption of SOAP messages shall be accomplished by Web
Services Security: 4 SOAP Message Security 1.1.

Schema Language

Extensible Markup Language (XML) 1.0

Schema Mapping

ISO 19136 for GML

Table 7: W3C Web Service Platform
TBC with one table for each platform (e.g. OGC Web Services platform) as in the previous example

9.2.4.3

Engineering Policies

This section describes use cases conducted in GEOSS AIP-2. Please note that sequence diagrams of theseuse cases are not available, however, the Basic Flow section of the table presents the sequence of steps indetail.

9.2.4.3.1

Resource Discovery

This use case describes the conditions and steps for portals and application clients to support the GEOSS user insearching for resources of interest via the GEOSS Clearinghouses or Community Catalogs. This use case is a precondition to the Present Reachable Services and Alerts use case.
Overview
Title

Search for Resources via GEOSS Clearinghouse(s) or Community
Catalog(s)Description

This use case describes the conditions and steps for portals and applicationclients to support the GEOSS user in searching for resources of interest via
the GEOSS Clearinghouse(s) or Community Catalog(s).

Actors andInterfaces

GEOSS User
Client Application (GEO Portal, Community Portal, Desktop Application,
Portlet, etc)
GEOSS Clearinghouse
Community Catalog

Initial Status andPreconditions

GEOSS User is looking for information of value to task at hand
Client Application has been developed and is available for use

40

OGC 10-028r1
Resources’ metadata has been successfully harvested in GEOSS
Clearinghouses (either directly or via registration in a Community Catalog)
Basic Flow
Step 1: Client Application requests capabilities of catalogs of interest (GEOSS Clearinghouse
and/or Community Catalogs) to determine the protocol needed to search for resources (e.g CSW
2.0.2 or Z39.50) and the queryable elements of each as needed. Alternatively, the Client Application
knows a-priori the protocol needed to interact with catalog(s)/clearinghouse(s) of interest
Step 2: Client Application presents GEOSS User with search criteria based on queryable propertiesof selected catalogs- Simple keyword search and area of interest/bbox search- Advanced search parameters such as organization, catalogs to be searched, societal benefit areas,
resource type, etc- More specific earth-observation criteria such as sensor row/path, collection, subsetting/ordering
and/or delivery mechanisms, etc- Value-added and/or domain/community specific search capabilities such as thesaurus matching,cluster matching, etc
Step 3: Based on user selections, Client Application constructs query to each selected catalog andthe ResultSet is returned and presented to the user with application-specific options (such as total
number of results, basic information about each result, grouping of results, etc)
Step 4: GEOSS User selects resources of interest for evaluation and/or use.
Post Condition
The Client Application has retrieved the necessary metadata to present the GEOSS User withinformation on discovered resources matching the search criteria for further evaluation and/or use.

Table 8: Resource Discovery

9.2.4.3.2

Service Monitoring

This use case describes the conditions and steps to interact with a Service Instance within GEOSS. This use case can be
specialized to support a variety of GEOSS services and resources such as Sensor Planning Service, Ordering Service,
Models, Sensor Observation Service, WCS over netCDF, WMS Cascading, WFS Simple, CAP Alerts atompub
Service, etc.
TBC with descriptions of each use case using template in annex.1

9.2.4.3.3

Access Control

The GEOSS Implementation Plan states that
“The societal benefits of Earth observations cannot be achieved without data sharing.
The following are GEOSS data sharing principles:
There will be full and open exchange of data, metadata, and products shared within GEOSS, recognizing
relevant international instruments and national policies and legislation.
All shared data, metadata, and products will be made available with minimum time delay and at minimumcost.
All shared data, metadata, and products free of charge or no more than cost of reproduction will be
encouraged for research and education.

Copyright © OGC 201041

OGC 10-028r1
Use of data or products does not necessarily imply agreement with or endorsement of the purpose behind
the gathering of such data.”
Based on the requirement in the implementation plan, it can be expected that GEOSS access control will
primarily be for authentication of users. However,the use of OGC web services within GEOSS implies that
OGC GeoRM (formerly GeoDRM) will play a key role in GEOSS access control as it develops.

9.2.4.3.4

Development Policies

The GEOSS Architecture Implementation Pilot (AIP) develops and deploys new process and infrastructurecomponents for the GEOSS Common Infrastructure and the broader GEOSS architecture. AIP is a coretask (GEO Task AR-09-01b) of the GEO Architecture and Data Committee. Results of the AIP aretransitioned to GEO Task AR-09-01a and the GEOSS Common Infrastructure (GCI). The OGC coordinates
the AIP. Progress of AIP development is listed at http://www.ogcnetwork.net/AIpilot

9.2.4.4

Implementation Architecture

Services can be classified into client, business process and access tiers. Client tier services provide the userinterface of the system; the services include the GEO web site, GEOSS Web Portal, various community
portals and client applications. The business process tier provides the computational and management
functionality of the system; the services include the GEOSS registries, clearinghouse, alert servers,
processing servers, portrayal servers, workflow management servers and other services. The access tieroffers various data acquisition and dissemination services; for example GEONETCast, product accessservices, sensor web services, model access services and others. The following figure depicts these tiers.

Figure 3 GEOSS Tiers
Collectively all these services form the GEOSS Common Infrastructure (GCI). Within the GCI, the web
portal, registry and clearinghouse are the principal components for resource discovery. The web portal is the42

OGC 10-028r1
main application for accessing GEOSS services. The clearinghouse provides search capability across a
distributed network of catalogue services. The registry publishes metadata describing components andservices registered in GEOSS.
An instantiation of the above architecture is being deployed under the Heterogeneous Missions Accessibility[RD5] initiative of the European Space Agency as shown on the next figure. The Community Clients are themain applications for accessing the EO services. The EO Community Clearinghouse accessible from the
GEO Web Portal provides search capability across a distributed network of catalogue services. The EO
Community Service and Collection catalogue publishes ISO metadata describing Community resources e.g.
EO dataset series (i.e. collections) and services registered and their interrelationships. Types of service
registered include catalogues, ordering services, sensor planning services and Web mapping services. In
addition, conformance test capabilities are available based on the OGC CTL language and the TEAM test
engine.

Figure 4 Example of GEOSS Tiers Instantiation for the European Union

9.2.5

Technology Viewpoint

The GEOSS Registry provides a catalogue of all registered components and services. The following requirements
apply to technologies contributed to GEOSS:
Upon registering a service, a service provider must specify the length of time for which the service will beoffered (preferably ‗unlimited‘).
Experimental services will be registered and exempt from the level of service requirements.
Services are expected to be available at least 99% of the time, except when otherwise required by the natureof the service. This allows for approximately 7 hours of down time a month. Adequate network service must
be utilized in order to provide this level of availability.

Copyright © OGC 201043

OGC 10-028r1
Non-functioning components of the Network will diminish the operational and marketing value of the
Network in general for all participating organizations. Therefore, GEO may remove a listed server from theregistry

9.2.5.1

Component Implementation

It should be noted that GEOSS is a system of contributed systems, components and services. Therefore, contributors
have adopted a variety of technologies for implementing the components contributed to GEOSS. In this sub-section we
have selected some of the components and instances that have been used in the AIP and associated tasks.
Community portals: A community-focused portal (website) that provides a human user interface toidentified content. Some of the component instances used include ESRI GIS Portal toolkit,
Compusult, ESA/FAO portal products.
Client applications: Application hosted on users computer to access remote services and provide
manipulation of the data in the client application. Clients may be specific to a user community or
may be more generic geospatial data applications. Some of the clients that have been used tointeract with GEOSS components during AIP-2 included web browsers (Internet Explorer, Mozilla
Firefox), UDig (used as WPS client), Google Earth and ERDAS TITAN.
Community catalogues: Collection of community-organized information descriptions (metadata)
exposed through standard catalog service interfaces. Example component instances used include
catalogue services(CSW) bundled with ESRI GIS Portal toolkit and another developed by George
Mason University.
Workflow management: Encapsulates an engine capable of managing workflows, services,
activities, and workflow execution instances. An example instance is BPELPower developed by
George Mason University. GMU BPELPower BPEL engine is a generic BPEL workflow execution
engine. Another workflow engine is Oracle BPEL Process Manager used by ESA Service Support
Environment (SSE).
Processing services: Components that accepts requests to process data using an algorithm hosted
in the component. The data is accessed from a remote service. The processing services used in
AIP-2 were offered through instances of the 52North WPS.
GEONETCast: Global network of satellite-based data dissemination systems to distribute data via
broadcast. The GEONETCast multicasting allows different datasets or EO products to betransmitted in parallel from satellites or in-situ sensors. Access to data is controlled and targeted to
specific groups of users through a key access capability. The multicast capability uses a global
network of communications satellites that includes direct-to-home (DTH) telecommunication
satellites and Digital Video Broadcast (DVB). GEONETCast is describes in detail by Wolf L. andWilliams M. (2008) "GEONETCast—Delivering Environmental Data to Users Worldwide" IEEE
Systems Journal, pp. 401-405, 2(3) DOI 10.1109/JSYST.2008.925978

9.2.5.2

Run-time Environment

There are no requirements in GEOSS for specific run-time requirements. Components and Services within GEOSS are
implemented in a variety of run-time environments.

9.2.5.3

Deployed Service Instances and Networks

The following are lists of Components and Services currently registered in the GEOSS Registry.
The following table is a list of components catalogued in the GEOSS Registry exported on September 9th 2009.
1.
2.

44

52°North SOS Client
AIRNow Gateway Web Service
TBC with list of other components

Details
Details

OGC 10-028r1
Table 9 Extract of the Components Registered in GEOSS by September 9th 2009
The following table is a list of services catalogued in the GEOSS Registry. The list was exported on September 09th
2009.
1.

Water Survey of Canada WMS Service

Details2.

VASDI greenland wms_n_baggrund service

Details

TBC with list of other services
Table 10 Extract of the Services Registered in GEOSS by September 9th 2009

9.2.5.4

Standardisation Process

During service registration, service providers enter references to interoperability arrangements adopted by theircontributed services and components. Interoperability arrangements can include international standards such as those of
the OGC, IEEE or W3C; but may also be special arrangements based on application-specific business rules.
If the standard is not already a registered specification, it is assessed by the Standards and Interoperability Forum (SIF)
then registered. The main purpose of the SIF is to ensure that GEOSS components can interoperate through one of theregistered standards or other interoperability arrangements. The SIF facilitated interoperability through technicalanalysis, advocacy, education and the provision of impartial advice on issues regarding standardisation andinteroperability within GEOSS. The following figure illustrates the role of the SIF.

Figure 5 SIF RoleAll registered standards are entered in the Standards and Interoperability Registry. The architectural role of theStandards and Interoperability Registry is depicted in the GEOSS Common Infrastructure described in the GEOSSEngineering Viewpoint sub-section of this chapter.
The SIF promotes to form Regional Teams to have true global representation in supporting GEOSS interoperability. A
SIF European Team was promoted (see http://www.thegigasforum.eu/sif/ ). In this framework, the purpose of having a
European Regional Team is to increase efficiency in carrying out the work of the SIF, addressing issues such as:
bring local knowledge and reach out multi-disciplinary and regional science Communities;

Copyright © OGC 201045

OGC 10-028r1
provide knowledge and experts about regional standard and interoperability arrangements;
support the SIF to complete the tasks submitted by Communities.
The SIF European Regional team will
identify subject matter experts representing each (or most) of the Societal Benefit Areas of GEOSS in
Europe.
facilitate the registration of European standards and interoperability best practices (e.g. special
arrangements).
be prepared to review standards and special arrangements submitted for entry into the standards registry.
help reach out to scientific Communities in Europe, as far as GEOSS is concerned.
URL for accessing the present GEOSS deployed services is http://geossregistries.info/

46

OGC 10-028r1

9.3

Annex 3 Requirements on Requirements

The following requirements define a set of basic rules on how to write requirements. The
rules are derived from ECSS E-10 6C [RD7] which can be used as a reference for writing
requirements.
Each requirement shall be separately stated.
A requirement shall be self-contained.
Each requirement shall consist of a single sentence with ―shall‖ or ―should‖,Note: notes like this can be used to clarify the sense of the requirement
The verbal form ―shall‖ shall be used whenever a provision is a requirement.
The verbal form ―should‖ shall be used whenever a provision is arecommendation.
The verbal form ―may‖ shall be used whenever a provision is a permission.
The verbal form ―can‖ shall be used to indicate possibility or capability.
Requirements should be stated in performance or ―what-is-necessary‖ terms, as
opposed to telling a supplier ―how to‖ perform a task, unless the exact steps inperformance of the task are essential to ensure the proper functioning of the
product.
Requirements should be expressed in a positive way, as a complete sentence (verb
and noun).
The entity responsible of the technical requirement shall be identified.
All technical requirements shall be backwards-traceable and forwards-traceable.
Any detected ambiguity in a requirement shall be removed.
Each requirement shall be unique.
Each requirement shall have a unique identifier
A proposed syntax for the requirement identifier should be<project-acronym>-XXX-YYY-NNN
Where<project-acronym> is something like GEO
XXX is an identifier of the topic/working group, e.g. CAT for―‖Catalogue‖

Copyright © OGC 201047

OGC 10-028r1

YYY is a 2nd level acronym e.g. FUN for functional, GEN for general,
OPE for operational..
NNN is a counter, it is suggested to start numbering requirements with astep of 10 (e.g. 010, 020 etc, in order to be able to insert new requirements
later (e.g 011, 012 etc.)
The requirements should be grouped by type or in accordance with the different
situations of the product or system life cycle in regard of the needs, theenvironmental conditions and the constraints.
The requirements shall be unambiguous and not in conflict with the otherassociated requirements in contractual documentation.
A priority should be identified for each requirement.
Each (performance) requirement shall be described in quantifiable terms.
Each (performance) requirement should include an attribute that defines themethod used to determine the required performance.
A requirement shall be verifiable using one or more approved verification
methods.
The following items (and similar ones) should not be used in a requiremento ―and/or‖,o ―etc‖,o ―goal‖,o ―shall be included but not limited to‖,o ―relevant‖, ―necessary‖, ―appropriate‖,o ―as far as possible‖,o ―optimize‖, ―minimize‖, ―maximize‖,o ―typical‖,o ―rapid‖, ―quick‖o ―user-friendly‖,o ―easy‖,o ―sufficient‖, ―enough‖,o ―suitable‖, ―satisfactory‖, ―adequate‖,o48―first rate‖,

OGC 10-028r1

o ―best possible‖,o ―great‖, ―small‖, ―large‖,o ―state of the art‖.

Copyright © OGC 201049

OGC 10-028r1

9.4

Annex 4 Example of Draft Issue/Recommendation

Summary“It is recommended
to GIGAS to define a sustainable model for a permanent test environment ('persistent research test-bed'),to initiatives and organizations like INSPIRE/GEOSS/GMES/OGC/AGILE/EuroSDR and existing and future
research projects to design, develop and test new types of interoperable geospatial services and interfaces in
the context of this testbed, andto the EC/EU and related organisations to foster research by offering this sandbox environment.

Classification
Category
Interoperability tools

Identifier
REC-IT-001 Persistent Testbed

Type of recommended activity
Business model

Organisations addressed
GIGAS (as the one to start the development) and INSPIRE Consolidation Team, GEOSS ,GMES, OGC, AGILE,EuroSDR, ISO/TC-211, CEN TC287

Additional information
Context
It is recommended to define a sustainable model for a persistent test-bed so that uptake of standards by industry andinstitutions is eased.The envisaged testbed is assumed to provide
An open, permanent infrastructure in which organisations or external projects can integrate their(compliant) services.
A permanent test environment to design, develop and test new services and service interfaces and to foster
related research by to offering a sandbox for not yet established service types.
Optionally conformance test tools (as for example CITE).
A set of tools supporting the target interfaces (ideally offered as freely available open source tools).

Full recommendation text
It is recommended
to GIGAS to define a sustainable model for a permanent test environment ('persistent research test-bed'),to initiatives and organizations like INSPIRE/GEOSS/GMES/OGC/AGILE/EuroSDR and existing and future
research projects to design, develop and test new types of interoperable geospatial services and interfaces in
the context of this testbed, and50

OGC 10-028r1
to the EC/EU and related organisations to foster research by offering this sandbox environment.

Rationale
Although multiple and diverse testing activities exist among the initiatives and standardisation organisations, none ofthem provides a sustainable and persistent environment to test and develop new standards and data specifications.
Each testing activity has to set up an own environment. This includes redundant time and effort from scratch, because
in most cases, the same kinds of data and processing services are used. A persistent testbed could help to minimize
these efforts by offering such services for a sustainable time period. More time can be spent for solving the realresearch problem. Besides, the services could be used to reliably serve teaching purposes and the various researchoutcomes can be offered for a longer time period instead of vanishing after a project is finished. This would improve
the work of the whole geospatial interoperability research community in Europe.

Dependencies
Main discussion points
To enable the persistent characteristics of the testbed, the maintenance of the offered services and the according
management activities are a critical issue. Although this requires only a modicum of money and manpower, the funding
has to be assured over years.

Further background information
The development of the business model for the testbed is carried out in strong cooperation with the
AGILE/EuroSDR/OGC Persistent Testbed for Research and Teaching in Europe (PTB). A lot of information can beacquired from their website at http://plone.itc.nl/gitestbed.

Roadmap
The business model for the Persistent Testbed is tackled by the deliverable D3.5 “GIGAS Persistent Testbed Business
Model”. Details can be found there as soon it is published (first draft in the end of September 2009).

Follow-up
The business model for the Persistent Testbed is tackled by the deliverable D3.5 “GIGAS Persistent Testbed Business
Model”. Details can be found there as soon it is published (first draft in the end of September 2009)

On-line discussion
You can add your own thoughts and remarks about this topic in the GIGAS comment section.
If you are not yet registered yet, you can do so at the GIGAS discussion board.

Copyright © OGC 201051

OGC 10-028r1

9.5

Annex 5 RM-ODP in GEO Architecture Implementation Pilot

The GEO Architecture Implementation Pilot (AIP) is using the RM-ODP approach for its
design. This approach has the advantage that the proposed methodology can be used
as a tool to identify gaps and areas of convergence in parallel to the AIP design.
The AIP is developing RM-ODP viewpoints using UML in accordance with thefollowing principles:
1. ―Creating explicit models of a system‘s design is the step leading from art topractice‖ is the approach taken by Christopher Alexander‘s Notes on theSynthesis of Form, and Eberhardt Rechtin‘ System Architecting.‖ The principal
is that explicit models are needed for the community of interest for the system toinspect and critique in order to have an optimum development practice.
2. ―Architecture practice requires description of the system from multiple
viewpoints‖ is consistent with almost all International standards for architecture
which consistently require a set of viewpoints, e.g., IEEE 1220, ISO/IEC 10746,
ISO/IEC 19793
3. ―System-of-system development requires iteration of design synthesis withexisting implementations‖. There is no ―blank sheet‖ starting point for systemdevelopment in a system of systems. The models can begin with abstracting the
key design aspects from the deployed system. Optimization is achieved throughiterations of deployment analysis, design refinement and refinement of the
deployments.
The GEO AIP makes use of ISO/IEC 19793. The following table summarizes thecontent of the viewpoints used in AIP:
ViewpointName

GEO AIP Viewpoint
Summary

GEO AIP Viewpoint Contents

Scenarios, system
purpose, users, policies,

Community of Practice Scenarios
Community Objectives, Actors, Pre-Conditions, Events, Post Conditions, Enterprise Model
Context Diagram: UML diagram showing GEOSS and the externals – no internal structureEnterpriseEnterprise Specification: UML class diagram of Enterprise Objects
Activity Diagram: UML activity diagram with swimlanes of Scenario Events (functional anddata flow)
Process Diagram (optional): UML sequence diagram of Scenario EventsC Information
o
m
p
u
t
a
t
i
o
n
a
l

Abstract information
concepts; Concrete
encodings

Service oriented

52

UML class diagram for Information Types: ERD
SBA specific classes: e.g., flooded areas,
GEOSS wide data types: Global data sets, Framework data types in CFP
Cross-cutting technology classes: e.g., geospatial features
Focus on basetypes/classes and too a lesser extent individual attributes
Use Case from technology point of view including these elments: Actors and Interfaces,

OGC 10-028r1

ViewpointName

GEO AIP Viewpoint
Summary

GEO AIP Viewpoint Contentsarchitecture; Use cases

Initial Status and Preconditions, Evolution, Post Condition
SOA concepts: publish-find-bind and Service definitions
Use Cases of two types are define:
Generalized Use Cases modeled as an activity diagram or sequence diagram
Specialized Use Cases for the Community of Practice Scenarios
Activity diagram or sequence diagram

TechnologyEngineering

Mapping to Enterprise Activity Diagrams as activity hierarchy
Component types;
Communication media

Component Types
UML Component diagram
Mapping from generalized use cases to the component types
Mapping services to component types

Component instanceswith network addresses

Component Instances identified by referring to the GEOSS Component and Service Registry
Representative Deployment diagrams
Not aiming to completely describe all deployed components in the Tech View

Table 11 Contents of the RM-ODP Viewpoints for GEOSS AIP

Copyright © OGC 201053