An Approach to Standardize Mobile and Immobile

Location-based Services: An Application based on

Mobility and Geo-location

El Kindi Rezig

and Valérie Monfort

2,3

University of Science and Technology –USTHB, BP 32 EL ALIA

16111, Bab Ezzouar, Algiers, Algeria

Université de Sfax, MIRACL, Sfax, Tunisie

Université Paris 1 Panthéon Sorbonne, 90 rue de Tolbiac 75634 Paris cedex 13, Paris, France

Abstract. Location-based services (LBSs) are being increasingly popular due

to their usefulness in users’ daily life, their applications include location-based

advertising, location-based shopping…etc, however today’s LBSs often relate

to a fixed geographic location. Unlike immobile LBSs, mobile LBSs are mov-

ing services that have a changing geographic location, their applications in-

clude mobile hospitals, ambulances, mobile libraries…etc. In addition, today’s

LBS applications are provider-specific and can’t (generally) cohabit with other

LBS applications from other providers, consequently, consumers have to use

different platforms and applications in order to discover and interact with dif-

ferent LBS applications. In our paper, we present an infrastructure based on

geo-location and Web services to promote the uniformity of the way mobile

and immobile LBS providers publish their services on one hand, and the way

consumers discover and interact with the LBSs they look for on the other hand.

Moreover, the proposed infrastructure is context-aware and promotes dynami-

cal services accessibility by offering consumers, as they are moving, the nearest

services they are interested in.

1 Introduction

Location based services (LBSs) [1] are offered through devices with location capabil-

ities such as mobile phones, GPS devices…etc. These services include a wide range

of applications such as looking for the closest restaurant, finding someone,…etc.

LBSs have become a lucrative business for both wireless carriers and developers of

location-aware applications. Today, LBSs have become part of users’ everyday life,

using several media as: mobile phones, PDAs…etc to find the closest clinic, to do

bank transactions…etc, most of today’s LBS providers propose immobile services

such as restaurant, bank,…., these LBSs relate to a fixed geographic location, we

called them immobile LBSs. Since a lot of services are being mobile such as libraries,

hospitals, transportation…etc, it would be useful to propose mobile LBS applications

that change continuously their location as they are moving. These mobile and immo-

bile LBSs should be discoverable and consumed by clients.

Kindi Rezig E. and Monfort V.

An Approach to Standardize Mobile and Immobile Location-Based Services: An Application Based on Mobility and Geo-location.

DOI: 10.5220/0003026400920100

In Proceedings of the International Joint Workshop on Technologies for Context-Aware Business Process Management, Advanced Enterprise Architecture and Repositories and Recent

Trends in SOA Based Information Systems (ICEIS 2010), page

ISBN: 978-989-8425-09-6

Geo-location is the cornerstone of this research work. Geo-location aims to locate

a user, an object, a data … on a map with geographical coordinates. This operation is

possible using a device able to be located (GPS, …) and to publish (on real time for

instance) the geographical coordinates. The location can be seen on online maps us-

ing laptops, PDAs, Mobile phones...

Moreover, we noticed that Service Oriented Architecture (SOA) [2] offers a great

flexibility to Information Systems (IS) because each application owns interfaces

masking implementation details. So, applications own interfaces including services

and are seen as black boxes independently connected to a middleware as Enterprise

Application Integration bus (EAI) with its connectors and adaptors. Moreover, Web

services are based on standards and are till now the cheapest and simplest solution to

support interoperability between platforms. Based on Web services, Enterprise Ser-

vices Bus (ESB) [3] [4] is a kind of services Web based EAI and allows loosely

coupling with low costs. However, even if Web services offer technical connection

means for interoperability, they address neither adaptability nor context aware adap-

tability.

This paper presents a concrete design and implementation of context awareness for

mobile users and an improved platform to standardize the discovery, interaction and

publication of LBSs, We mainly used Web services and Microsoft .NET 3.5 to

