Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.adass.org/adass/proceedings/adass02/reprints/P2-2.pdf Дата изменения: Wed Mar 12 01:43:45 2003 Дата индексирования: Tue Oct 2 09:47:36 2012 Кодировка: Поисковые слова: water

Astronomical Data Analysis Software and Systems XII ASP Conference Series, Vol. 295, 2003 H. E. Payne, R. I. Jedrzejewski, and R. N. Hook, eds.

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 SOAP1 -based Cone Search2 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" Pro ject (Cornwell, this conference). It is implemented as a series of Glish scripts, which implement queries to the AIPS++ Table System.3 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.4 The applet opens a socket and talks to a stand-alone, C++ program; this C++
1 2 3 4

http://www.w3.org/2000/xp/Group/ http://www.us-vo.org/metadata/conesearch/ http://aips2.nrao.edu/docs/notes/199/199.html http://aips2.nrao.edu/vla/calflux.html

313 c Copyright 2003 Astronomical Society of the Pacific. All rights reserved.


314

Waters, Benson, Cornwell, Ye & Douthit

Apache Web Server
CGI Request

Perl CGI Proxy
TCP/IP Socket

C++ Glish Adapter
Glish "CGI" Event

Glish Query Parser
Glish "DoQuery" Event

AIPS++ Table Server

NRAO Data Archive

Web Server

AIPS++

SAN

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.) 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. 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 Descriptors5 to each column. Once this mapping was understood, we used a nice set of Glish XML tools,6 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.
5 6

http://cdsweb.u-strasbg.fr/doc/UCD.htx Code is available in the AIPS++ distribution under the code/trial/implement/XML directory.


Web Services in AIPS++
Web Browser
HTTP Request SOAP REQUEST

315

Java Servlet SOAP Client

Java Glish-SOAP Adapter
Glish "CGI" Event

Glish Query Parser
Glish "DoQuery" Event

AIPS++ Table Server

NRAO Data Archive

Web Server
SOAP REQUEST

AIPS++

SAN

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.) We were able to replace the C++ socket-server implementation with a Java command-line program wrapped with the Glish shell function.7 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.8 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.
7 8

http://aips2.nrao.edu/docs/reference/Glish/node60.html 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.


316 4. Java Tools

Waters, Benson, Cornwell, Ye & Douthit

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 Toolkit9 to suit these requirements. We used Apache Tomcat10 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

9 10

http://www.themindelectric.com/ http://jakarta.apache.org/tomcat/index.html