 |
|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass02/P2-2/
Дата изменения: Thu Mar 13 02:27:56 2003 Дата индексирования: Tue Oct 2 04:04:10 2012 Кодировка: Поисковые слова: images |
The NRAO on-line data archive is part of NRAO's ``End-to-End'' Project (Cornwell, this conference). It is implemented as a series of Glish scripts, which implement queries to the AIPS++ Table System. The actual data files are stored on our multi-terabyte Storage-Area Network (SAN).
We wished to provide archive data via a web browser, which meant that we needed to implement a web server process that could interact with the AIPS++ Table system.
With the addition of a ``business logic'' layer between our user form and the ``raw'' tables, we were able to re-use a TCP/IP table-data socket server that Wes Young had developed for use by his VLA Calibrator Flux applet. The applet opens a socket and talks to a stand-alone, C++ program; this C++ program acts as a stand-alone, ``table data server'' (called atabd) for the applet. A slight modification of Wes' atabd could accept web form data from a Perl CGI script over a TCP/IP connection, and return an HTML string that was in turn presented to the web browser.
|
The ability to browse the on-line NRAO database is a great boon to our data analysts, but real utility will be realized when this data can be aggregated with other astronomical data sources and manipulated by our image-processing systems.
A first step was to map our catalog information, our meta-data, onto the VOTable format, with particular attention to the proper attribution of Unified Column Descriptors to each column. Once this mapping was understood, we used a nice set of Glish XML tools,1 written by Ray Plante at NCSA, to emit a VOTable directly from our AIPS++/Glish scripts.
Once we had simple XML output capability, we considered XML input; we wished to receive archive query requests from other computer processes. Clearly, we needed a SOAP framework; SOAP is exactly an XML messaging system primarily based upon HTTP. Writing our own SOAP framework in Glish, based on Ray's XML toolset, was possible. But why do so, when the entire computer industry is providing these tools for us?
For this experiment, we decided to focus on Java tools, as the rapid-development aspects of Java were a nice match to our team's expertise, and a nice complement to Glish.
 |
We were able to replace the C++ socket-server implementation with a Java command-line program wrapped with the Glish shell function. The shell function logs any Unix command onto the Glish Event bus by mapping the stdin and stdout streams: Java raises an event to the Glish/AIPS++ system simply by printing to stdout, and receives event values from AIPS++ by accepting data on stdin. Since XML messages are simply string values, this approach works well enough.2
Re-implementing the server in Java gave us Java as the socket client, and the socket server. It was theoretically possible to replace the simple socket messaging scheme with Java RMI, but the complexity of Java RMI deployment stymied our efforts. Currently, we use the same SOAP messaging scheme to talk between the web service front-end and the Java/Glish back-end that we use for other services. Therefore, the Glish ``back-end'' became our SOAP server: SOAP is the default, and traditional, HTML web servers are a special front-end!
We had intended to re-engineer the C++ server at some point; as written, it cannot handle more than one client. This is because the C++ server is launched from an AIPS++/Glish process; AIPS++ controls the lifecycle of the process. We were not able to create a process that forks upon accepting a socket connection, as such a system confused the parent AIPS++ process.
Upon implementing the web front-end, as well as the Glish socket adapter in Java, we had Java on both ends of a socket connection. It would seem that we could do away with this socket approach entirely, and have a monolithic system that integrated the web facade and the Glish query server. But life-cycle issues are still there: the web server (or web service framework) is parent to one of the processes, and AIPS++ is parent to the other. In order to keep our system manageable, we kept the ``front-end''/``back-end'' split.
Since we had our framework essentially in place, we were looking for a relatively lightweight Java implementation of SOAP; we wanted the minimum necessary to instantiate and send a SOAP Message. We found that the GLUE Toolkit to suit these requirements.
We used Apache Tomcat for our web server front-end.
The remote procedure call approaches discussed here are very similar to what Glish already does very well: optimized, socket-based distributed computing (Schiebel 2000). A much better approach would be to implement the Glish messaging protocol, SOS, in 100% pure Java.
We also wish to implement web services clients that leverage the visualization and astronomical-processing capabilities of AIPS++.
Schiebel, D. R. 2000, in ASP Conf. Ser., Vol. 216, Astronomical Data Analysis Software and Systems IX, ed. N. Manset, C. Veillet, & D. Crabtree (San Francisco: ASP), 39