AIP-2 Kickoff Workshop

End-to-end use case: Discovery, access, and use with variations

Doug Nebert

GEOSS AIP-2 Kickoff

25-26 September 2008

History

• AIP Phase 1 engaged a number of scenarios to demonstrate access to and integration of services related to problem-solving in the EO context

• GEOSS Registries were fully available as of June 2007, and all AIP-nominated systems and services were expected to be registered

• GEOSS Clearinghouse (common search facility) and Web Portal solutions were in the process of design and development, coincident with the AIP scenarios

• Few scenarios actually applied the Clearinghouse and Registries, now known as the GEOSS Common Infrastructure as part of the demonstrated workflow

Use of GEOSS Common Infrastructure (GCI)

• Focus of AIP-II contributions is to contribute and integrate mature, persistent capabilities as services and client solutions (operational persistence)

• All contributions must exercise the existing capabilities of the GCI as a core outcome of the “Architecture Implementation”

• GCI elements include:– GEOSS Component and Service Registry– GEOSS Standards and Interoperability Registry– GEOSS Clearinghouse– GEOSS Best Practice Wiki– GEOSS User Requirements Registry (Prototype)– GEO Web Portal frameworks

GEO Web Site

Client Tier

Business Process Tier

Access Tier

GEOWeb

Portal

GEOSSRegistries

Services

Components

Standards

GEONETCast OtherServices

ProductAccess

Services

ModelAccess

Services

CommunityPortals

Client Applications

RequirementsCommunityCatalogues

PortrayalServers

WorkflowManagement

ProcessingSevers

OtherServices

GEOSSClearinghouse

SensorWeb

Services

Alerts/FeedsServers

InfrastructureRegistries

CFP Architecture – Component Types

GCI operational interaction diagram

GEOSS workflow

GEOSSComponent,

Service registry

Standards,Special

ArrangementsRegistries

references

Web Portal orClient Application

searches

Offerors

contribute

CommunityResourcesaccesses

GEOSSClearinghouse

Catalogues

User

accesses

get catalogueservices

accesses

searches

invokes

1

2

34

56

7

8

ComponentSystem

Service(s)

AIP Context

• Clients (websites or desktop) applications need to interface with the GEOSS resources through standard interfaces

• GEO Web Portal candidates may be approached to ‘host’ your community interests and help register content

• Additional resource types (applications, documents, models, etc.?) should be considered in the Registries – need your help on what these should be and how they are managed

In your scenarios, consider:

• Include a link to registration of Components and Services to support your user community – we need key content

• The discovery of new resources may be critical to the function of your decision-support application – include a software-based search capability

• Identify the resource types you expect to contribute and discover in GEOSS and what is needed to make automated connection (binding) more possible

• Are there user requirements from your application domain that could be captured in GEOSS to compare with available resources?

Project expectations

• Every project must register service interfaces in the GEOSS Component and Service Registry: Service information (WSDL, GetCapabilities, html page) and an invocation sample URL

• If new standards or practices are identified, nominate them to the Standards and Interoperability Registry

• If you have questions or issues on the application of standards, the Standards and Interoperability Forum (SIF) is available to support you