ECHO: NASA’s E os C learing HO use Integrating Access to Data Services Michael Burnett Blueprint Technologies, 7799 Leesburg Pike, Suite 1000N, Falls Church, VA 22043, USA CEOS May 7-10, 2002 Frascati, Italy

May 7-10, 2002CEOS – ECHO Services Agenda Echo Overview Services and Echo User Interfaces Issues

May 7-10, 2002CEOS – ECHO Services 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 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.

May 7-10, 2002CEOS – ECHO Services ECHO Context Clearinghouse Catalog Pages Client Apps Client API Provider API

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

May 7-10, 2002CEOS – ECHO Services 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

May 7-10, 2002CEOS – ECHO Services ECHO’s Service Oriented Architecture Design-time Run-time

May 7-10, 2002CEOS – ECHO Services 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

May 7-10, 2002CEOS – ECHO Services Web Services >

May 7-10, 2002CEOS – ECHO Services Object Model

May 7-10, 2002CEOS – ECHO Services 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

May 7-10, 2002CEOS – ECHO Services Service Types Based on ECHO’s responsibility in fulfilling the “binding” interaction Four types Advertise Context-based Brokered Order Options

May 7-10, 2002CEOS – ECHO Services 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

May 7-10, 2002CEOS – ECHO Services User interface version of SOA

May 7-10, 2002CEOS – ECHO Services Issues

May 7-10, 2002CEOS – ECHO Services 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

May 7-10, 2002CEOS – ECHO Services 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?

May 7-10, 2002CEOS – ECHO Services 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

May 7-10, 2002CEOS – ECHO Services 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”

May 7-10, 2002CEOS – ECHO Services 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.

May 7-10, 2002CEOS – ECHO Services “Advertising” Services Problem: How do users know about new services? Issues: Is there a need for a proactive mechanism? Subscription Service?

May 7-10, 2002CEOS – ECHO Services 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)

May 7-10, 2002CEOS – ECHO Services Taxonomies Problem: What is the most appropriate level of specification of service taxonomy? Issues: Positive and negative Helpful for semantic understanding Can be constraining

May 7-10, 2002CEOS – ECHO Services 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”

May 7-10, 2002CEOS – ECHO Services Security Problem: Secure Access – Authentication and Authorization Issues: Web Service standards not yet in place Delegation

May 7-10, 2002CEOS – ECHO Services 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