achieve this. We shall process as follows, The second section introduces Web servic-

es. The third section presents LBS. Section four proposes a case study. Section five

shows a new model to describe LBSs using GML. Then, Section seven shows dis-

cusses the approach’s implementation.

2 Web Services

Web services [5], like any other middleware technologies, aim to provide mechan-

isms to bridge heterogeneous platforms, allowing data to flow across various pro-

grams [6]. The Web service technology looks very similar to what most middleware

technologies looks like. Consequently, each Web service has an Interface Definition

Language, namely WSDL (Web Service Description Language) [7], that is responsi-

ble for the message payload, itself described with the equally famous protocol SOAP

(Object Access Protocol) [8], while data structures are expressed by XML (eXtended

Markup Language) [9]. Very often, Web services interfaces are stored in UDDI (Uni-

versal Description Discovery and Integration) registry [10].

In fact, the winning card of this technology is not its mechanism but rather the

standards upon which it is built. Indeed, each of these standards is not only open to

everyone but, since all of them are based on XML, but it is also pretty easy to imple-

ment them for most platforms and languages. For this reason, WS are highly intero-

perable and do not rely on the underlying platform they are built on, unlike many

ORPC (Object Request Procedure Call). Web services standards are gathered in WSA

(Web Service Architecture) [5].

Geographical discovery of services has improved users’ everyday life dramatically,

and it has made people’ life easier, services include road navigation, geographical

social networks, ….etc, such solutions already exist today and they are being increa-

singly popular for their big usefulness, however most of the existing geographical

solutions are vertical, meaning that they are vendor-specific and can’t live in the same

environment because of their heterogeneity. Having Web services that can express

their offers geographically improves drastically the capabilities of today’s Web ser-

vices, in fact, customers will be able to search for them geographically and according

to their location constraints. Moreover, Web services resolve the problem of the geo-

graphical services heterogeneity.

Our goal is to design and implement a location-aware system that takes advantage

of Web services with geographical capabilities, our system is able to deliver the ser-

vices that the client looks for according to his current location, we mean the nearest

services to the client.

3 Towards a Homogenous LBSs Environment

Location based services application can be described as applications that are depen-

dent on the user’s location in order to work. In other words LBS applications give

information based on the device’s geographical position [11]. LBSs can be divided

into two categories as: Triggered and user-requested. In the triggered category, LBS

relies on a certain condition to be met in order to retrieve the user’s position and use it

in the location-aware application, for example, when a vehicle has an accident, an

automatic emergency call with the vehicle’s position would be triggered. In user-

requested LBS, users transmit their current location to have relevant information like

driving directions, finding the nearest shopping malls…etc. LBS services can be

mobile or immobile depending on the application.

Many efforts are in progress to standardize LBSs, the most popular LBS standard

is OpenLS [12] defined by the Open Geospatial Consortium (OGC), it offers imple-

mentation specifications to the most critical parts of LBSs. Unfortunately, the current

methods of designing LBS applications are not enough to get the most of LBS appli-

cations using open standards. This limitation is addressed in our paper using SOA and

GML.

3.1 LBSs Concerns Stack

Location based services providers increasingly worry about the visibility of their

services to potential consumers, unfortunately because LBSs are provider-specific

each editor has a discovery policy through which consumers can find it. Moreover,

providers of LBSs may use different ways to access and interact with their services.

Eventually, LBS providers have different ways to describe their services in terms of

their locations and how to interact with them. To express all the aforementioned fea-

tures we defined a three-layered stack. Layers are aspects that LBSs are concerned

about: Discovery, Description, Access.

When every provider offers a different stack, users wouldn’t be able to discover it as

long as they aren’t sticking to the provider’s discovery policy; The same issue is

Fig. 1. LBS providers in a heterogeneous environment.

applicable to the access and description policies. The following Fig.1 shows the sce-

nario where every LBS provider defines its own concerns stack

In order to improve the aforementioned situation, each LBS provider should stick

