ECHO : NASA’s E os C learing HO use

1. ECHO: NASA’s Eos ClearingHOuse Integrating Access to Data Services Michael Burnett mburnett@blueprinttech.com Blueprint Technologies, 7799 Leesburg Pike, Suite 1000N, Falls Church, VA 22043, USA CEOS May 7-10, 2002 Frascati, Italy

2. Agenda • Echo Overview • Services and Echo • User Interfaces • Issues CEOS – ECHO Services

3. 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 Goals Functionally Support the efficient discovery and access to Earth Science data. Enabling System Publish API’s 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. ECHO CEOS – ECHO Services

4. Client Apps Pages Client API Clearinghouse Catalog Provider API ECHO Context CEOS – ECHO Services

5. Clearinghouse Catalog ECHO Framework • Data Extensibility • New participating providers • New Collections/Data Types • Access Mechanisms • Client Extensibility • Applications • Extended Servers • UI’s (applets, active pages, etc.) • Service Extensibility • New Services • New UI’s on those services API’s CEOS – ECHO Services

6. Philosophy of Services and Echo • Expanding the value of the data holdings • A marketplace for broader science tools • Market specific value-added processing • Support more effective data delivery • Reduce the volume • Reduce the delivery of “incorrect” or “less than useful” data • Distribute the roles and participation of the support community • Data providers don’t have to “do it all” • Looser coupling • Enabling more complete Science, faster • Manage Interfaces not the domain CEOS – ECHO Services

7. ECHO’s Service Oriented Architecture Design-time Run-time CEOS – ECHO Services

8. Web Service Standards • XML • Language and platform independent • Used for information exchange between clients and services. • SOAP • XML-based protocol used to communicate with service • WSDL • Describes the service’s interface the client may use. (in XML) • UDDI • Provides mechanisms to publish and locate web services CEOS – ECHO Services

9. Web Services <<SOAP>> <<WSDL>> <<UDDI Query>> <<UDDI>> CEOS – ECHO Services

10. Object Model CEOS – ECHO Services

11. Service Views • Two “Views” Identified • Based on User’s perspective • Service View • Looking for services first and foremost • Data View • Looking first for data, then what services are available CEOS – ECHO Services

12. Service Types • Based on ECHO’s responsibility in fulfilling the “binding” interaction • Four types • Advertise • Context-based • Brokered • Order Options CEOS – ECHO Services

13. Services & User Interfaces • Service is functionality • With an interface • Like a Function signature • Service Attributes • Describe the services • How to use the service • Echo Enables flexible User Views • What does the User see? • Multiple User Interfaces CEOS – ECHO Services

14. User interface version of SOA CEOS – ECHO Services

15. Issues CEOS – ECHO Services

16. API simplicity • Problem • How to minimize the specification of the services framework API? • Issues • Can’t know all the kinds of services • Simple may not seem/be complete • Classic trade CEOS – ECHO Services

17. Coupling • Problem: • How tightly coupled are the service and the “type” of data? • Issues: • What are the mechanisms of consistency? • Is there a uniform definition of “type”? • Where could any checking occur? CEOS – ECHO Services

18. Co-location • Problem: • Data and Service aren’t always “at the same place” • Issues: • Connecting the data and the service • Data Hopping? • Moving the service or the data • Potential volume of data movement CEOS – ECHO Services

19. Synchronicity • Problem: • There will be needs for both synchronous and asynchronous services. • Issues: • Description and interface need to be able to support both • Some services may provide both • What is Echo’s role in managing asynchronous transactions? • Estimating “Quality of Service” CEOS – ECHO Services

20. Service Response • Problem • What does the service return: Data or status? • Issues: • Delivery of data is nominally what ordering is for. • Volume of data returned in XML might be large. CEOS – ECHO Services

21. “Advertising” Services • Problem: • How do users know about new services? • Issues: • Is there a need for a proactive mechanism? • Subscription Service? CEOS – ECHO Services

22. Registry on UDDI • Problem: • UDDI is least mature of the fundamental Web Service technologies • Issues: • Use of tmodels at multiple layers • tmodels for service interface description • tmodels for service types (reuseable service interfaces with separate implementations) CEOS – ECHO Services

23. Taxonomies • Problem: • What is the most appropriate level of specification of service taxonomy? • Issues: • Positive and negative • Helpful for semantic understanding • Can be constraining CEOS – ECHO Services

24. Service Chaining • Problem: • Users will want to define sequences of services, for reuse • Issues: • Definition of a language for chaining • Technical challenges • Reuse and sharing of “service chains” CEOS – ECHO Services

25. Security • Problem: • Secure Access – Authentication and Authorization • Issues: • Web Service standards not yet in place • Delegation CEOS – ECHO Services

26. Futures • WSFL • Use in chaining services • Letting users build their own business processes • WSEL • ECHO Service Registry: Private or Public? • Moving from system to framework CEOS – ECHO Services