Next: Turning Besançon Observatory On-line Facilities into the VO: Galactic Model Simulation, Binary Star, Molecular Collisional and TNO Databases
Up: Web Services and Publications
Previous: ADS Web Services for the Discovery and Linking of Bibliographic Records
Table of Contents - Subject Index - Author Index - Search - PS reprint - PDF reprint

Waters, B., Benson, J., Cornwell, T., Ye, J., & Douthit, M. 2003, in ASP Conf. Ser., Vol. 295 Astronomical Data Analysis Software and Systems XII, eds. H. E. Payne, R. I. Jedrzejewski, & R. N. Hook (San Francisco: ASP), 313

Web Services in AIPS++

Boyd Waters, John Benson, Tim Cornwell
National Radio Astronomy Observatory, PO Box 0, Socorro, NM 87801-0387

Jason Ye
Brown University, Box 4087, Providence, RI 02912

Melissa Douthit
Computer Science Department, California State University, San Marcos, CA 92096

Abstract:

The ease of distributed computing in AIPS++ has traditionally obviated the need for standard networking components, such as those found in Java, Python, or Perl. However, Glish is able to ``wrap'' arbitrary commands, enabling us to link powerful, Java-based toolkits to Glish's event-based, client-server processing model. We have used this technique to implement a SOAP-based Cone Search web service for the Virtual Observatory. Integration of Java with AIPS++ leveraged industry-standard toolkits, and simplified the code.

1. Motivation and Initial Design

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.

Figure 1: Initial Deployment: Receiving an Archive Query Request. A TCP/IP client/server pair, implemented in Perl and C++, implements the adapter between a web server and AIPS++. (Circles represent processes; grey boxes correspond to host computer boundaries.)
\begin{figure}
\plotone{P2.2_1.eps}
\end{figure}

2. A Web Services-Based Re-Implementation

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?

3. Java/AIPS++ Interoperability Issues

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.

Figure 2: Java Implementation. The Glish adapter handles SOAP clients directly; traditional Web browser clients are handled by an HTTP adapter servlet. (Circles represent processes; grey boxes correspond to host computer boundaries.)
\begin{figure}
\plotone{P2.2_2.eps}
\end{figure}

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!

3.1 Life-Cycle Management: Who Owns the Process?

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.

4. Java Tools

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.

5. Future Work

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++.

References

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



Footnotes

... tools,1
Code is available in the AIPS++ distribution under the code/trial/implement/XML directory.
... enough.2
However, shell clients are limited to a single output event ( stdout) and a single input event ( stdin). Some dispatch code, written in Glish, is used to parse event values as they come in, effectively multiplexing the events into and out of the stdin/out stream events.

© Copyright 2003 Astronomical Society of the Pacific, 390 Ashton Avenue, San Francisco, California 94112, USA
Next: Turning Besançon Observatory On-line Facilities into the VO: Galactic Model Simulation, Binary Star, Molecular Collisional and TNO Databases
Up: Web Services and Publications
Previous: ADS Web Services for the Discovery and Linking of Bibliographic Records
Table of Contents - Subject Index - Author Index - Search - PS reprint - PDF reprint