AIP-2 Kickoff Workshop End-to-end use case: Discovery, access, and use with variations Doug Nebert GEOSS AIP-2 Kickoff 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 GEO Web Portal GEOSS Registries Services Components Standards GEONETCast Other Services Product Access Services Model Access Services Community Portals Client Applications Requirements Community Catalogues Portrayal Servers Workflow Management Processing Severs Other Services GEOSS Clearinghouse Sensor Web Services Alerts/Feeds Servers Infrastructure Registries CFP Architecture – Component Types

GCI operational interaction diagram

GEOSS workflow GEOSS Component, Service registry Standards, Special Arrangements Registries references Web Portal or Client Application searches Offerors contribute Community Resources accesses GEOSS Clearinghouse Catalogues User accesses get catalogue services accesses searches invokes Component System 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