The main purpose of geotechnical Web services is to assist in the utilization of geotechnical information by local, state, and federal agencies mandated to develop and sustain our civil infrastructures. For some particular applications, a service may need to control the authentication of the users who want to access geotechnical Web services. Some entry of information into the system database might have to be restricted and controlled to expert members of key organizations. Some other Web services such as data exchange and visualization may not require such stringent security levels and may be anonymously accessed through read-only queries. Some tools (e.g., the Microsoft .NET framework, IBM WebSphere, etc.) may be useful to construct several different levels of a security model for certificate users. Our current GIME prototype does not yet implement fine-grained access control.
Geotechnical. Web. Service...
Functionality. and. Implementation
The three main geotechnical Web services of the system provide a number of specialized methods for programmatic access to the data, and the parameters and variables are described in the GIME WSDL file.8 These methods follow the W3C
Figure 5. The logical organization of the GIME server components (left) and the architecture for the borehole query (BQ) client application (right); the communica- tion between the client and the server is based on the SOAP and HTTP protocols.
Name.of.Component Description
Apache Axis Axis is a Web service middleware that acts as SOAP server and client. Axis handles the task of converting Java objects to SOAP requests when they are sent and received over the network.
Apache Tomcat Tomcat is the official reference implementation for the Java servlet and JavaServer pages technologies. It serves as a servlet engine (mainly for Axis) and a Web server for GIME.
Apache Xalan Xalan is an XSL Transformation (XSLT) processor for converting XML docu- ments into HTML, SVG or other XML document types. It generates on the fly SVG files from XML borehole files.
Apache Batik Batik is a toolkit based on Java. It can be used in Java applications or applets for viewing, generating, and manipulating scalable vector graphics (SVG) format images. Batik library is used in one of our Java client applications for viewing SVG files produced by GIME.
PostgreSQL PostgreSQL is an object-relational database and can be spatially enabled by the PostGIS package. PostgreSQL and PostGIS provide the backend database and spatial functionalities of GIME.
Table 1. Software components and toolkits that are leveraged to build GIME GIME Web Services
HTTP./.SOAP GIME Services.Code
Apache.Tomcat (Web server) Apache Axis (Appl. Server)
Xalan
PostgreSQL+
PostGIS JDBC
Java
Axis.1.0 Batik.1.5 GIME Borehole Query.(BQ)
standardized data-types and structures of the SOAP9 specification to provide an easily-usable interface for client program construction. Web services usually oper- ate from a combination of a Web server and application server; they can be imple- mented using many available tools and libraries. GIME utilizes the open source software components listed in Table 1. The GIME Web server is Apache Tomcat10
Table 2. Description of the GIME application programming interface (API)
Name.of.Function Description.of.Function.
(client.perspective)
Restriction Related..
Web.Service
GeoPutDTD() Upload a new DTD file and update the current DTD on server. Input parameters: a DTD identification number and a DTD file
Super user FSWS
GeoGetDTD() Send a unique identification number of a DTD file and the server returns a string- type object to the client program. Input parameter: a DTD identifica- tion number; return value: a string-type object
All users FSWS
GeoPutXMLFile() Upload a borehole XML file and store it in the server. Input parameters: a borehole XML file name and a borehole XML file
Only in write en- abled databases
FSWS
GeoGetXMLFile() Send a unique identification number of a borehole XML file, and the server returns a string-type object to the client program. Input parameter: a XML file identification number; return value: a string-type object
All users QEWS
GoeQuery() Execute the input query statement which is parsed by this function to select tuples inside tables. All the result tuples are stored in a result structure and returns to the client. Input parameters: query parameters; return value: a result data object
All users QEWS
GeoVisualization() Send unique identification number of a borehole file and display its SVG picture inside a pop- up window. The transformation from XML to SVG format is executed on the fly and the SVG file is rendered in the client. Input parameter: a borehole file identification number; return value:
a SVG file
All users VWS
GeoGetSVGFile() Send unique identification number of a borehole file and returns its SVG file as string type. Input parameter: a borehole file identification number;
return value: a SVG file
All users VWS
and its application server is Apache Axis.11 The application code specific to GIME is embedded within Axis, which is convenient to use; when Tomcat starts, Axis automatically compiles the application codes located in its working directory and generates the necessary object class files. Figure 5 shows the components of the GIME Web services and all the application programming interface (API) methods are listed in Table 2. We now describe the overall functionality and implementation of each GIME Web service.
Geotechnical File Storage Web Service
The geotechnical file storage service provides client programs with an interface to upload their geotechnical XML files into the main database. All files are stored in XML format, and at the same time, meta-data is extracted and saved. The meta-data includes specific elements of the imported files to facilitate querying (described earlier). This service is subject to user authentication because only registered expert users are allowed to make changes to the database. We currently utilize the open source PostgreSQL object-relational database with the PostGIS package. To manage the data we implemented two different paradigms to store XML data. The first one extracts elements of interest from an XML file and stores them in table columns as meta-data. The XML file itself is also stored in its entirety in a column of type XML in the main table. Hence, the meta-data columns can be rapidly accessed when users want to query and retrieve XML information in the database. This second ap- proach to store XML data is to completely decompose the elements of an XML file into columns of multiple tables. The second process is bi-directional, which means that the XML files can be regenerated after individual elements have been updated.
Furthermore, new XML files can be generated from multiple existing tables.