Infrared Astonomy Archive Analysis Environment
The principle purpose of the of the Infrared Science Archive (IRSA) at IPAC is to provide our user communities with efficient access to the data from NASA's infrared astronomical missions. These communities run the gamut from current projects which need the ability to securely insert new data into the archive, to external projects which need to extract data for their own purposes using remote application program interfaces (APIs), to the research community (and the public) who want simple user interfaces to help them locate and retrieve specific datasets.
Like most network data services today, current public IRSA applications are constructed using HTML/CGI technology, where the client submits requests through an HTML form and obtains a static response from server. To extend the interactive capabilities of these services requires an enormous amount of intermediate state management on the server side utilizing "cookies" on the client. The power of this approach is in part that (at least for simple interactions) it involves a minimum of data volume on the network but primarily that it can rely on the fact that everyone already has all the client-side functionality necessary (i.e. a Web browser) to make use of it.
For more complex interactions, however, the same factors that make this approach initially appealing become a liability, often requiring repeated data tranfers and increasingly complex server-side state manipulation. Thus, even for basic archive access services (which are the focus of the IRSA effort) it highly desirable to augment the HTML/CGI approach with more stateful client-server or even multi-tiered components built using JAVA. The architectural advantages of JAVA are often touted and very real, but from a system design point of view perhaps its most significant attribute is that (as with the HTML access mentioned above) it is soon likely to be ubiquitous.
Although IAAAE is entitled an "analysis environment", that description is misleading on two important architectural points. First, the focus of our work is the set of components necessary for interacting with the archive to find and retrieve data. While this can often involve rudimentary data reduction functionality and certainly involves a considerable amount of visualization, we see our work as primarily the "access" components in what we hope will be a more general global environment.
Second, our design is very different from the traditional analysis environments that attempt to encompass everything and forces user and developers to do everything in such a develop environment. IAAAE is taking a completely opposite design approach, the toolkit consists of components written in pure JAVA (and without the huge heirarchy of custom dependancies that often accompany such efforts) that may be used individually, within other applications or in collaboration with each other. This collaboration allows the building of a loosely coupled "analysis environment" for a specific application by means of a optional inter-tool signaling mechanism. This is a very useful yet extremely simple mechanism that allows complex N-way interaction among components without requiring commitment to a large integrated environment.
This approach has also allowed us to avoid "Grand Design" interfaces. While such interfaces hold the allure of swiss-army-knife utility, they often bury the functionality needed for a specific task in scattered layers of pull-down menus and pop-up forms. Even worse, they will often weld together totally unrelated functionality ("its a vacuum cleaner AND a food processor") simply because they can.
Instead, we believe that the correct approach is to build a toolkit of access, visual interaction, and analysis components with which a collection of interfaces can be quickly built, each customized to a specific need. Some of these will be well-thought-out interfaces to a relatively broad set of services but many will be (as our prototype demonstrates) extremely narrow interfaces for a small clientele and limited purpose. "Grand Design" results all too often in lowest common denominator, sacrificing each individual group's needs for a ficticious "everyone".
Simply put, the IAAAE work we have done to date has been proving out the interaction infrastructure paradigm described above. The figure indicates those elements whose development has been support at least in part by the IAE funding. We plan on migrating this functionality into our operational system over the next year and extending and augmenting them as time permits. We also plan to fold in the functionality associated with our Digital Sky and Virtual Observatory collaborations and make this available through this archive access environment as ancillary tools.
In addition to the continued refinement and evolution of the existing tools, we plan to investigate operational mechanisms for dissemination and updating of client components in the real world astronomical research community.