by the same concerns stack, this following way. All LBSs use the same discovery,

services description and access policies. By having this scenario, LBS providers share

the same platform between each other, this helps maximizing their visibility, and

consumers would have more choices to pick the most convenient LBS. In order to

achieve an homogenous LBS environment, we have used Web services as they are

the best way to make heterogeneous environments interoperable. Each LBS is a Web

service, and with Web services we can associate standardized items to the three layers

of the concerns stack as follows:

Discovery: We use the UDDI registry to publish and discover all LBSs.

Description: Descriptions of LBSs is done through the Web service’s WSDL,

geographical description is done through the Web service’s GML profile (explained

in section 5).

Access: All interactions with the Web services are done with SOAP.

Web services are the fitted solution for flexibility to changes and interoperability

but as mentioned in previous related works [13] , [14], [15] they do not offer (context

aware) adaptability.

The following Fig.2 shows the LBS providers in a homogenous environment:

Fig. 2. LBS providers in a homogenous environment.

4 Case Study

4.1 Context

Users can ask for geographical services (LBSs wrapped in web services) via a UDDI

registry. They can also use their cars, and, while driving, ask for the closest services

as banks or hospitals, … Since all he LBSs are Web services, users can interact with

these services using the WS’s WSDL and the WS’s GML profile.

4.2 Technical Architecture

4.2.1 First Scenario: User Accesses Geographical Services (LBS Application

Wrapped in Web Services)

Let us focus on the LBSs accessibility. Fig. 3 shows two parts as client and server

sides. On the client side, the user is detected by different kinds of devices to deter-

mine his location and the area corresponding to his location. Then, on the server side,

a specific interface (as a gateway) provides a mapping between the area and the ser-

vices corresponding to this area.

4.2.2 Second Scenario: An Actor Publishes Geographical Services

This second scenario explains how to reach the UDDI registry and the correspon-

dence between an area and a service. Then, for instance, a bank manager wants to

inform potential users that his bank offers a set of services as ATM. He can ask for a

service provider to subscribe an account. A contract is signed between the bank and

the service provider with financial engagements. The service provider proposes a

GUI pattern as a form, to be fulfilled by the bank manager to promote bank services.

So, the publisher gives the Web service WSDL as well as its GML (Geography Mar-

kup Language) profile that geographically expresses the Web service. GML is an

XML grammar that expresses geographical information, ranging from complex

graphical representations to simple points representations, GML has been defined by

the Open Geospatial Consortium (OCG). GML can also serve as an interchange for-

mat for geographical data. The accuracy of this language has led us to choose it in

order to describe geographical information.

The bank manager uses the Publication module and the service provider defines

the link between the services and the area including bank via UDDI Publish Interface

and then via UDDI registry. Then, this module is in charge of the communication

between the publisher and the UDDI registry, it publishes the information the pub-

lisher gives but most importantly, it associates the GML profile to the publisher’s

Web services via tModels. A tModel is a data structure representing a service type (a

generic representation of a registered service) in the UDDI (Universal Description,

Discovery, and Integration) registry. Each business registered with UDDI categorizes

all of its Web services according to a defined list of service types. Businesses can

search the registry's listed service types to find service providers. The tModel is an

abstraction for a technical specification of a service type; it organizes the service

type's information and makes it accessible in the registry database.

For every published Web service, the publish module publishes a tModel that

holds the GML profile information. This tModel will be used in the geographical

discovery.

Fig. 3. Technical architecture.

5 A New Model to Describe LBSs using GML

5.1 The Web Service’s GML profile

LBS providers must have a standardized way to describe their services geographical-

ly. Since most today’s geographical description means are proprietary. We had to find

an open standard to associate the geographical description to LBS applications effi-

ciently. The most suitable choice to accomplish this task is GML.

Each Web service proposes a set of services that are located geographically and

associated to the Web service operations. In order to express these settings, a profile

