| GISdevelopment.net ---> GITA 2003 ---> E-Biz |
Chaining GIS Web Services
Nadine Alameh
Global Science & Technology 7855 Walker Drive Suite 200
Greenbelt, MD 20770
Nadine Alameh
Global Science & Technology 7855 Walker Drive Suite 200
Greenbelt, MD 20770
Abstract
The Web services model is rapidly materializing within the Geographic Information Systems (GIS) field. An emerging GIS Web services architecture is enabled by the advancements in general Web service technologies and the focused efforts of the Open GIS Consortium in defining XML-based GIS service and registry information models. Based on these models, this paper addresses the issues of service chaining, the process of combining or pipelining results from several complementary and interoperable GIS Web Services to create a customized solution. The paper presents three basic service chaining options: client-coordinated, static and mediated chaining. Highlights of key Web technologies that can support dynamic service chaining and a discussion of the current limitations of these technologies are also included.
Introduction
Over the last decade, GIS technologies have evolved from the traditional model of standalone systems with spatial data tightly coupled with the systems used to create them, to an increasingly distributed model based on independently-provided, specialized interoperable GIS Web Services (Alameh 2001). This evolution was fueled by the growing role of GIS in today’s organizations, the increasing availability of spatial data and its inherent conduciveness to reuse, the maturity of Web and distributed computing technologies, and the key role of GIS in a promising location-based services market. Furthermore, given that most users of traditional GIS systems typically only use a small percentage of their systems’ functionalities, the services model promises to provide these users with just the services and data that they require, hence bypassing the need to install, learn or pay for any unused functionalities.
Within the GIS domain, GIS Web Services are rapidly materializing as a result of the advancements in general Web service technologies and the focused efforts of the Open GIS Consortium (OGC) in sponsoring consensus-based development of interoperable GIS Web service interfaces (OGC 2002). Soon, it will be possible to dynamically assemble applications from multiple GIS Web services for use in a variety of client applications. This dynamic assembly of services is the motivation behind studying service chaining in this paper. Service chaining is the process of combining or pipelining results from several complementary services to create customized applications.
After an overview of GIS Web Services, this paper discusses three basic service chaining options: client-coordinated, static and mediated chaining. Each option is examined with respect to its coordination complexity, metadata tracking ability and error handling propagation. Next the paper highlights key enabling Web technologies as well their current limitations in meeting the unique needs of the GIS data and services community.
Overview of GIS web services
Web Services are “modular applications that are self-describing and that can be published, located, and invoked from anywhere on the Web or within any local network based on open Internet standards” (Cauldwell 2001). Web Services provide a new of set of technologies that can be used to either expose existing applications or build new distributed applications that work across the Internet. Web Services typically provide access to sets of operations across standardized interfaces and are accessible via ubiquitous Internet protocols such as HTTP or SMTP. Being entirely based on XML technologies, they provide more flexibility and ubiquity that help set them apart from previous middleware technologies. Currently, more businesses are increasingly exposing their underlying applications as Web Services because of these services’ promise to reduce development and deployment costs, decrease the complexity of system design, and increase interoperability among applications and business partners.
According to the OGC framework (OGC 2002), GIS services are logically grouped into three categories:
- Data services are typically tightly coupled with specific data sets and offer access to customized portions of that data. Examples of data services include the OGC Web Mapping Service (WMS) which produces status maps as visual representations of geospatial data, the OGC Web Coverage Service (WCS) which provides access to unrendered geospatial information as needed for client-side rendering, and the OGC Web Feature Service (WFS) which allows a client to retrieve geospatial data encoded in Geographic Markup Language (GML) (OGC 2002).
- Processing services are not associated with specific datasets. Instead they provide operations for processing or transforming data in a manner determined by userspecified parameters (Alameh 2001). Such services can provide generic processing functions such as projection/coordinate conversion, rasterization/vectorization, map overlay, imagery manipulation, or feature detection and imagery classification.
- Registry/catalog services are used to classify, register, describe, search, maintain and access information about Web services (OGC OWS1 2002). Registries can specialize in the type of information they describe, leading to the availability of registries for cataloguing data types, online data instances, service types and online service instances.
Motivation for service chaining
With access to interoperable and autonomous GIS Web Services, a variety of applications can more easily integrate and make use of geospatial technologies. Those applications can be based on traditional information and GIS systems, but can also easily extend to thin clients such as web browsers and newly emerging clients such as handheld devices. For a typical GIS application, multiple GIS and non-GIS Web Services need to be combined or chained. Figure 1 shows a typical service chaining scenario where several GIS coverages are fetched from WCS services, mosaicked and portrayed using a Coverage Portrayal Service (CPS). A processing service then re-projects the resultant coverage to another Spatial Reference System (SRS). The coverage is then overlayed with feature data extracted from a WFS, and then portrayed as a rendered map to the client. Information on WCS, CPS and WFS can be found on the OGC webpage (OGC 2002).
Figure 1. A Simple Service Chaining Example.
This paper explores three basic alternatives for efficient and practical dialogs that occur among the chained services as well as between the services and the calling client. As expected, a number of issues surround the design and implementation of such dialogs. The section below highlights the subset of these issues that are considered to be the most relevant to the specific case of chaining GIS Web Services. This subset covers
- The degree of transparency to the client of the service chaining complexities and the amount of coordination required by the client to construct, execute and manage service chains.
- The alternatives for keeping track and relaying to the client the sources of geographic data used in a service chain and the transformations that were applied to the data along the chain. Keeping track of metadata is particularly important in the case of GIS as typical GIS data users often cannot use that data unless they have some information about its resolution, ortho-rectification parameters, remote sensing origin, etc.
- The alternatives for handling and reporting errors along a chain to the client. Precise error reporting is critical when one or more services along a chain break or return an exception.
This section discusses three basic alternatives for chaining GIS Web Services: clientcoordinated, static and mediated chaining. Each option is examined with respect to the issues presented above.
Client-Coordinated Service Chaining
In the simplest case, service chaining is fully transparent to the client: The client defines and controls the order of execution of individual services in a chain. Although the client does not necessarily have to know a priori the syntax of each service request (see section on WSDL), this type of chaining still requires the client to know about the types of services needed for a particular operation. Using this a-priori knowledge of the types of services needed, the client can access one ore more registries to find service instances to use for a certain request (Nebert 1999).
A practical way for a client to chain various services is achieved by having the client directly embed, in the input of one service, a request to the following service. The quintessential example (shown below) is that of a WMS which symbolizes feature or coverage data stored in a remote WFS or WCS using an SLD specified by a URL. The request to the underlying WFS is embedded within the WMS request.
http://yourfavoritesite.com/WMS?
VERSION=1.0.5&
REQUEST=GetMap&
SRS=EPSG%3A4326&
BBOX=0.0,0.0,1.0,1.0&
SLD=http%3A%2F%2Fmyclientsite.com%2FmySLD.xml&
WIDTH=400&
HEIGHT=400&
FORMAT=PNG&
REMOTE_OWS_TYPE=WFS&
REMOTE_OWS_URL=http%3A%2F%2Fanothersite.com%2FWFS%3F
While nesting calls may simplify some of the client’s coordination responsibilities, it nevertheless introduces complexities in the areas of error and metadata propagation as well as the client’s ability to control certain details. Consider for example the case of the WFS service issuing an exception in response to an erroneous call from the client. This exception will in turn trigger the WMS to signal an "invalid input" exception. With larger chains, a domino effect ensues, as the same problem occurs over the remaining links of a chain. Consequently, a mechanism is needed to embed the source and/or cause of an exception as delivered to a client. One alternative mechanism consists of allowing a service to automatically forward a received exception input, as is, to the next service in the chain; while appending to the forwarded exception any of the service's own error messages. In this context, representing exceptions in XML is particularly useful as it makes it easier for services to detect and add to incoming exceptions.
Moreover, consider the issue of an unexpected delay occurrence in one of the chain’s services. The serial nature of the chain implies that the delay propagates through the chain, and all the way to the client. In the scenario where the client directly accesses each service, the client can abort the operation if a specified time-out period for a service expires. The client may then find a substitute for the timed-out service. However, with nested calls, a global time-out, controlled by the client and communicated to every service, is needed. At any point, if a service takes longer than this global time-out, it aborts and returns an appropriate exception to the preceding service in the chain. In order to hide some of the complexity of service chaining, many service providers provide complementary services as one aggregate service.
Static Chaining using Aggregate Services
With aggregate services, chaining is totally opaque to the client. Aggregate services bundle static (pre-defined) chains of services and present them to the client as one. Such services handle all the coordination of the individual services used. In the case of the WMS/SLD/WFS example, the client does not need to worry about the access to an underlying WFS. Similarly, if a WMS that provides data in one SRS was chained to a Coordinate Transformation Service (CTS), the client doesn’t need to know that the map was projected by that service behind the scenes.
Despite their benefits, aggregate services have some drawbacks. By having a single access point to the chain, the client loses the flexibility and control over the individual services’ parameters. In the example, the client has no control over which WFS is used or which re-projection algorithm is applied. In fact, the client may not even be aware that the image is being re-projected. Not being able to control the parameters of the reprojection can be problematic for GIS users as their applications are often dependent on data quality and resolution. Clients should be able to differentiate between basic and aggregate services, which is why, within OGC, service descriptions (or capabilities files) include a flag that indicates whether a service is an aggregate (or cascading) service. The next section introduces workflow-managed service chaining which aims at striking a balance between the opaque and transparent service chaining alternatives.
Workflow-Managed Service Chaining with Mediating Services
With workflow-managed chaining, aggregate services are replaced by smarter mediating services that act as gateways to other services by coordinating between multiple services without necessarily storing any data of their own. The client may execute the chain himself or just select a chain to be executed by the mediating service. The concept of mediating services is borrowed from the database arena (Litwin 1990), where mediating elements, also known as facilitators, brokers and dispatchers (Wiederhold 1999), dynamically convert multi-database queries into smaller sub-queries that can then be dispatched to the various databases. The results of the sub-queries are then integrated by the mediating element and returned to the client.
Correspondingly, in a distributed geo-processing infrastructure, mediating services dynamically construct and manage chains of GIS Web services. Based on client's requirements, mediating services determine appropriate data sources and services, retrieve and process the data, and then assemble the final response. In order to that, they match the outputs of one service to the inputs of another service. In order to find services needed for a certain process, a mediating service may consult with available catalogs, search engines or meta-search tools. It may also keep its own indexed lists of useful services, which are more likely to be biased towards certain providers and/or domains. For efficiency purposes, mediating services may also provide commonly used functions, such as format, coordinate or vector-to-raster conversions.
Mediating services use pre-specified client preferences to search for appropriate data and processing services that best meet their clients' requirements. Such preferences might include information about service time-outs, price ceilings, accuracy/mapping quality requirements, or preference for a particular service provider. The client may also impose a constraint that all services used in a particular session be supplied by the same provider, presumably to achieve performance or monetary efficiencies. With the wide range of possible GIS applications and the different semantics needed in different fields, the mediating services internal rules are likely to be tuned to specific application domains (such as transportation) or processes (such as image processing). The need for domain or process-tuned services will constitute excellent market entry opportunities for third party players with significant expertise in a domain, but with no capabilities to single-handedly offer and maintain all the data and transformations needed for that domain.
Despite promising to simplify the service chaining process, the truth is that mediating services are inherently complex and challenging to design, especially in light of the continuously evolving underlying technologies. In order to ensure proper construction and execution of chains according to clientspecified requirements, mediating services need to use carefully-designed mechanisms to obtain and refresh client configuration parameters. In this context, issues arise as to how such parameters are specified, and how frequently they are refreshed. Options include having each client register its preferences with a mediating service a priori, or having each client store a local version of its preferences that is easily accessed by the mediating service.
Moreover, the fact that chains are created dynamically by the mediating services may create some inconsistencies in the responses received by the client. Given the dynamic formation of service chains, there is no guarantee that a given request would always garner the same response. For instance, using two different re-projection services in two different executions of the same request may result in maps that have different resolution and quality attributes. Whether this is acceptable to the client depends on the nature of the client and its application. One way to overcome such a problem involves storing, at the client, a cookie containing the details of an executed service chain. Such a cookie and enclosed service chain can be used by the mediating service in future requests. In summary, mediating services promise to reduce the transparency of service chaining to the client. However, by requiring a certain degree of intelligence and continuously requiring update, they may be challenging to design and implement. Fortunately, service providers can leverage general Web Services technologies such as the ones described below to provide “smarter” aggregate and mediating services.
Enabling XML Technologies
Many XML-based technologies can be used to enable or support GIS Web services and pave the way for future enabling automated chaining of these services. They help with automatic web service invocation, automatic discovery and automatic composition. This section highlights some of these technologies with an emphasis on how they can be used and what their limitations are with respect to the requirements of the geospatial community.
Web Services Description Language (WSDL)
WSDL (W3C 2001) describes Web services as a set of endpoints operating on messages containing either document or procedure-oriented information. WSDL provides a way to describe the messages and operations in an abstract way and bind them to a concrete protocol and message format.
A Web service described with WSDL enables programs, also known as proxy generators, to automatically construct a request to that service. By not requiring the calling party (client or mediating service) to know a priori the interface to any WSDL-described service, WSDL makes both transparent and workflow-managed chaining easier to implement. Furthermore, the description of input and output messages of each service’ portType in WSDL facilitates the matching on inputs and outputs by mediating services, hence facilitating the process of constructing service chains of complementary services. However, it should be noted that in the case of GIS services, describing the service interface is often not enough. In a data-centric field such as GIS, a mechanism is needed to describe the characteristics of the data that each GIS service can serve or process. Within the OGC, this is currently achieved by requiring each GIS Web service to support a getCapabilities operation which returns, among other information, details about the data supported by that service.
Universal Description, Discovery and Integration (UDDI)
The UDDI specification (OASIS 2002) enables businesses to quickly and dynamically find and transact with each other. It is introduced here as an alternative for implementing GIS Web service catalogs. It provides a registry for registry businesses and the services they offer. A web service provider registers its advertisements along with keywords for categorization (tModels). The search mechanism relies on pre-defined categorization through keywords, looked up by name or standard taxonomy as used within a certain industry.
The major obstacle slowing down the adoption of UDDI within the geospatial community is attributed to the fact that UDDI registries do not currently support any type of spatial queries. With spatial queries being at the heart of any GIS application, the ability of not being able to search for services or data by bounding box constitutes a real limitation for users. It remains to be seen whether future versions of UDDI will support such functionality.
Simple Object Access Protocol (SOAP)
SOAP (W3C 2000) provides a simple and light-weight mechanism of exchanging structured and typed information between peers in a decentralized distributed environment.
Of particular relevance to service chaining is the SOAP actor attribute in the SOAP header which provides a mechanism for applications to specify the ultimate destination of a message as well as any intermediary services that can partially process the message and then forward it to another actor. Such a mechanism can be highly leveraged by mediating services in their process of creating dynamic service chains.
DAML-based Web Service Ontology (DAML-S)
DAML-S (DAML 2002) is a DAML-based Web service ontology which supplies Web service providers with a core set of markup language constructs for describing the properties and capabilities of their Web services in unambiguous, computer-interpretable form.
DAML-S’ support for automatic selection, composition and interoperation of Web services is of particular relevance to service chaining. Such support is possible because DAML-S provides declarative specifications of the prerequisites and consequences of individual service use that are necessary for automatic service composition and interoperation. These specifications can be used by mediating services to dynamically identify which services can be chained to each other, and which ones can be substituted for one another for the purpose of answering a specific request.
Web Services Flow Language (WSFL)
WSFL (IBM 2001) is an XML language for the description of Web Services compositions. WSFL supports two types of composition: flow models describe how to choreograph the functionality provided by a collection of Web Services to achieve a particular business need while global models describe how a set of Web Services interact with each other.
WSFL can be applied to orchestrate Web Services and provide a means for mediating services to construct, describe and save chains that can be later communicated to clients upon request.
Conclusion
It is becoming increasingly evident that there is a growing need for GIS Web Services (Abel D, Ooi B, Tan K, and Tan S 1998). The Web services model allows users to freely combine services to create customized solutions with minimal programming, integration and maintenance efforts. Such a model, supported by efficient service chaining, will also be a key enabler of GIS to extend beyond its traditional boundaries of mapping to embrace a broader community of users and wider scope of services. The development of this model should leverage general Web services technologies such as those described in this paper, and extend them to address any requirements that are unique to the geospatial community.
References
Abel D, Ooi B, Tan K, and Tan S, 1998, Towards integrated geographical information processing: International Journal of Geographical Information Science 12(4): 353-371.
Alameh N, 2001, Scalable and Extensible Infrastructures for Distributing Interoperable Geographic Information Services on the Internet: PhD Dissertation Submitted to MIT Libraries.
Brodie, Michael, 1993, The promise of distributed computing and the challenges of legacy information systems: In Hsiao D K, Neuhold E J, and Sacks-Davis R (eds) Interoperable Database Systems (DS-5) Amsterdam: 1-32. Cauldwell, Patrick et al. 2001, Professional XML Web Services. Birmingham, UK, Wrox Press Ltd.
CPS 2001, Coverage Portrayal Service, WWW document, http://member.opengis.org/tc/archive/arch02/02-019r1.doc
DAML 2002, DAML Services, WWW document, http://www.daml.org/services.
IBM 2001, Web Services Flow Language, WWW document, http://www- 3.ibm.com/software/solutions/webservices/pdf/WSFL.pdf
ISO, 2001, ISO/TC 211 Geographic Information/Geomatics. WWW document http://www.statkart.no/isotc211/
Litwin W, Mark L, and Roussopoulos N, 1990, Interoperability of multiple autonomous databases: ACM Computing Surveys 22 (3):267-293. Microsoft, 2001, XLANG WWW document, http://www.gotdotnet.com/team /xml%5Fwsspecs/xlang%2Dc/
Nebert D, 1999, Interoperable spatial data catalogs: Photogrammetric Engineering and Remote Sensing 65(5): 573-575.
OASIS, 2002, UDDI Page WWW document, http://www.uddi.org.
OGC, 2002, Open GIS Consortium Page WWW document, http://www.opengis.org.
OGC OWS 1, 2002, OGC Web Services Initiative 1 (OWS1) Baseline Documents Page WWW document, http://ip.opengis.org/ows1/docIndex.html.
SLD, 2001, Styled Layer Descriptor WWW document, http://www.opengis.org/techno/specs/02-070.pdf
Wiederhold G, 1999, Mediation to deal with heterogeneous data sources: In Proceedings of Second International Conference. Zurich, Switzerland: 1-16.
Worboys M, 1995, GIS A computing Perspective. Bristol, PA, Taylor & Francis.
W3C, 2000, Simple Object Access Protocol 1.1 WWW document, http://www.w3.org/TR/SOAP.
W3C, 2001, WSDL 1.1 Specification WWW document, http://www.w3.org/TR/wsdl.