EM
, yliu$,
lis paper
nal non
ns of the
hods for
services,
n allows
over the
nal Web
nd other
dation to
rototype
ns from
hitecture
support
twork. It
e format
he Web
ip. SOAP
in. XML
standards
plays a
reviation
'uage for
scription
„ version
L is the
by both
ram that
ked, and
for us to
rvice IS à
| data or
International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences. Vol XXXV, Part B2. Istanbul 2004
information. We need to distinguish geospatial Web services
from Web services in general because of the special
characteristics of geospatial data.
Geospatial data are the data which have spatial components
(e.g. geo-location or geo-reference). Geospatial data differ
from the general data such as numbers or characters largely in
many ways. Geospatial data mostly involve in complex data
type instead of the simple data type. And also, processing these
data are much more challenging. In general, geospatial data are
much more complex and difficult for data users than the general
data. Using geospatial data usually requires that the users have
expert knowledge or enough resources and spend a lot of time
to preprocess the data for further use. For example, NASA has
archived huge amounts of satellite data in HDF/HDF-EOS
format because the satellites data are all geospatial. How to use
these data has been a headache for many scientists and
researchers since the first day.
Geospatial Web services, which works with geospatial data, are
quite different from a general Web service as well. For
examples, an operation for a geospatial Web service may be
very complicated and hierarchical while the operation for a
general business Web service is usually simple and atomic. The
service discovery, access, binding and chaining for a geospatial
Web service may also highly differ from a general Web service.
1.3 Motivation to Build Geospatial Web Service System
The importance and necessity of building a geospatial Web
service system that can provide ready-to-use information
instead of raw data are obvious. Huge amounts of Earth remote
sensing
terabytes data are expected to be collected daily. Those data are
valuable not only for scientific research but also for other socio-
economic activities. However, currently most of the data are
only available to users in raw form. Users need to have both the
expert knowledge and significant amount of resources to
process the data into ready-to-use information. This situation
limits many potential uses of the data by broader user
communities. For instance, some users do not have enough
knowledge or resources to use data for their analysis and
information extraction and lots of valuable data are wasted, and
sometimes the decision makers need to promptly respond to an
incident or event, but the time needed to process and analyse
data is too long to fulfil the task.
À gcospatial Web service system based on the newly developed
Web technologies, which allows users to dynamically chain the
services with services and services with data to produce the
user-specified products over the Web, may provide a solution
for those puzzles. We propose to build a prototype geospatial
Web service system to demonstrate its robust power and
advantages over traditional non-service based systems for
reducing the difficulty of using remote sensing data for research
and applications.
2. SYSTEM DESIGN
To design our prototype system, we take the following into our
major considerations:
1. The system interoperability
2. Web services interoperability
3. The personalization capability
4. Software reuse
data have been collected by space agencies, and of
Un
System evolution capability/capacity
Our final goal is to provide products tailored to the individual
user's needs, including selection of spatial or temporal
coverage, map projection, format, bands etc. and information
products produced on-demand by executing Web-executable
geospatial process models. To realize our goal, the system must
be an open, personalized, standard-based, and interoperable
system [Di, L & Yang, W, 2002].
System interoperability means that the system can access and
process data and services from multiple resources. Web service
interoperability means that all geospatial Web services in the
system must be standards-based and interoperable for coupling
with data and other services.
The personalization capability of the system means that users
will be able to define the geospatial models and service
composition, use existing services or contribute new services to
obtain the data and information that exactly match their own
needs.
Software reuse means that all geospatial Web services and
geospatial models are designed to be dynamically reusable by
other systems and services through interoperable just-in-time
integration. All reuse may involve some code modifications.
The capability for evolution of a system depends largely on the
system architecture. A system that is component-based with
each component using standard interfaces, and is modular and
self-contained, is easy to evolve. We will design the prototype
Web service system as a component-based system so that the
system allows self evolution capability/capacity by allowing
standards-based geospatial Web service modules and geospatial
models to be plugged in.
Currently, the prototype gcospatial Web service system to be
developed here is a modelling and execution system which has
the capability to access online geospatial data and services, to
build models (service composites) which chain individual
standards-based geospatial Web services together and register
the models in the catalogue and to execute the chain for solving
complex tasks dynamically and efficiently. Figure 1 is the
abstract architecture for our prototype system.
| Users
Modeling | Catalog! |
E — Revistry Service |
| |
| |
|
y |
- | |
Instantiation pem
|
y
L__ 1 Execution
Figure 1. The Abstract Architecture
