# Presentation: 372564

## Evolving SPDF/SECAA Active-Archive Multi-Mission Services in the Era of Virtual Observatories and LWS

- R E McGuire1, R M Candey1, R A Chimiak2, D Han2,  B T Harris2,
- R C Johnson3, C Klipsch3,T J Kovalick3, H A Leckner3, M. Liu4
- 1Code 630, 2Code 580, 3QSS/Code 630, 4Raytheon/Code 630
- NASA's Goddard Space Flight Center, Greenbelt, MD 20771

## Multi-Mission Services Today(cf. http://spdf.gsfc.nasa.gov)

- CDAWeb:  Easy data browse and display, user-specified time and parameter subsets with graphics, listings, file downloads
- Data from most currently-important SEC missions
- SSCWeb: Multi-mission orbits, with graphics and conjunction logic for coordinated science planning
- OMNI2:  Field, plasma, particle hourly avgs at 1 AU
- CDF standard data format 			and associated software
- Data format translations
- ModelWeb:  Information, 			codes, execution I/F

## Unique Community Resources
Scope of CDAWeb data holdings and multi-mission service
Nature of SSCWeb database and unique functions supported
OMNI2 database as near-Earth 40- year interplanetary baseline
CDF supports multiple programs (including planned STEREO and THEMIS)

Citations to services & data (with NSSDC, >107 in 2003)
Resources are heavily used (plots, lists, files, queries)
Many regular distinct science users:  e.g. ~900 CDAWeb 		
International sharing of data (including CDAWeb mirror sites)

Variety of technologies
FTP access plus S/W (e.g. CDAWLib and CDFX)
Html-based user I/F
Web-services application I/F
New Java-based clients (with Webstart installations)

- Scope of CDAWeb data holdings and multi-mission service
- Nature of SSCWeb database and unique functions supported
- OMNI2 database as near-Earth 40- year interplanetary baseline
- CDF supports multiple programs (including planned STEREO and THEMIS)
- Citations to services & data (with NSSDC, >107 in 2003)
- Resources are heavily used (plots, lists, files, queries)
- Many regular distinct science users:  e.g. ~900 CDAWeb
- International sharing of data (including CDAWeb mirror sites)
- Variety of technologies
- FTP access plus S/W (e.g. CDAWLib and CDFX)
- Html-based user I/F
- Web-services application I/F
- New Java-based clients (with Webstart installations)

- Years 1990-2010

- CDAWeb Data Sets
-  (~240 total datasets in this overview, one row per dataset)

- _Missions include_
- ACE
- Cluster
- FAST
- Geotail
- GOES
- IMAGE
- Interball
- LANL
- Polar
- TIMED
- Ulysses
- Wind

## SECAA Services in the Context of VxOs

- Virtual Observatory (VO) paradigm for Sun-Space-Geospace research community might be defined as a vision of a future Solar-Terrestrial data environment
- Where data, models and services can be highly distributed
- While end users see an integrated view, and where
- All potentially-useful data are readily findable, accessible, useable
- With appropriate services and across mission-instrument boundaries
- VO is similar to the Virtual Space Laboratory concept proposed several years ago as a Roadmap effort
- VxO strategy to build the new data environment by leveraging existing capabilities, while those capabilities evolve in turn to talk to the new data environment
- Want a flexible long-term architecture delivering over time the best services at the lowest effective cost
- Technology => hybrid solution with both distributed and centralized service elements whose mix will change

## Short-Term Plans

- Retain (+build) excellence & utility of what works now
- Must maintain performance and reliability
- Access to more 				(& higher quality/content) 				(& distributed) data
- New services 					(e.g. FTP Data Finder), 				functions and I/F flexibility
- Data, models, and services through multiple paths
- FTP (files+s/w), service user-I/Fs (html, Java), Web Service APIs
- Data and capabilities available to early SEC VxOs
- Via Web Services with XML/WSDL-SOAP for communications,  URL pointers to result files (data files or service products)
- Exploit these extensions directly (Java-based clients, using WebStart for easy installation e.g. SSCWeb 3D interactive plots)
- Support mapping to evolving SEC data dictionary (SPASE effort)
- Enable and partner in the various VxO efforts
- Data format translation and other enabling services
- Data/service "provider" (and “consumer”) to larger VxO environment
- Expect framework and participation will evolve to a range of cooperative and innovative partnerships (e.g. VITMO conversation)
- VO concept should be empowering
- Wider range of data with much deeper analysis capabilities
- Wide range of service approaches
- E.g Many interfaces and services evolving over time that are "easy to prove" by attaching to full data environment
- Multi-source data coupled to display, models and analysis,
- Including accessible computing power

