Web Services Composition and Geographic Information - Geographical Information Systems: Trends and Technologies - page 129

completely transparent to the client application. The proposed architecture
consists of a server-side proxy and a client-side proxy. The client-side proxy
receives the HTTP GET and POST requests and transforms them into a
SOAP message, while the server-side proxy receives this SOAP message and
restores the original HTTP GET or POST request. For the response messages,
the contents must be properly XML encoded in order to incorporate them
in a SOAP document and, in particular, the previously discussed MTOM
standard could be used for binary data and for those services that can also
return plain or html text, such as the WMS.
A more complete analysis of problems arising during the integration
of W3C and OGC services can be found in (Ioup et al. 2008). In this paper,
some techniques for 'dividing OGC services and mapping capabilities into
multiple SOAP services' are presented and discussed. The core idea is to split
a single OGC service into multiple atomic W3C services each representing
a single geospatial dataset. As for the effective implementation, also these
solutions are based on the creation of a wrapper aimed at solving a series
of integration problems that the authors categorize into Data Handling,
Functionalities Mapping and Metadata Management issues. The authors'
work arises from a critique to the solution proposed in Gartmann and
Schäffer (2008). Their evaluation is based on the observation that OGC
services are based on a two steps process: a generic client, fi rst queries a
server to know its capabilities and then uses the various functionalities of
the OGC service to get the real data. The authors argue that by adding a
simple SOAP transformation a W3C service client should perform three
steps: get the WSDL, get the server capabilities and then get the real data.
Therefore, on the basis of such a possibility, they discuss issues that have to
be faced to realize this split. The fi rst issue to deal with concerns the Data
Handling since, as previously discussed, OGC services are not limited to
XML as a data exchange format. Moreover, different OGC services may
return different data types. A viable solution could be the possibility for a
W3C service to return only string data types. Although simple, this option
is not admissible when it is necessary to return data in binary format. A
different solution for binary encoded data could be to simply return a URL
pointing to actual data. Through it, a client could directly contact the OGC
service and retrieve the binary information. By this simple approach, a Web
service is not in charge of managing data in binary format and might not act
as a proxy for OGC services specifi c data. However, this approach transfers
the computational complexity to the clients, a not always performing
solution. Finally, a relevant part of the communication occurs outside the
W3C service stack, thus blocking the use of the aforementioned standards,
such as WS-Security. These motivations make this simple to implement
proposal unfeasible. The only way to overcome these issues is the creation
of a full wrap around the OGC service, thus forcing clients to communicate