Global Positioning System Reference
In-Depth Information
Data (USD) of a large city, the paper investigates the communication issues
that arise in environments where the underlying data must be accessed by
different types of users, in a reliable and up to date manner. In this case,
further diffi culties are represented by the needs of each system user and
their way to access such data, namely different computing platforms and
communication technologies, while performance and reliability aspects
must also be taken into account. As for the integration issues, a classifi cation
into Data Types handling, Functionality Mapping and Metadata Delivery
issues is adopted as in Ioup et al. (2008). To deal with the fi rst task (Data
Types handling), four different approaches are discussed and evaluated,
namely the translator Web service, the physical Web service, the wrapper
Web service and the common back end.
In the fi rst approach, a Web service receives SOAP messages from a
client and translates them in a format suitable for the target OGC service.
This suitable format is sent back, in a SOAP message, to the client, which
uses it to retrieve data directly from the OGC service. In the physical Web
service approach, the Web service translates the SOAP request and sends
it directly to the OGC service; the OGC service generates the binary fi le
and stores it in a permanent location on the server. The link to this location
is sent back to the W3C service, which forwards it to the client in a SOAP
message. Finally, the client uses this physical address to retrieve the binary
data. In the wrapper Web service approach, the wrapper service catches
the response message from the OGC service and sends it back to the client
by using only W3C encoding. The whole communication between client
and service is totally Web service based. As for the binary data returned
by an OGC service, the preferred choice is, again, the use of the MTOM
standard. In the last approach, the common back end, a W3C service and
an OGC service provide for 'two direct gateways to the same server engine'
(Amirian et al. 2010). A client can either send requests directly to the OGC
service or can query the W3C service, which will provide responses in a
W3C compliant way. Moreover in the latter case, according to the need of
the client, the W3C service can return the possible binary data using their
physical address, the Base64 encoding or the MTOM standard. Flexibility
and performance are the main advantages of this approach. As for the
mapping of functionalities these two approaches and those discussed in
Ioup et al. (2008) are quite similar. In the former approach, a Web service
replicates the same methods of an OGC service in a SOAP compatible way.
In this case a client must fi rst invoke the GetCapabilities method, parse the
Capabilities document and fi nally invoke the desired OGC functionality
replicated by the W3C service. The main disadvantage of this method is
that a service consumer is able to exploit a service by exclusively using the
published service contract, namely its interface. In the latter approach, the
one to many mapping, each data layer of an OGC service is mapped by a
Search WWH ::




Custom Search