HR: 1330h
AN: ED32C-1204    [PDF]
TI: Some Programs Should Not Run on Laptops - Providing Programmatic Access to Applications Via Web Services
AU: * Gupta, V
EM: vgupta@usc.edu
AF: Southern California Earthquake Center, 3652 Trousdale Parkway Science Hall, Room 156, Los Angeles, CA 90089 United States
AU: Gupta, N
EM: niting@usc.edu
AF: Southern California Earthquake Center, 3652 Trousdale Parkway Science Hall, Room 156, Los Angeles, CA 90089 United States
AU: Gupta, S
EM: sumit@usc.edu
AF: Southern California Earthquake Center, 3652 Trousdale Parkway Science Hall, Room 156, Los Angeles, CA 90089 United States
AU: Field, E
EM: field@caltech.edu
AF: U.S.G.S, 525 S. Wilson Ave, Pasadena, CA 91125 United States
AU: Maechling, P
EM: maechlin@usc.edu
AF: Southern California Earthquake Center, 3652 Trousdale Parkway Science Hall, Room 156, Los Angeles, CA 90089 United States
AU: Maechling, P
EM: maechlin@usc.edu
AF: U.S.G.S, 525 S. Wilson Ave, Pasadena, CA 91125 United States
AB: Modern laptop computers, and personal computers, can provide capabilities that are, in many ways, comparable to workstations or departmental servers. However, this doesn't mean we should run all computations on our local computers. We have identified several situations in which it preferable to implement our seismological application programs in a distributed, server-based, computing model. In this model, application programs on the user's laptop, or local computer, invoke programs that run on an organizational server, and the results are returned to the invoking system. Situations in which a server-based architecture may be preferred include: (a) a program is written in a language, or written for an operating environment, that is unsupported on the local computer, (b) software libraries or utilities required to execute a program are not available on the users computer, (c) a computational program is physically too large, or computationally too expensive, to run on a users computer, (d) a user community wants to enforce a consistent method of performing a computation by standardizing on a single implementation of a program, and (e) the computational program may require current information, that is not available to all client computers. Until recently, distributed, server-based, computational capabilities were implemented using client/server architectures. In these architectures, client programs were often written in the same language, and they executed in the same computing environment, as the servers. Recently, a new distributed computational model, called Web Services, has been developed. Web Services are based on Internet standards such as XML, SOAP, WDSL, and UDDI. Web Services offer the promise of platform, and language, independent distributed computing. To investigate this new computational model, and to provide useful services to the SCEC Community, we have implemented several computational and utility programs using a Web Service architecture. We have hosted these Web Services as a part of the SCEC Community Modeling Environment (SCEC/CME) ITR Project (http://www.scec.org/cme). We have implemented Web Services for several of the reasons sited previously. For example, we implemented a FORTRAN-based Earthquake Rupture Forecast (ERF) as a Web Service for use by client computers that don't support a FORTRAN runtime environment. We implemented a Generic Mapping Tool (GMT) Web Service for use by systems that don't have local access to GMT. We implemented a Hazard Map Calculator Web Service to execute Hazard calculations that are too computationally intensive to run on a local system. We implemented a Coordinate Conversion Web Service to enforce a standard and consistent method for converting between UTM and Lat/Lon. Our experience developing these services indicates both strengths and weakness in current Web Service technology. Client programs that utilize Web Services typically need network access, a significant disadvantage at times. Programs with simple input and output parameters were the easiest to implement as Web Services, while programs with complex parameter-types required a significant amount of additional development. We also noted that Web services are very data-oriented, and adapting object-oriented software into the Web Service model proved problematic. Also, the Web Service approach of converting data types into XML format for network transmission has significant inefficiencies for some data sets.
UR: http://www.scec.org/cme
DE: 7294 Instruments and techniques
SC: Education and Human Resources [ED]
MN: 2003 Fall Meeting