The software architecture is built as a client-server application using Java language and SQL above a set of components such as an HTTP server, a JDBC gateway, a RDBMS server, a data server and a Web browser. Since HTML pages and CGI scripts are not powerful enough to allow user interaction during a multi-instrument catalog search, this type of requirement enforces the choice of Java as the main language. We also discuss performance issues, security problems and portability on different Web browsers and operating systems.
SOHO is a satellite dedicated to the study of the Sun, built as part of an ESA and NASA cooperation. It operates with 12 instruments on-board that produce about 1.5 TB for 2 years of mission. These are operating in the frame of joint observing programs but their data and catalogs are not homogeneous. SOHO scientific and engineering data are currently stored at NASA/GSFC and at MEDOC/IAS (Scholl 1996). The goal of the current joint effort between ESA/NASA and MEDOC teams is to define a unique catalog for all data as well as a unique user interface to access them independently of their physical location. After a common catalog definition (Scholl & Sanchez 1998), the software development was split between the two teams. ESA/NASA team was in charge of the catalog data ingestion programs while, at MEDOC, we designed and developed the software that is responsible for catalog and file access. Because of the international character of this mission, our basic requirement was to develop a software that is independent of the archive architecture and which provides users with web access capabilities. Moreover, the amount of data and their complexity can lead to heavy queries producing a large volume of results. Then, ergonomy, good response time and easy browsing functions were among our main goals.
The catalog access system is pure Java software. It is organized as a 3-tier architecture (see Fig. 1).
The client side is a Java applet while the server side is composed of several stand-alone Java applications.The applet is stored on the HTTP server directory tree to be loadable by the user's Web browser, that must be JDK-1.1 compliant. The client implements the graphical user interface (GUI) functions such as:
The query is built dynamically using a dictionary which is the only part of the software that would be changed if the database structure changes. Each selection enriches the query in order to restrict the set of data (rows) returned.
Once the user has committed his choices, the resulting query is sent to the server which completes it in order to figure out if the data may be accessed by the user. The query is forwarded to the RDBMS via a JDBC driver; the results, received via the same channel, are temporarily stored on the server. Then, the content of the first page can be sent to the client before the end of the transfer. These buffers have several goals: lighten the client, decrease response time, allow the user to browse data by using next/previous (for the same view) and back (for different views) functions without accessing the database each time. Several parameters such as buffer size, number of maximum back operations, etc. can be tuned if necessary regarding the host computer capabilities.
The retrieve operation involves several components at different levels. Figure 2 shows them as well as the sequence of operations necessary for the file retrieval process. The main problem encountered for this part of the software is related to Java security restrictions that don't allow an applet to write on a file system. In order to make the browser to allow this operation, the saving must be done outside the JVM. For user convenience and general security reasons we use an HTTP download instead of collecting login and password from users in order to send files using FTP. The request to the corresponding HTTP server, the save server, is an URL hiding a certificate coming from the transaction server. This ensures that the save server will not deliver the precious data to inadequate persons.
The retrieve process is independent of any kind of storage system: for example, at MEDOC we have implemented an HSM architecture with disks and cartridges while the GSFC has on-line disks.
Our current work aims to get better performances in tuning the database access and result management. Our future works will be oriented to new facilities enhancing current search criteria as well as adding different parameters (like other ground-based or space solar observatories keywords). We will also follow Java evolutions such as JDK-1.2 with JFC which comes with more powerful components that improve performances and should simplify our code (i.e. RMI communications, direct print capabilities, light weight graphical components).
We are grateful to all future users who have tested this software. Special thanks go to Luis Sanchez and George Dimitoglou from ESA-NASA team and Jean-Luc Orcesi from MEDOC team for their technical contributions.
Scholl, I. 1996, in SpaceOps'96 (ESA Publ. SP-394) (Munich: ESA), 384
Scholl, I. & Sanchez L. 1998, ``User Requirement Document for the SOHO Archive'', ftp://ftp.medoc-ias.u-psud.fr/pub/archive/urd.ps