must be added to the Web service in order to enumerate its geographical services and

their details such as their names, operations…. We defined a profile based on GML,

this profile is part of the description layer of the LBS concerns stack presented pre-

viously. It is presented as an XML document that uses the GML namespace in order

to express the name of the entities through the element Gml:Name, and, most impor-

tantly, their location through the elements: Gml:Point, Gml:Pos. This profile is called

a GML profile.

6 Implementation

6.1 Applicative Architecture

6.1.1 Overview

The Windows 7 sensors and location platform has brought a tremendous facility in

developing location-aware applications in the Microsoft .NET platform, while most

existing location platforms today are vendor-specific, the Windows 7 sensors and

location platform defines a uniform model for location devices, each sensor respect-

ing this model will enable developers to handle it without worrying about the imple-

mentation details of the sensor’s driver. In order to simulate a GPS receiver we use a

virtual location sensor: Laptop Lojack[24], an open source virtual GPS ready to work

with the Windows7 sensors and location platform.

We implemented the system as a WPF application since it offers rich and intuitive

GUIs that are convenient to any user. The Windows Presentation Foundation (or

WPF) is a graphical subsystem for rendering user interfaces in Windows-based appli-

cations. WPF, previously known as "Avalon", was initially released as part of .NET

Framework 3.0. WPF is built on DirectX, that provides hardware acceleration and

enables modern UI features like transparency, gradients and transforms. WPF pro-

vides a consistent programming model for building applications and provides a clear

separation between the user interface and the business logic. We chose Microsoft

.NET 3.5 for the development environment, for location awareness we used the Win-

dows 7 sensors and location platform to make the application location-aware. To

interact with UDDI registry we used Microsoft UDDI SDK. As UDDI registry, we

used jUDDI [16]. The Fig.4 shows the applicative architecture of the system. The

storage layer presents the persistent entities of the system. jUDDI is an open source

Java implementation of the Universal Description, Discovery, and Integration (UDDI

v3) specification for Web services. This project is under the Apache foundation. The

core layer shows back end applications.

Fig. 4. Applicative Architecture Overview.

7 Future Works

We would like to find a more fitted solution to query geographical descriptions (GML

profiles) of web services representing LBS applications, since quantity of information

within GML profiles may become enormous rapidly, parsing them might be a slow

process, and therefore, we should work on improving the performance of this process.

We would also like to add composition capabilities between the web services of

the LBS applications, this way, all the composition of the LBS would be done

through open standards and without the need of additional technologies and policies.

8 Related Works

Several research works aim to use meta modelling such as [17], [18], [19], [20], [21],

context awareness platform as WComp [22] or other platforms to promote adaptabili-

ty. [11] presents the need to standardize LBSs using open standards and the key bene-

fits of this move, however it just focuses on the standardization of the geographical

part of the LBS applications using GML, thus, no means to standardize the LBS ap-

plications globally. We did not find any research work using context aware platform

in this domain. Moreover, we did not find any research work using the same approach

to locate a user and to associate Web services to geographical location with GML

extensions.

9 Conclusions

This research paper presents a new means to standardize LBS environments, on one

hand this means allows LBS providers to be more visible to consumers, on the other

hand consumers don’t have to use proprietary mechanisms to access and interact with

LBS applications. Adaptability is given by Geo-location that allows to select services

according to the location context. We used web services as a technical means to stan-

dardize LBS applications, we used Microsoft .NET 3.5 for the development environ-

ment and for location awareness we used the Windows 7 sensors and location plat-

form. We described a genuine mechanism to associate the position of a user to an area

and to services (defined and subscribed in this area) via an extended GML and UDDI.

We implemented the whole case study and we showed examples of code. We have

now to improve adaptability to auto adaptability with reflection mechanism and to

also improve Geo location data bases.

References

1. T. D'Roza, G. Bilchev: An Overview of Location-Based Services. BT Technology Journal,

Springer Netherlands, volume 21, number 1, 2003.

