A Web Services Solution for Work Management Operations
By Venu Kanaparthy and Charles O'Hara
The GeoResources Institute at Mississippi State University is leveraging spatial technologies and Web-based services for addressing rural septic system problems. Current methods are inadequate for mapping and managing wastewater resources and executing work management operations.
This article presents an Open GIS Web services architecture for providing a streamlined work flow for wastewater work and utility management operations. A mobile GIS solution was developed with ArcPad for supporting work order query, download, and update services. The Microsoft .NET framework is utilized to provide services to mobile applications. A desktop application implemented with MapObjectsJava Edition supports services such as parcel finding, querying utility maintenance history, map view, work order creation, and redline feature operations for field inspection.
The work management operations and feature characteristics of wastewater utilities are modeled with GML schemas standardizing the structure and content of geographic information for validation and use. This enabled spatial data interoperability with both desktop and mobile GIS applications.
Geographic data is critical to applications that need to view, query, edit, and update information from different locations to achieve business objectives. Traditionally, GIS applications were limited to desktops running GIS software for displaying and querying geographic data that was often stored in a spatial database. With the introduction of mobile devices, a desktop GIS system could be extended to any remote location providing easy, accurate, and efficient methods for remote data access, but the data was still stored and transported in proprietary formats. As a result, only certain GIS software packages and databases could read and store the geographic datasets respectively.
Organizations developed different data models and structures to support their business purpose, resulting in diverse data formats and software packages to interpret them. Some data formats are proprietary and can only be read by certain software packages. To be usable with diverse GIS software products, data conversion tools are required. Their development costs time and money. This not only limits the GIS data interoperability but also places the constraint on software packages and spatial databases to be used for developing the user application itself. The ability to use a dataset across multiple user applications is interoperability.
Often desktop and mobile applications that need data may not be able to utilize a dataset because of its proprietary structure. An approach to provide data conversion from a proprietary format to one usable by applications is the first step toward providing data interoperability. Esri has been a key player in promoting and implementing geographic data interoperability standards, resulting in data conversion tools, simple feature specification for SQL and OLE/COM, and direct data access APIs such as the ArcSDE APIs in Java and C. Esri products, such as ArcWeb Services and the ArcGIS Data Interoperability extension, implement Web services technologies to provide data interoperability support.
Interoperating mobile and desktop applications provides a significant step toward field data availability. Different levels of data interoperability depend on the level of knowledge about the dataset provided to user applications.
The levels of interoperability are structural, schematic, and semantic. At the structural level, basic meta information about the dataset is available (e.g., Esri ArcIMS image services provide information on the spatial extents, width, and height of an image but do not provide details on how to query an image for extracting some features). At the schematic level, explicit knowledge of the structure of the data is provided in the form of a schema (e.g., the Describe Feature Type operation in OGC Web Feature Service provides the schema information as XML to user applications). The schema describes the geometry and feature attributes associated with a dataset such as XMML, ESML, and LandXML (XML subsets used to represent geology, mining, and earth science datasets, respectively). At the semantic level, agreement on a common vocabulary to represent geographic entities is required. Ontologies are required for this purpose.
This article presents a Web services framework for providing interoperable spatial data services. An interoperating spatial data service provides services such as data access, query, editing, and conversion (spatial services or geoservices) to remote desktop and mobile user applications. The user applications using such a service are not constrained to use a specific software product or platform.
Geography Markup Language
Geography Markup Language (GML) is an XML-encoded format for representing and storing the structure and content of geographic features. GML is an Open Geospatial Consortium ?(OGC) standard, primarily targeted at addressing geographic data interoperability among GIS applications. Since GML uses XML encoding, it inherits all the features such as extensibility, interoperability, and human readability. GML is an open source data exchange standard and, hence, freely available to everyone. GML-encoded information is portable and can be transported over the Internet to diverse applications on desktop and mobile platforms.
Using GML data does not require an investment in complex and expensive software. Esri provides extensions in ArcIMS and ArcExplorer for accessing geographic data from GML data sources. GML can be used to store and transport geographic features over the Internet to remote GIS applications including those on mobile devices.
GML can be used to represent spatial and nonspatial aspects of geographic features. Feature characteristics, such as topology, routing, units, and measurements, can be captured. GML also provides schema documents for modeling feature attributes and geometries. For example, wastewater features, such as manholes, sewer lines, and pumps, can be modeled in GML.
Likewise, application objects or entities, such as intersections, drill holes, and work orders, can be modeled from GML schemas. The application schema represents the structure or placeholder for data that will be populated during the data exchange operation. The application schema is used by an organization or applications interested in sharing geographic information. Communities interested in sharing geographic information in GML can custom develop GML schemas based on data requirements as is the case with ESML and XMML. The use of an OGC standard format, such as GML, to model the geographic information structure will provide increased interoperability across multiple GIS systems.
Understanding Web Services
Web services are reusable software components that can be published, discovered, and invoked over the Internet. They are built around a set of industry-based protocols such as XML, Simple Object Access Protocol (SOAP), and Web Service Description Language (WSDL). Web services extend client/server architecture by enabling broader accessibility to diverse applications and reusability of the Web components delivering the functionality.
Web services are the latest approach for delivering data and geoprocessing services to diverse user applications. ArcWeb Services are based on Web services.
Three major components of the Web services framework are service registry, service provider, and service user. The service registry is a searchable online catalog and is utilized by a service provider to publish a service. The service provider is an entity or organization willing to provide data or geoprocessing services. Service users are organizations or persons with a need for data or processing services. Typically, a user with a specific data or processing requirement can query a service registry for a service provider offering the desired data. After locating a service provider, the user application can send a request for the required datasets.
A service provider creates a service description using a WSDL document that contains a list of spatial or nonspatial operations supported, data types exchanged, and location of the service. Using a WSDL document, user applications can create requests to the service provider. SOAP is utilized for data exchange between service provider and user. SOAP provides XML envelope structure and data encoding rules to transport data between applications. XML data transport makes the SOAP message platform independent. Encoding rules provide mapping mechanisms from application or data objects to equivalent XML data types as illustrated by the SOAP message requesting image with a GetImage operation shown in Figure 1.
Figure 1: SOAP message requesting image with a GetImage operation
|<?xml version='1.0' encoding='UTF-8' ?>|
<s:Header>Routing, security & session control</s:Header>
<e:parameters width="500" height="350"
This article describes an approach for providing spatial or geographic data services to diverse user applications by leveraging industry standards such as Web services and GML. For GIS applications to share data, a common data model is required. The data model defines various geographic entities, their geometry, and feature attribute characteristics. A common data model is developed using a GML application schema that models the shared geographic entities. Figure 2 shows an application schema representing a manhole feature.
Figure 2: An application schema representing a manhole feature
<xs:element name="mh_code" type="xs:string"/>
<xs:element name="fitt_type" type="xs:string"/>
<xs:element name="elev" type="xs:float"/>
<xs:element name="map_" type="xs:string"/>
The application schema provides user applications with explicit knowledge of the structure (i.e., geometry and feature attributes) of the dataset. After agreeing on the application schema that will be used to share geographic information, a service provider can start defining the service interface using WSDL. The service interface provides the operations supported such as subset, query, and buffer; the input/output message for each operation; and the data types sent with each message. Additional information about the protocol (HTTP, SOAP, SMTP, and JMS) used for transport and the location of the service (i.e., the URL) are required.
Continued on page 2