Transcript Update on OGC involvement in GEOSS

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
CFP Architecture – Component Types
Client Tier
GEO Web
Site
GEOSS
Registries
Components
GEO
Web
Portal
Community
Portals
Client
Applications
Business Process Tier
GEOSS
Clearinghouse
Alerts/Feeds
Servers
Portrayal
Servers
Workflow
Management
Infrastructure
Registries
Processing
Severs
Other
Services
Services
Standards
Requirements
Community
Catalogues
Access Tier
GEONETCast
Product
Access
Services
Sensor
Web
Services
Model
Access
Services
Other
Services
GCI operational interaction diagram
GEOSS workflow
accesses
User
Web Portal or
Client Application
5
6
accesses
Community
Resources
searches
searches
7
references
GEOSS
Component,
Service registry
get
catalogue
services
GEOSS
Clearinghouse
3
4
2
Standards,
Special
Arrangements
Registries
accesses
Catalogues
contribute
Offerors
1
Component
System
Service(s)
invokes
8
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