echo: nasa’s e os c learing ho use integrating access to data services michael burnett...
Post on 18-Dec-2015
214 Views
Preview:
TRANSCRIPT
ECHO: NASA’s Eos ClearingHOuse
Integrating Access to Data ServicesMichael Burnettmburnett@blueprinttech.comBlueprint Technologies, 7799 Leesburg Pike, Suite 1000N, Falls Church, VA 22043, USA
CEOSMay 7-10, 2002Frascati, Italy
May 7-10, 2002 CEOS – ECHO Services
ECHO
DriversCost
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
GoalsFunctionally
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, 2002 CEOS – ECHO Services
ECHO Context
ClearinghouseCatalog
PagesClientApps
Client API
Provider API
May 7-10, 2002 CEOS – ECHO Services
ECHO Framework
ClearinghouseCatalog
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, 2002 CEOS – 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, fasterManage Interfaces not the domain
May 7-10, 2002 CEOS – ECHO Services
ECHO’s Service Oriented Architecture
ECHO Client
Service ProviderBind
ECHO Operations
(from Use Case View)
ECHO Service Registry
PublishFind
manages
Design-time
Run-time
May 7-10, 2002 CEOS – 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, 2002 CEOS – ECHO Services
Web Services
ECHO Client
Service ProviderBind
ECHO Operations
(from Use Case View)
ECHO Service Registry
PublishFind
manages
<<UDDI>>
<<SOAP>>
<<WSDL>><<UDDI Query>>
May 7-10, 2002 CEOS – ECHO Services
Object Model
ServiceDescription<<WSDL>>
ServiceRepository<<UDDI>>
0..n0..n
UserInterface
User
ServiceInterface<<SOAP>>
0..n0..n
Service Provider
(from Use Case View)
Service
May 7-10, 2002 CEOS – 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, 2002 CEOS – ECHO Services
Service Types
Based on ECHO’s responsibility in fulfilling the “binding” interactionFour types Advertise Context-based Brokered Order Options
May 7-10, 2002 CEOS – 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, 2002 CEOS – ECHO Services
User interface version of SOA
UI ProviderECHO ClientBind
<<http>>
ECHO UI Registry
Publish
Find
<<WSDL>>
May 7-10, 2002 CEOS – 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, 2002 CEOS – 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, 2002 CEOS – 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, 2002 CEOS – 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, 2002 CEOS – 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, 2002 CEOS – 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, 2002 CEOS – 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, 2002 CEOS – 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, 2002 CEOS – 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, 2002 CEOS – ECHO Services
Security
Problem: Secure Access – Authentication and
Authorization
Issues: Web Service standards not yet in
place Delegation
top related