2008 International Conference on Internet Computing in Science and Engineering
Building Improved GIS Service Based on WSRF
Zhiming GUI, Kai SONG
Department of Computer Science, Beijing University of Technology, Beijing, China
zmgui@bjut.edu.cn
Abstract
To implement some complex geoprocessing functions, it
may need to integrate several different GIS service. Due
to the low level HTTP Get/Post method only support
synchronous data queries and could not keep service
context information, the current OpenGIS Web Service
(OWS) architecture can not meet the requirement of
chained geoprocessing. Though the OpenGIS Message
Framework (OMF, discussing paper of OGC) provides a
mechanism to favor service chaining in OWS, it does not
clearly illustrate how to implement it. With the coming of
Web Service Resource Framework (WSRF), it provides a
feasible way to enables the service chain. This paper first
analyzes the WSRF and compares it with the OWS
architecture. Then it provides a method on converting the
OWS under WSRF. The detailed progress of implementing
an improved map service using Globus Toolkit is
provided at the end. The result shows it get better
performance and collaborative than standard OWS.
1. Introduction
The current OWS such as WMS, WFS and WCS
support very simple synchronous data queries based on
HTTP transport protocol. The lower level HTTP
GET/POST method is perfect valid in the case of simple
synchronous queries of information from an end-user
client such as a browser or a viewer application. With the
coming of service chain (a sequence of services where,
for each adjacent pair of services, occurrence of the first
action is necessary for the occurrence of the second
action.) which needs high level communication between
web services, the current OWS message method could not
meet the new requirement [1]. The use cases developed in
OWS1.2 have identified a number of requirements for the
communication between web services that are going
beyond the current existing communication [2]. Aiming to
these questions, the OGC provides OMF (OWS Message
Framework) to conduct communications between the
OWS in its interoperability program. However, it is still a
discussing paper. With the rapid development of Grid
technology, the WSRF provides a standard way to meet
the new requirement of OWS. In this paper, we discuss an
approach on adapting the OWS according to the
requirement of WSRF. And we designs and implements
978-0-7695-3112-0/08 $25.00 © 2008 IEEE
DOI 10.1109/ICICSE.2008.12
an improved map service system in this way using the
open source grid toolkit-Globus and Geoserver. Through
the process, it illustrates how to improve the existing
OWS to get more efficient and enable chained
geoprocessing.
2. Improve OWS Using WSRF
According to the content OWS provide, it can be
divided into data service and execution service. The data
service such as WMS, WFS and WCS provides the
sharing of geospatial data through the open interface. The
execution service such as WPS, it provides the spatial
processing on the data from the web or from the other
data service. The collaboration of GIS service requires
that the execution service be coupled to data service.
However, it is difficult to accomplish this target while the
OWS currently can only perform one task on one
requirement. It leads to the result of one task can not be
resend to the other service without another web request. It
also brings lower efficiency if the users wish to carry out
further processing on the returned data. Though the OMF
provides a message framework which intends to separate
the data (state) from the action (service) and favors
chained geoprocessing, it has not illustrate how to
implement it. To improve the cooperation and enable
chained geoprocessing of current OWS, it needs to find
out a way to keep and address the output message of
OWS.
2.1 WSRF and Stateful Web Service
With the rapid development of Grid technology and
OGSA (Open Grid Service Architecture), it provides an
ideal framework for the service management and
cooperation. The most important requirement of OGSA is
that the web service should be stateful. WSRF is a joint
effort by the Grid and Web Services communities. It is
the infrastructure on which OGSA is built. It improves
several aspects of web services to make them more
adequate for grid application. It provides a mechanism to
represent “state”. In WSRF, a stateful web service is a
plain web service with a resource, a pairing of a Web
service with a resource is called a WS-Resource. The state
information are seemed as WS-ResourceProperties and
stored inside resource properties in WSRF. Making the
274
state information as ResourceProperties will brings great
efficiency benefit while the client wishes to carry out
further processing on the result of previous invocation. It
also contributes to more collaborative between different
web services.
2.2 WS-ResoucePropeties and OGIS message
In WSRF, the Web service‘s state is modeled by
wrapping atomic or composite data types called
WS-Resource properties in WS-Resources [3]. What need
to do with making OWS stateful is to modify and wrap its
input/output message the way WSRF manipulates the
WS-ResourceProperties does.
In WSRF, it provides several actions to manipulate the
value of the resource such as getResourceProperties,
setResourceProperties,GetMultipleResourceProperties,
QueryResourceProperties. We map it to the OGIS
interface as the following method using the OGC: WFS as
the example and illustrate how it can improve the
efficiency and enable chained geoprocessing for the WFS.
As for the OGC: WFS GetFeature operation, it can
select an collection of feature like this,
getFeature (<wfs:GetFeature>
<wfs:Query typeName="topp:states">
<ogc:Filter>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>prevail</ogc:PropertyName>
<ogc:Literal>5</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>)
If we want to carry out further process on the result set,
it could not be done by OGC: WFS since the result is not
kept in server anymore. However, it can be done using
XPath in WSRF as:
QueryResourceProperties(”<QueryExpression>//MyFeatu
re[@fid=’state.3’]</QueryExpression>”) if we model the
result as Resource.
This expression retrieves the feature which ID is equal
to 3 from the result set get from the previous request.
However, OGC: WFS can do much more complex queries
than simply selecting on feature ID as in this example, it
needs to compare in more detail the OGC: Filter
specification with the WSRF resource property query
operations.
As for the transaction operation such as insert, update,
updateGeom in OGC: WFS, though
WSRF:SetResourceProperties can do part of this job, it
still needs further research to mapping all these operations
to WSRF interface for set and modify these resource
properties.
As for the checking of data integrity and determine
whether the data can be processed, the OGC: WFS
275
DescribeFeatureType retrieves feature definitions in GML
schema. In WSRF, it should be attached to WSDL port
type as XML schema. WSRF: WFS incorporates
reference to resourceproperties schema in WSDL
description like this:
WSRF-WFS:
<wsdl:types>
<element name=’MyFeature’ type=’MyFeatureType’
substitutionGroup=’gml:_Feature’>
</wsdl:types>
<wsdl:portType name=’WFS’
wsrp:resourceProperties=’MyFeature’>
2.3 Adding Notification to OWS
Due to notification message is very hard to implement
in HTTP without some serious hacking, the current OWS
do not provide the notification service. When the client
want to know what the status of a specific message
processing, adding notification is extremely useful for the
long transaction. In WSRF, the WS-Notification defines a
standard Web services approach to notification using a
topic-based publish/subscribe pattern. Adding notification
service to WSRF version OWS using WS-Notification is
illustrated in part-3.
3. Implementation of Improved GIS Service
Here, we convert the OGC: WMS according to the
requirement of WSRF as the example. OWMS is one kind
of OGC Portrayal Services belongs to OGC Web Service
model and it specifies a means for a client to request a
rendered, projected, cartographically styled map image
from a service. The OWMS specification defines a
number of request types, and for each of request type it
defines a set of query parameters and associated
behaviors. There are three main interfaces in OWMS:
GetMap, GetFeatureInfo and Get Capabilities. Get
Feature Info returns the information of some special
element s on the map. GetCapabilities: return an XML
document with metadata containing WMS Information.
GetMap: return an image as specified by a user. To
implement the WMS as the WSRF requirement, the first
step is to define the input/output parameters of these
interfaces as ResourceProperties, and then redefine the
service's interface using WSDL.
3.1 ResourceProperties Definition
There are several parameters in these interfaces. Not
every parameter in input/output message is suitable to be
modeled as Resource. We should first decide which
information should be made as Resource. Let use the
GetMap interface as the example.
A typical OWMS GetMap call looks like this:
URL=
http://127.0.0.1:8080/geoserver/wms?bbox=-130,24,-66,5
0&styles=population&Format=image/png&request=Get
Map&layers=topp:states&width=550&height=250&srs=E
PSG:4326
As we can see from this URL, every time we make a
new Getmap quest, many parameters with the same value
in the previous call are send again in the URL. Since the
most frequently change parameter is BBOX and the other
parameters are comparatively much stable, we choose the
FORMAT, VERSION, LAYERS, WIDTH, HEIGHT and
SRS as the state information. Since we will use the
Globus Toolkit to implement the service later, here we
use the WSRF and Globus specific WSDL to redefine the
interface. The state information can be defined as
resource properties using WSDL like this:
<!-- RESOURCE PROPERTIES -->
<xsd:element name="VERSION" type="xsd:String"/>
<xsd:element name="LAYERS"
type="xsd:String"/>
<xsd:element name="STYLES" type="xsd:String"/>
<xsd:element name="SRS" type="xsd:String"/>
<xsd:element name="FORMAT" type="xsd:String"/>
……..
<xsd:element name="MapServiceResourceProperties">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="tns:VERSION" minOccurs="1"
maxOccurs="1"/>
<xsd:element ref="tns: LAYERS " minOccurs="1"
maxOccurs="1"/>
<xsd:element ref="tns: STYLES " minOccurs="1"
maxOccurs="1"/>
<xsd:element ref="tns: SRS " minOccurs="1"
maxOccurs="1"/>
<xsd:element ref="tns: FORMAT " minOccurs="1"
maxOccurs="1"/>
......
</xsd:sequence>
</xsd:complexType>
</xsd:element>
3.2 PortType Definition
We have set some input message as
ResourceProperties, we need not to include the layerlist
and stylelist in the message again since at the most
situation it is the same. And now the Getmap interface
can be predigest to only one parameter: BBox.
There are a bit different in the portType definition
between the normal WSDL and the WSRF specific
WSDL. The most difference is the Resource properties
attribute of portType element, which is used to descript
the state information. Furthermore, to add notification
276
service to the portType, it should be extended from the
standard NotificationProducer portType.
Assume the Getmap operation return the target map’s
URL address as a String, and then we can define the
GetMap interface in the portType element as:
<portType name="MapServicePortType"
wsdlpp:extends="wsrpw:GetResourceProperty
wsrpw:GetMultipleResourceProperties
wsrpw:SetResourceProperties
wsrpw:QueryResourceProperties"
wsdlpp:extends="wsrpw:GetResourceProperty
wsntw:NotificationProducer"
wsrp:ResourceProperties="tns:MapServiceResourcePrope
rties">
<operation name="GetMap">
<input message="tns:GetMapInputMessage"/>
<output message="tns:GetMapOutputMessage"/>
</operation>
…….
</portType>
<types>
…… <!-- REQUESTS AND RESPONSES -->
<xsd:element name="GetMap" >
<xsd:complexType name=”BBox”>
<xsd:sequence>
<xsd:element name="minx" type="xsd:Float"/>
<xsd:element name="miny" type="xsd:Float"/>
<xsd:element name="maxx" type="xsd:Float"/>
<xsd:element name="maxy" type="xsd:Float"/>
…….
</xsd:sequence>
</xsd:complexType>
<xsd:element name="GetMapResponse"
type=”xsd:String”/>
The other two portType can be defined the same way.
3.3 Implement the Service
After define the interface using WSDL, we use Globus
Toolkit 4 and JAVA to program it. The GT4 is a famous
software toolkit, developed by The Globus Alliance,
which we can use to program grid-based applications.
First, a QNames interface is defined for all the
members of ResourceProperties according to the WSDL
definition. Next, according to the requirement of WSRF
and GT4, we split the implementation into three classes,
one for the Map Service, one for the Resource and one for
the ResouceHome. Here we use the Singleton design
model to implement the service. The ResourcrHome class
is extended from an existing class included in the GT
toolkit, SingletonResourceHome. The only thing to do is
implement the findSingleton method in it.
The MapserviceResource class implements the
Resource, ResourceProperties and TopicListAccessor
interface of GT4 JAVA WS-Core library. The
MapService class has three main methods corresponding
to the OWMS interface. To simplify its implementation,
we set the initial value for the ResourceProperties in the
MapService construct method. We also use an open
source OWMS implementation - Geoserver as the map
engine. While a client calls the Getmap method of the
map service, the method just creates an OWMS Getmap
request URI based on the state information and the value
of BBox parameter. Then it calls the Geoserver WMS
using the URI. When got the address of the target map, it
returns the address to the client.
3.4 A Simple Client Instance
same way since the main information is kept in the server
side.
Our current work has not incorporate many useful
WSRF functions such as lifecycle management and
security. In the future, we will incorporate it into our
system. And high performance data transfer is one
prominent challenge in GIS service, we also needs to do
further investigate on it under Grid environment. Now,
there is a growing interest amongst OGC members to
explore Grid technology. The incorporating of OGC
technology with the WSRF functionalities will provides
more personalized, efficient on-demand geospatial data
access and services to data users.

