AIP-2 Kickoff Workshop End-to-end use case Discovery, access by wwr69367

VIEWS: 7 PAGES: 9

									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
   GEO Web                         Community               Client
                     Web
     Site                           Portals              Applications
                     Portal



   GEOSS
                                                   Business Process Tier
  Registries       GEOSS
 Components     Clearinghouse   Alerts/Feeds      Portrayal      Workflow
                                  Servers         Servers       Management
   Services
  Standards
                Community       Infrastructure   Processing        Other
 Requirements   Catalogues        Registries       Severs         Services


                                                                Access Tier
                    Product          Sensor        Model
 GEONETCast                                                       Other
                    Access            Web         Access
                                                                 Services
                    Services        Services      Services
GCI operational interaction diagram
 GEOSS workflow
                    accesses
                                                                    6        Community
                                          Web Portal or
     User    5                          Client Application        accesses   Resources
                           searches
                                      searches
                                                  7
                                   get                                       invokes
                                   catalogue        GEOSS
references       GEOSS                                                          8
                                   services      Clearinghouse
              Component,
                                            3
             Service registry
                                                        4    accesses
        2


    Standards,                                  Catalogues
      Special
   Arrangements                    contribute
     Registries
                        Offerors        1
                                            Component       Service(s)
                                            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

								
To top