## Virtual Observatory Technical Questions, Concerns and Personal Observations

- Technology is only one part of making the right data fully accessible to the required user community
- Resource and cultural issues must have ongoing attention
- Full data requirements to accomplish a science program (e.g. LWS) needed center-stage early & within effective data policy framework
- Software is only one part (if perhaps the most fun) of the problem
- Primary consideration in implementing Virtual Observatories must be effective and adequate service to the end users of the data
- Users need ability to perform a full range of functions
- Users need to be able to accomplish functions quickly
- Users need to be able to perform functions predictably
-  What worked yesterday should work today
- Software libraries and simple file finding/retrieval can offer high functional (analysis) capabilities
- But software ... takes time to install and learn to operate
- May not readily integrate data from different sources
- May have issues with platforms and reliance on commercial s/w
- Many users want/need more than simple file finding and retrieval (even with supporting s/w)
- And need functions across mission / dataset boundaries
- Higher-functions hard with too much heterogeneity
- Metadata standards vital; data format standards still important

## Not everything may make sense to distribute
User “wall-clock”time is the most valuable commodity 
Plus development and maintenance resources of couse
WAN transfer times are still a design issue
Often better to store multi-source data at the service host
Data service architecture with almost all work done at the server end and talking to thin (very basic browser) clients is fairly robust
Can be made to work almost every time for almost everybody
”Duplicated" disk storage is one more tool (and OK if it works)
Can allow less complex s/w development and maintenance
Allows work offline preparing diverse data for common service

NASA science research community uses (and will use) many distinct operating systems (and versions), hardware and software platforms
Complex functionality built on distributed data and smart desktop clients will present cross-platform and maintenance challenges 
E.g. Web services to talk to both Java and .NET clients
E.g. Testing for client development and  support for easy installation across multiple platforms
E.g. Deployed web services infrastructure may become hard to change or evolve (as technology evolves, as new requirements are identified) as more clients are developed
We‘re changing our web service I/F but are you able/willing to change your client as we change and evolve over time?   

KISS will always be important for effective services, software installation/operation and interfaces
Critical future science from a diverse research community
Options for a few “power” users will confuse many “novice” users
We are ALL novices more times than we might care to admit
Can there be too much data and too much capability to use?

- User “wall-clock”time is the most valuable commodity
- Plus development and maintenance resources of couse
- WAN transfer times are still a design issue
- Often better to store multi-source data at the service host
- Data service architecture with almost all work done at the server end and talking to thin (very basic browser) clients is fairly robust
- Can be made to work almost every time for almost everybody
- ”Duplicated" disk storage is one more tool (and OK if it works)
- Can allow less complex s/w development and maintenance
- Allows work offline preparing diverse data for common service
- NASA science research community uses (and will use) many distinct operating systems (and versions), hardware and software platforms
- Complex functionality built on distributed data and smart desktop clients will present cross-platform and maintenance challenges
- E.g. Web services to talk to both Java and .NET clients
- E.g. Testing for client development and  support for easy installation across multiple platforms
- E.g. Deployed web services infrastructure may become hard to change or evolve (as technology evolves, as new requirements are identified) as more clients are developed
- We‘re changing our web service I/F but are you able/willing to change your client as we change and evolve over time?
- KISS will always be important for effective services, software installation/operation and interfaces
- Critical future science from a diverse research community
- Options for a few “power” users will confuse many “novice” users
- We are ALL novices more times than we might care to admit
- Can there be too much data and too much capability to use?

- Contact information:      _[mailto:robert.e.mcguire@nasa.gov](mailto:robert.e.mcguire@nasa.gov)_