bul 2004 | International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B2. Istanbul 2004
cuments | The core part of the prototype system consists of four major
ing our | components, Build, Instantiate, and Execute and Registry
| Catalogue. The component Build is used for the modelling
| process that provides the user interaction with the system to
| construct a service chain (composition). This modelling process
will produce a BPEL document with an abstract description of
the service chain. The component Instantiate will logically walk
through the chain for validation, and an executable BPEL
document will be produced in this step. These two components
are coupled with the Registry Catalogue with the service
discovery and registry functions. The Registry Catalogue also
publishes the services. The component Execute can access
services (or service composites), execute the service chain with
theBPEL engine and return the result. For better performance, a
service ontology is needed to be built into the catalogue service
for users to search for data and services for their own geospatial
interests.
33 Illustration
For demonstration simplicity, we test the developed prototype
| system with a user request to get land cover information for San
Francisco, California. A user can use the system in different
ways. For example, an expert user who wants to build his own
service chain could use the system catalogue service and find
SUE the available services and data (or register his own services or
data for use). Figures 4 is the instance of this expert use. The
user searches through the system and finds the WCSPortal
Sen its | service to access SPOT image data for San Francisco and one
E. | unsupervised Web image classification service chains these two
| | services together and executes the chain to get the classified
image (Figure 5). There are two WSDL files and Two BPEL
usiness : ; : ; ;
VS) files are involved in this chain. The two WSDL files,
da WCSPortal Wrapper. wsdl and
SD WICS Grass UnsupervisedWrapper.wsdl, describe the two
Le services respectively. One BPEL file is used to define the chain
as a new service interface, and another BPEL file is used to
ecutable 3 ^ ; ; aa
| define the executable process for this services composition. The
i | engine takes all the four files for execution. The intermediate
The result of the getCoverage in the service chain (Figure 6) is
mu invisible for the user, here is presented for comparison. Users
ins without their own models may go to the system and search for
the existing service for land cover information retrieval (as we
know, one expert user may have registered his model as a new
service in the system) or the system will automatically provide
a chain model based on ontology and type matching for uscr
testing and evaluation.
Figure 6. The Intermediate Result as GetCoverage
> GEOSPATIAL WER SERVICES j i = =
% WMS_Boston i
# WCS_Ruston
# WCSPortalService {
\MICS_Grass_Unsupervise
# ReprojectionService E
PortalSerice
ervicePoriType
4. CONCLUSIONS
r Target Service —————
In this paper, we described a successful implemention of a
limited number of interoperable geospatial Web services, based
on W3C and OGC standards, for taking coverage data from
coverage servers or from the output of other services as the
inputs. Those services are available for stand-alone applications
and service chaining. A prototype geospatial Web service
svstem for remote sensing data is developed to access those
services and construct service chains to solve complex tasks
dynamically. Initial demonstration shows that the prototype
Figure 4. An User Instance
svstem enables users to obtain the requested information and
stem
321
