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