The Full Picture

[

] 108

contributed as GEOSS Components. “Interfaces” are the primary

touch points between component systems--a way to plug one system

into other systems. GEOSS interoperability emphasizes interfaces,

defining precisely how system components can interface with each

other. This minimizes impact on component systems other than

where each system interfaces to the shared GEOSS architecture.

In the wildland fire scenario, there are various interfaces among the

different systems in use. Many of these interfaces are implemented

as services in the GEOSS Architecture sense. For instance, back-

ground maps of terrain, vegetation, roads, etc. are typically available

through the standardized service for map display. These maps can

be overlain with real-time fire warnings from a standard Internet

news feed service. Finally, warnings for any hazard can be commu-

nicated across all available media using the standard format for alerts.

Standards and other interoperability arrangements

Overall, GEOSS is made up of contributed systems operating

within their own mandates. GEOSS adds value to these compo-

nent systems to the extent that they leverage each other’s resources

through standard interfaces and other interoperability arrange-

ments. That synergy among diverse and independent systems is

how GEOSS makes Earth observation data and information more

accessible, comparable, and understandable.

The GEOSS Plan states: “The success of GEOSS will depend on

data and information providers accepting and implementing a set

of interoperability arrangements, including technical specifica-

tions for collecting, processing, storing and disseminating shared

data, metadata and products.” Any newly contributed GEOSS

component must implement GEOSS interoperability arrangements

as registered at the time when it is contributed.

Potentailly, thousands of existing standards could be relevant to

one or another aspect of GEOSS, so how does GEOSS help the

designers of contributed systems to choose between available stan-

dards and arrangements, in order to maximize interoperability with

other GEOSS components? A few interoperability standards are refer-

enced in the GEOSS Plan itself, but the GEOSS Plan sets only the

most basic of requirements: “GEOSS interoperability will be based on

non-proprietary standards, with preference to formal international

standards.” A consensus process is needed to consider additional

standards and interoperability arrangements.

To support consensus seeking in matters of GEOSS

interoperability, the GEO Architecture and Data

Committee will call upon its Standards and

Interoperability Forum, which was set up to address

situations where GEOSS components cannot interop-

erate using one of the registered standards or other

arrangements. Drawing on expert advice, the objective

of the forum is to exploit existing standards to the

maximum extent possible. The forum is not itself a

standards body, but its participants will forward sugges-

tions to standards organizations from time to time.

Standardizing services, syntax and semantics

As mentioned above, there are a few interoperability

standards given in the GEOSS Plan itself. Because the

GEOSS Architecture is an instance of an SOA, the

GEOSS Plan addresses how service interfaces are

defined. If a service interface is like a power connector,

a service interface definition is like the specification for

making plugs and outlets.

Software engineers have several ways to define a

service interface at present. Because these languages

are not equivalent, GEOSS has not specified a stan-

dard for service interface definitions. The GEOSS Plan

states: “Systems interoperating in GEOSS should use

any one of four open standard ways to describe service

interfaces.” In the wildland fire example, the standard

for displaying maps is defined using one of these inter-

face languages.

Today, building adaptors to achieve interoperability

between systems can be frustrating. Even though most

systems have network service interfaces, often such

services are poorly documented. It is crucially impor-

tant to have service definitions; it is less important that

all service definitions are expressed the same way. Still,

it is inconvenient that software designers must some-

times translate between service definitions. When the

field of software design converges on a single standard,

GEOSS service interoperability should be updated

accordingly.

Source: Eliot Christian

Earth System Models

• Oceans • Cryosphere

• Land • Atmosphere

• Solid Earth • Biosphere

Decision Support

Assessments

Decision Support Systems

Policy Decisions

Management Decisions

Predictions and Analysis

Observations

High Perfomance Computing;

Communication & Visualization

Standards & Interoperability

Assimilation

Ongoing feedback to optimize value, reduce gaps, and account for human activity

Earth Observation

System

• In situ

• Airborne

• Space-based

Other Data Sources

Socio-economic data

GEOSS

GEOSS architecture implemented by component systems

GEOSS C

OMPONENTS

– O

BSERVING

YSTEMS