ECHO : NASA

1
ECHO NASAs Earth Observing System (EOS)
ClearingHOuse

• Robin Pfister
• robin.pfister_at_gsfc.nasa.gov
• Code 423, NASA/GSFC, Greenbelt MD, 20771 USA
• Michael Burnett
• mburnett_at_blueprinttech.com
• Blueprint Technologies, 7799 Leesburg Pike, Suite
  1000N,
• Falls Church, VA 22043, USA
• CEOS
• May 7-10, 2002
• Frascati, Italy

2
Outline of Presentation

• What is ECHO?
• Goals Drivers
• Architecture Technology
• Issues

3
What is ECHO?Goals

• Functionally
• Support the efficient discovery and access to
  Earth Science data.
• Enabling System
• Publish APIs to user community. Open system,
  rather than closed.
• COTS-based
• Maximize COTS usage. Follow industry trends
  rather than try to set them.
• Incremental Deliveries
• Allow for insight and feedback during the
  development cycle. No big bang surprises.

4
What is ECHO?Drivers

• Cost
• Need to manage the cost of system development,
  deployment and operations.
• Ease of Participation
• The system should not be so hard as to prohibit
  providers from participating in the
  clearinghouse.
• Extensibility
• The system must continuously support new
  capabilities, including Data types, User
  Interfaces, and Services. It must be an enabling
  system, not a solution system.

5
What is ECHO?Capabilities

• Clearinghouse of Earth Science Metadata
• Providers control what is represented
• Single Search point
• Internet based interfaces
• Support ordering of data
• Broker distributed orders
• Extend the available Earth Science resources
• To the science community
• From the science community

6
What is ECHO?A Framework

• Message-based framework
• Allowing providers and clients (machine to
  machine or human-machine) to share information
  and context in order to interoperate.
• Catalog Service
• Capable of handling very large and complex data
  sets
• Order Entry Service
• Handles receiving a single order and sending it
  out to multiple providers
• Data Management Service
• Manages privileges for accessing catalog entries
  and controls the ability to order them
• Subscription Service
• Ability to send metadata updates directly to users

7
ECHOs Context
Client Apps
Pages
Client API
Clearinghouse Catalog
Provider API
8
Framework Extension Points

• Data Extensibility
• New participating providers
• New Collections/Data Types
• Access Mechanisms

• Client Extensibility
• Applications
• Extended Servers
• UIs (applets, active pages, etc.)

• Service Extensibility
• New Services
• New UIs on those services

APIs

• Admin Extensibility
• Personalization
• Billing and Accounting

Clearinghouse Catalog
9
What is ECHO?Implementation

• Java and XML used extensively
• COTS
• BEA WebLogic, Oracle, Open Source
• Providing SOAP access to core services
• Moving towards Web Service

10
Current/Planned Participants
Clients Data Providers Service Providers
EDG Data Validation UI Query Preview GSFC-ECS EDC-ECS NSIDC-ECS ORNL SEDAC (TBD)? EDC GSFC
Mercury-EOS DODS (URI) NSIDC Wizard Code 935 (NEPSTER)? Stennis (Ikonos) Code 935 (NEPSTER)? UAH DODS (URI)
Internal
External
11
Issues/Challenges
12
Issue Metadata Integrity

• A system based on metadata is only as good as the
  metadata contents
• Challenge Developing a clean metadata
  clearinghouse and keeping it clean has a large
  impact on operations. Minimizing the impact is
  the challenge.
• Solution
• Define conceptual data model (based on ECS)
• Policy decisions made during Registration
• Provide Tools to facilitate translations
• Automated tools for data population that prevent
  Providers from violating metadata rules

13
Issue API Simplicity

• APIs are most effective when they are simple
• Challenge Developing a clean and simple set of
  APIs that meet future needs without having to
  predict all future needs.
• Solution
• Drive API identification through Use Cases
• Distill to what is needed
• Dont try to be too smart
• Allow for extensibility

14
Issue Visibility

• Providers dont want to expose all of their data
  to all users
• Challenge Provide a mechanism for controlling
  access to data, as specified by the data provider
• Solution
• Give provider the control
• Support ACL mechanisms
• Users and Groups

15
Issue Getting Input From Large Community

• ECHO wants to represent the expected needs from a
  variety of groups within the Earth Science
  community
• Challenge Balancing practicalities of
  conflicting input and system goals
• Solution
• Ideas for features and enhancements are generated
  by ECHO Providers, development team, advisory
  group and others.
• Initiated through meetings, telecons and
  workshops
• Input is prioritized in the ECHO Technical
  Committee Meetings/Telecons. (ETC is made up of
  ECHO providers)

16
Summary

• Echo is
• A metadata clearinghouse
• A set of APIs
• Flexible
• Status
• Operational (Limited)
• Release 5 under development
• Futures
• Service Integration next big push
• Moving from system to framework
• Check out
• http//dangermouse.gst.com/ECHO/