Geoscience Reference
In-Depth Information
The phase 1 of MPLoM implementation covers the location integration
from two different providers offering pull and push services.
The pull services which are the nearest hotels and restaurants are visual-
ized on a 2D background Google map and the components are overlaid as
Google markers(R for restaurants and H for hotels); the details for each
clickable restaurant marker or hotel are presented textually on the mobile
device. A user interface is created to get all the preferences of the clients
(e.g. name, age, nationality, major, email, credit card, language, etc.) and
save them into a middleware admin database. Thus, the client's request
with all the needed parameters will be forwarded via Java servlet to the
concerned tables in the providers' databases (Karam et al. 2010).
Both providers' databases are created in PostgreSQL with the PostGIS fea-
ture for spatial usage. Each user's request will be then subdivided into two
sub requests, one for each provider in order to collect the available data.
Output data for each requested service type, will be saved as a GML file,
precisely in cGML format (compact for mobile device). All cGML output
files, one per provider, will be collected in the middleware admin database.
XQuery, from W3C body, is used to parse these cGML files, in order to in-
tegrate the details of homologous objects and append the heterogeneous
ones into a unified cGML file response.
The MPLoM executable file, or in other words, the LBS middleware in-
stalled on the mobile device (an S60 Nokia emulator in our case), can then
easily match and display on the screen, each cGML tag accordingly.
In order to implement a weather forecast push service, we choose a differ-
ent approach: The MPLoM LBS middleware connects to the available
weather forecast web services, which responses can be easily integrated,
due to the fact that they are in xml format.
We had implemented as well a catalog service in the mediator database to
list all the metadata about the providers and their offered services (service
type, free or not, the frequency of updates, covered countries, languages,
etc.). This kind of metadata catalog would be very useful: based on the
user's request and preferences, we can implement a pre filter step, in order
to access only the adequate providers, and thus minimizing the response
delay on the screen.