2. F. Curbera, R. Khalaf, N. Mukhi, Quality of Service in SOA Environments. An Overview

and Research Agenda (Quality of Service in SOA-Umgebungen). it - Information Technol-

ogy 50(2): 99-107, 2008

3. D. Chappell: Enterprise Service Bus. Publisher. O’Reilly, 2006 Alexander Ryan

4. Mulesoft, retrieved from the website: http://www.mulesoft.org

5. Web Services Architecture, retrieved from the website: http://www.w3.org/TR/ws-arch/

6. Web Services and Service-Oriented Architectures, retrieved from the website:

http://www.service-architecture.com/

7. Web Services Description Language, 2007, retrieved from the website

http://www.w3.org/TR/wsdl20/

8. Simple Object Access Protocol 1.2, 2007, retrieved from the website

http://www.w3.org/TR/SOAP

9. Extensible Markup Language, retrieved from the website http://www.w3.org/XML/

10. The UDDI Version 3.0.2 Specification, 2004, retrieved from the website

http://www.uddi.org/pubs/uddi_v3.htm

11. Sumit Sen, Smita Sengupta: Open standards in location based services. Retrieved from the

website: www.gisdevelopment.net/technology/lbs/techlbs002.htm

12. OpenLS Implementation Standards, 2010. Retrieved from the website:

http://www.opengeospatial.org/standards/ols

13. Hmida, M. B., Tomaz, R. F., and Monfort, V: Applying aop concepts to increase Web

services flexibility. Journal of Digital Information Management (JDIM), 4(1):37–43, 2006.

14. Haddad, S., Moreaux, P., and Rampacek, S: Client synthesis for Web services by way of a

timed semantics. In Proceedings of the 8th Int. Conf. on Enterprise Information Systems

(ICEIS06), pages 19–26, 2006.

15. Tomaz, R. F., Hmida, M. B., and Monfort, V. Concrete solutions for Web services adapta-

bility using policies and aspects. The International Journal of Cooperative Information Sys-

tems (IJCIS), 15(3):415– 438, 2006.

16. jUDDI project, 2009, retrieved from the website: http://ws.apache.org/juddi/

17. De Farias, C. R. G., Pires, L. F., and van Sinderen, M. A MOF Metamodel for the Devel-

opment of Context-Aware Mobile Applications. In Proceeding of the 22nd ACM Sympo-

sium on Applied Computing (SAC'07) (2007).

18. Frankel S. David., Model Driven Architecture: Applying MDA to Enterprise Computing,

Wiley Publishing, Inc(2003)

19. Gottschalk, F. and van der Aalst, Wil M.P. and Jansen-Vullers, M. H. and La Rosa, M.

(2008) Configurable Workflow Models. International Journal of Cooperative Information

Systems (IJCIS).

20. J. Klein, L. Hélouet, and J. M. Jézéquel. -- Semantic-based weaving of scenarios. -- In

Proceedings of the 5th International Conference on Aspect-Oriented Software Develop-

ment (AOSD'06), Bonn, Germany, March 2006. ACM.

21. S. Lundesgaard, A. Solberg, J. Oldevik, R. France, J. Oyvind Aagedal, F. Eliassen, Con-

struction and Execution of Adaptable Applications Using an Aspect- Oriented and Model

Driven Approach, IFIP DAIS 2007, LNCS 4531, 76-89, 2007.

22. Matthias, B., Dustdar, S., and Rosenberg, F. A survey on context-aware systems. Interna-

tional Journal of ad Hoc and ubiquitous Computing 2 (2007).

23. J. Y. Tigli,

S. Lavirotte, G. Rey, V. Hourdin, D. Cheung-Foo-Wo, E. Callegari, M. Riveill.

« WComp Middleware for Ubiquitous Computing: Aspects and Composite Event-based

Web Services ».

24. Laptop LoJack project, 2009, retrieved from the website: http://laptoplojack.codeplex.com

100