This simple client only tests how the Mapservice can
keep state and invocate continuous GetMap request
without sending duplicated information as OGC: WMS
does. Since the initial value for generate a getMap request
has been assigned to the Mapservice in its construct
method, this client do not use the set/get
ResourceProperties method. It just makes two getMap call
with different BBOX value to get two maps with the
different scale. Its code and result is listed below.
MapServiceAddressingLocator locator = new
MapServiceAddressingLocator();
EndpointReferenceType endpoint = new
EndpointReferenceType();
endpoint.setAddress(new Address(URI));
MapPortType map =
locator.getMapPortTypePort(endpoint);
…….
Map.getMap(BBox1);
Map.getMap(BBox2);
Reference
[1] OGC, OWS Messaging Framework (OMF), Open GIS
Consortium, Inc. OGC Document 03-029,2003
[2] Aijun Chen, “An optimized Grid-based, OGC
standards-compliant collaborative software system for
serving NASA geospatial data”, Proceedings of the 30th
Annual IEEE/NASA Software Engineering, 2006
pp.159-166.
[3] The Globus Project, “The Globus Toolkit”,
http://www.globus.org/toolkit, 2006.
[4] P. Vretanos, OpenGIS Web Feature Service (WFS)
Implementation Specification, version 1.1, OGC 2005.
[5] Zaslavsky, C. Baru, “Grid-enabled Mediation Services
for Geospatial Information”, Next Generation Geospatial
Information, Volume 1, Part 2 July 2005, pp. 15-25.
[6] Ian Foster, Carl Kesslman, “The Physiology of the
Grid-An Open Grid Services Architecture for
Distributed Systems Integration”,
http://www.globus.org/research/papers/ogsa.pdf

[7] Asif Akram, “Implement resource sharing using WSRF”,

Figure 1: The Result of Client ZoomOut
The client shows that the parameters are reduced to [8]
only BBox and the server need not to handle the other
parameters as OGC: WMS does. It brings higher
efficiency.
[9]
4 Conclusion and Future Work
In this work, we studied on improve the OWS using
WSRF. The OWS input/output message are mapping to [10]
WSRF ResourceProperties and it bring higher efficient
and enables chained geoprocessing. In our current demo
application, the collaboration between different GIS
service has not been tested. However, it can be done the
https://www6.software.ibm.com/developerworks/educati
on/gr-resws1/
A.Chen, L.Di, “Grid Computing enabled geospatial
catalogue web service”, Proceedings of ASPRS 2005
Annual Conference, Mar. 7-11, 2005, Baltimore, USA.
Yanfeng Shu, “A Grid-enabled Architecture for
Geospatial Data Sharing”, Proceedings of the 2006
IEEE Asia-Pacific Conference on Services Computing
pp. 369-375.
Scott Pezanowski, “An Open GeoSpatial
Standards-Enabled Google Earth Application to Support
Crisis Management”, Proceedings of the 3rd
International Symposium on Geo-information for
Disaster Management.

277