- Email: [email protected]
An architecture and development methodology for location-based services
Electronic Commerce Research and Applications 5 (2006) 201–208 www.elsevier.com/locate/ecra
An architecture and development methodology for location-based services Aaron Hand, John Cardiff, Patricia Magee *, Jimmy Doody Institute of Technology Tallaght, Dublin, Ireland Received 10 June 2005; received in revised form 25 July 2005; accepted 1 September 2005 Available online 21 April 2006
Abstract This paper presents SAGESS (spatial application generic environment system standards), an open framework location-based services (LBS) development architecture. It can be implemented without any third party software, and provides LBS developers with complete development control and technology choices. It also describes SAGE (spatial application generic environment), a methodology for creating LBS applications. It has the advantage of creating LBS applications that are light on the wireless device resources and are OS independent. It gives LBS developers the capability to build LBS applications based on generic templates, decreasing development cost and time. This paper presents a study of the deployment of a prototype LBS application on the SAGESS architecture platform, developed using the SAGE development toolkit. Ó 2006 Elsevier B.V. All rights reserved. Keywords: Location-based services; Development methodologies
1. Introduction Wireless telecommunication technology advances and the mass integration of wireless communication devices into society have created the next generation of computing, the mobile generation. The mobile generation does not restrict users to a fixed desktop location but allows anywhere anytime mobile computing. Wireless devices are no longer just simple communication devices and the demand for non-voice services have already been demonstrated by GSM’s short message service (SMS) and Japan’s NTT DoCoMo’s imode services [1]. NTT DoCoMo’s imode Internet services have signed about 2 million customers in a little over two years since its release. The future of most enterprise systems will be based on their adaptation to this mobile era [2] and applications built that can take advantage of this era. The applications
*
Corresponding author. Fax: +353 1404 2700. E-mail address: [email protected] (P. Magee).
1567-4223/$ - see front matter Ó 2006 Elsevier B.V. All rights reserved. doi:10.1016/j.elerap.2005.09.006
expected to dominate the mobile generation are locationbased services (LBS). LBS applications are accessible with a wireless telecommunication device through a telecommunication network and exploit the ability of a wireless device location to provide a service. LBS applications provide services like ‘‘Where is the closest restaurant?’’ ‘‘How do I get back to my house from here?’’ ‘‘Where is my friend located?’’ LBS have been identified as the ‘‘next killer application area’’ [3] with an industrial revenue prediction of over $32 billion in Europe by 2005 [4] and an expected $680 million global customer base by 2006 [5]. LBS applications have a mandatory requirement for location information. This information is obtained in geocoordinate format based on a geographical coordinate system used. This location information must then be spatially processed to determine the user’s location. The spatial processing involves the comparison of the geocoordinate to the spatial data stored inside a data reservoir. This mandatory manipulation of stored data makes LBS applications data intensive Error! Reference source not found. . . In many cases, LBS applications are required to
202
A. Hand et al. / Electronic Commerce Research and Applications 5 (2006) 201–208
manipulate and access stored data multiple times in order to produce the LBS solution. The more accurate and diverse the stored spatial data is, the more accurate and in-depth the LBS solution will be. There are various different LBS applications in many different commercial sections like tourism [7], business, health [8] and gaming [6]. LBS tourist applications provide a wide range of localised information: landmarks, restaurants, petrol stations, ATM locations, etc. Tourist information services must deliver content that is culturally correct and suited for the user’s wireless device. Mobile commerce or m-commerce is another type of LBS applications. Mobile users receive information about sales and prices of goods that are in their area. The user can buy these goods while on the move and collect them a few minutes later. This concept is the same as e-commerce [9] except that the user’s location is taken into consideration. M-commerce must address privacy issues and security of payment. LBS applications can be used to track the movement of goods, vehicles people, packages etc. The tracking of truck vehicles is commonplace but LBS applications could be used to track goods indoors. The tracking of goods inside a vehicle can assist in making last minute delivery changes. A LBS application could be used to calculate the shortest route for the truck and its cargo. LBS applications can assist in goods retrieval if stolen. A LBS application can be used to locate an emergency phone call location. This would assist rescue teams to arrive at the location faster. The call location would also assist the dispatcher to select the rescue services that is geographical the closest to the caller. By using emergency call location and routing LBS application, the fire brigade could arrive at the fire by the fastest possible route, considering dynamic features like traffic congestion. Games that can incorporate location information would provide an additional challenge to mobile game playing. This type of gaming is already starting to be released but with requirements for Java enabled phones to avail of the full functionality has caused user acceptance to be slow. A LBS application can assist with navigation and routing. Dynamic traffic information can be sent to a user about roadblocks or traffic congestion along a route. LBS applications can calculate the shortest route from the user’s current location considering all these factors. LBS applications development is starting to progress with a wide range of LBS development companies. Webraska, an LBS solution provider, developed the ParisDakar Motorcycle Race [10] tracking LBS application. Orange Slovensko, the Slovakian telecommunication company, developed an LBS application [11] for locating facilities such as hotels, ATMs, fuel stations, restaurants, etc. This LBS application is available on wireless devices by SMS or WAP (GPRS) and uses Cell ID for wireless device location. IT’s Alive, a Swedish LBS game company, devel-
oped the Botfighters [6] LBS game. In Botfighters, players run around chasing other players out in the streets. Game interaction is by SMS. To have more interactive functionality, a Java J2ME application must be installed on the wireless device Botfighters is available in Sweden, Finland, Ireland and Russia. Location-based services (LBS) provide users of mobile devices with personalized services tailored to their current location. They open a new market for developers, cellular network operators, and service providers to develop and deploy value-added services: advising users of current traffic conditions, supplying routing information, helping them find nearby restaurants, and many more. The author developed a prototype application: Service Route Finder (SRF) using the SAGE Development Toolkit. The prototype was developed following the SAGE development methodology and deployed on the SAGESS technical implementation architecture. The Service Route Finder (SRF) LBS application is a dynamic mobile solution for locating services (restaurants, ATM’s, hotels, cinema, etc.) on low resource devices over standard communication protocols. This paper begins with a description of the SAGESS technical implementation in Section 2 and how the SAGE guidelines apply. Section 3 then details the implementation structure and features of the SRF application. Section 4 gives an overview of the map content used in the prototype. The paper continues by explaining the development of the prototype application in Section 5. The conclusions from this study are presented in Section 5 with particular emphasis on the usefulness of the SAGESS architecture and the SAGE development methodology for LBS application developers, and the other players in the LBS market place. 2. SAGESS technical implementation architecture The SAGESS generic platform is a three-tier architecture, with three internal components. This section details the architecture of SAGESS, on which the prototype was developed. Fig. 1, demonstrates an overall diagram of the SAGESS architecture. The numbers in the diagram represent the flow of data through the architecture. 2.1. Client communication tier The client communication tier is a protocol independent tier, where the users’ location is established and where communication with the application tier occurs. Users can be any person with a wireless communication device that has Internet capabilities. Wireless devices with Internet connections range from the simple Siemens C60 to the multifunctional 02 XDK II [12]. The user accesses the LBS application by entering the application Uniform Resource Locator (URL) in to their Internet browser. Any location method (A-GPS, COO, Bluetooth, etc.) can be used to locate the user’s current
A. Hand et al. / Electronic Commerce Research and Applications 5 (2006) 201–208
203
Fig. 1. SAGESS architecture.
location. A user geographical coordinates can be of any format, including a height factor for users who are up a mountain. Wireless communication between the client communication tier and the application tier can be achieved by any form of wireless Internet protocol communication or technology, such as GPRS on 2.5 G networks, EDGE on 3 G networks, or imode packet switching technology. At the Client communication tier the users interact with the LBS application Internet page and choose their LBS application options. 2.2. Application tier The application tier performs all result-set mark-up into the appropriate output display for the user’s wireless device. On the application tier SAGESS generic architecture has two components: a SQL transformer and a display processor. The SQL/XML transformer was implemented using the Oracle XDK for Java component. This technology offers many different types of XML parsing based on different technologies. The key component inside the XDK package is the XML SQL Utility (XSU) for Java. The XML SQL Utility (XSU) for Java generates dynamic XML documents from SQL queries. This utility can be called from inside a Java application or as standalone XSQL data pages.
The XSU can output data as text, Document Object Model or a JDBC Result Set Object. XSU supports all data types supported in Oracle 9i database server and table operations (inserts, updates and deletes). This is a key point when dealing with complex Oracle geometry types, which contain three different array type structures. XSU performs database connections through JDBC drivers. Oracle provides specific JDBC drivers to optimise performance, but XSU will run with any industrial accepted JDBC driver. In the dynamic XML documents generated, nametags correspond to the table column names inside the database, and the value between the nametags corresponds to the table column value. The display processor was implemented using an eXtensible Stylesheet Transformations (XSLT) processor. A XSLT processor transforms or renders XML documents based on the formatting rules defined in the XSL stylesheet. There are many free XSLT processors and many come preinstalled with Internet servers. The XSLT processor can render XML document into a specific or a range of different markup formats (SVG, HTML, PDF, WML, VRML), depending on the wireless device capabilities. XSLT processors apply XSL stylesheets, which detail how XML nametags will be displayed. For example, a HTML XSL can define a XML nametag be displayed as bold text in a HTML document, where in a SVG XSL the same XML document nametag could be a heading on top of a diagram.
204
A. Hand et al. / Electronic Commerce Research and Applications 5 (2006) 201–208
The developing language XSQL (XML/SQL) is implemented on the application tier to inform the XML SQL utility what SQL query to execute and which XSL stylesheet to apply. XSQL is the control file that invokes the two application tier components. XSQL are text documents that are based on the open standards of XML. The SQL translator formats SQL result sets into an open source format. The use of open source formats means that a wide range of development language such as Java, C, and C++ can be used to coordinate the SQL translator and display processor. XSQL was chosen as its execution times are much faster with the application components and the Internet server recompiles XSQL files, making changes instantly effective. 2.3. Geographic information system tier The Geographic information system (GIS) information tier will perform all LBS application query processing. The GIS tier stores, modifies and retrieves spatial data sets based on the LBS application query from the application tier SQL/XML transformer component. The spatial database chosen was Oracle 9i with Spatial Cartridge option, implemented on Red Hat Linux 8 and Red Hat Linux 9. Oracle was chosen, as it is one of the most popular if not arguably the most popular database in the world. Oracle was also used in other LBS architectures [13–15] and was the database for J-Phone J-Navi [16]. The Oracle database is made up of three structures: geographical tables, application specific tables and stored LBS application code. This data can be imported directly into the database without the need for data type conversions. The LBS application code was developed using PL/SQL, an advance type of SQL. The PL/SQL code was compiled into stored procedures that were grouped together to form packages. Oracle packages offer benefits of information sharing and reusability of code. The LBS application code performs the mandatory LBS location query using data stored in the geographical tables and then executes the remaining code using data in the application specific tables. Application specific tables retrieve dynamic data from external system sources like Internet pages and SMS updates about real time event content that affects the LBS application code. The SAGESS implementation architecture utilises the open standard of XML and XSL to create content rich LBS applications. XML was used as XML allows data integration from heterogeneous sources and XML facilitates interoperability between the SAGESS architecture components. XSL was used firstly because it is ideally suited for XML display and secondly because XSL stylesheets can be created and modified in a simple text editor, like notepad. The low cost of XSL stylesheet development will decrease LBS application cost and create a more competitive LBS application.
SAGE presents a LBS development methodology, which is ideally suited for the data centric design of the SAGESS architecture. This next section details the SAGE development steps for the SAGESS technical implementation. 3. The development of SAGE on SAGESS technical implementation 3.1. Step one: development of LBS application code The LBS application code was developed using database stored procedures and packages. Database stored procedures and packages are supported by from a wide range of database companies such as Oracle and the open source database MYSQL. The use of database stored procedures and packages satisfies step 1 of SAGE, as the LBS application code is stored inside the database. 3.2. Step two: data design The data design of application specific tables, geographical tables and user object/tables must follow the guidelines of SAGE naming scheme. The user objects/tables column names are based on the application specific tables and the geometry tables. Once these column names are established, all other user objects/tables are automatically generated from this template. Users data stored inside the database can be either as a table or an object relation table. Object relation tables are recommended, as user specific data types and object functions can be created to speed up the data access. These object functions can also add an extra layer of security. 3.3. Step three: development of display format rule document In step 3, XSL stylesheets are used as the formatting rule documents. The naming scheme for XSL stylesheet nametags are based on the generic names of previous XSL stylesheet name and the table column names definitions. 3.4. Step four: creation of user interface The fourth step of SAGE is the development of the user interface. The SAGE development toolkit is used to develop the user interface as it speeds up developing time and generates a GUI that gathers the required inputs necessary for the LBS stored procedures. 4. Prototype map content The prototype developed generates content rich twodimensional (2D) map images. These images must be able to scale for different screen sizes, be compact in file size and be device independent. Vector based image types are mathematically based, allowing for images to be scaled without loss of quality and have low storage quality. 2D vector based images are available in two contrasting
A. Hand et al. / Electronic Commerce Research and Applications 5 (2006) 201–208
formats: Macromedia Flash and Scaleable Vector Graphics (SVG). Macromedia Flash is a proprietary driven, non-open standard approach to 2D vector graphics. All major desktop Internet browsers support it. It is also supported in a scale down format on the Pocket PC and many 3G mobile devices. W3C made two SVG profiles of full SVG: SVG Tiny and SVG Basic. These two profiles are a susbet of the full SVG and are refered to as Mobile SVG. Mobile SVG was developed because full SVG was deemed to large for mobile devices. SVG Tiny is aimed at content rich wireless mobile phone devices. SVG Basic is aimed at handheld PDA’s. The SRF prototype application dynamically generates SVG images in a range of SVG formats (full and Tiny). The SVG image type content was selected for several reasons. Firstly, its open standards suit the SAGE development methodology. Secondly, it has mobile format designed for wireless communication devices. Finally, SVG delivers the capability to generate intelligent maps that offer greater flexibility than simple raster images (GIF, JPG, etc.). 5. Prototype: service route finder application The SRF is a LBS prototype application that was implemented on the SAGESS technical architecture. SRF was developed using the SAGE DT based on the SAGE development methodology. SRF is a tourist style LBS application that provides localised restaurant information. This type of application has been popular in research areas [16,18,19]. The user can select a restaurant based on the type and price. The SRF prototype application was tested on two areas: Dublin City and New York City. ESRI [20] provided the map for New York City. The map of Dublin City was created by the author and is based on a non-electronic commercial map of the city. The author created the map of Dublin to demonstrate a solution to the problem of obtaining geographical map data, for certain areas. The map creation followed the guidelines of cartography map development and database geometric types. The SRF application has a variety of extra features, such as It finds the shortest route to the service location. It calculates the shortest route based on transport method, dynamic traffic information and road maintenance information. It estimates the arrival time and distance along the route path. It provides a re-routing service; back to the user’s saved location. It provides additional LBS services like the closest ATMs, car parks and monuments along the route. It incorporates a link to the selected restaurant Internet page if present.
205
It allows map images to be scaled and zoom on without loss of quality. The SRF application delivers user specific maps in SVG format. The SVG maps are automatically generated and can be displayed on any Internet browser device that has SVG support. This LBS application code accepts the parameters of the user location coordinates and service criteria. The SRF LBS application code incorporates a shortest route linked-based algorithm. The LBS application code dynamically integrates traffic updates, restaurant and road-works information from the application specific table in order to produce the dynamic shortest route. The author extended the link-based algorithm by adding a service area. The service area is based on the distance from the user’s current location to the service location multiplied by a search size value. The search size value is based on the size of the city. The service area dramatically speeds up the shortest route calculation, as roads outside the service area are excluded from the search. If no route can be found, then the service area is increased. The shortest route algorithm only searches entire roads, so if the start of a motorway is found, the entire motor junction will be included inside the area. The shortest route algorithm takes into consideration road speeds limits and other outside factors. Fig. 2 demonstrates an overview of the SRF technical implementation for Dublin City. An explanation of the data flow through the SRF application is explained in the steps below: 1. User enters the URL address of the LBS application Internet page (Client communication tier). 2. The user selects from the LBS application Internet page his/her restaurant search criteria (type and price range) and their current method of transport (driving or walking). This information along with their current location is sent to the XSQL datapage (Client communication tier). 3. The XSQL datapage sends the formatted query to the SQL-XML translator (Application tier). 4. The SQL/XML translator makes a JDBC connection to the database and executes the stored LBS application code defined in the XSQL datapage (GIS tier). 5. The LBS application code accesses the geographical tables to calculate the user’s location. After this calculation, the LBS application code accesses the application specific tables to find the closest restaurant that meets the user’s criteria. Once the restaurant is found, a dynamic shortest route is calculated based on the user and the restaurant location. The shortest route incorporates external real time event information from its application specific tables (GIS tier). 6. The complete SQL result-set is returned to the SQLXML translator and the XML parser inside creates a dynamic XML document, with the defined XML nametags based on the table column names (Application tier).
206
A. Hand et al. / Electronic Commerce Research and Applications 5 (2006) 201–208
Fig. 2. SRF implementation architecture overview.
7. The XSQL data page then informs the display processor (XSLT) to apply the relevant XSL stylesheet to the dynamic XML document, based on the wireless device capabilities. A SVG stylesheet is applied to the dynamic XML document and a dynamic user specific SVG map image is displayed (Application tier). The SRF application accesses different geographical tables based on transport method (walking, driving, subway, train, etc.). A different shortest route is calculated based on these geographical tables. 5.1. SRF scenarios The SRF prototype application was developed for two test methods of transport: driving and walking. In the first scenario, walking is the method of transport and Dublin City is the test city. In scenario one, the user launches an Internet browser on their wireless communication device and goes to the SRF Internet page for that city. The user then selects from a list of restaurant types and a price ranges per person. The user selects ‘‘French’’ as his/her restaurant type and ‘‘€40’’ as his/her price range. Fig. 3 demonstrates the dynamic SVG map image created from the user’s choices.
The dynamically generated SVG maps offer intelligent map features, not representative in non-electronic maps. These intelligent features include a road text enhancement, route travel details and restaurant Internet address. The dynamically generated SVG maps offer intelligent map features, not representative in non-electronic maps. These intelligent features include a road text enhancement, route travel details and restaurant Internet address hyperlinks. Road text enhancement displays the name of the road in larger text when the user clicks on a road. This feature is designed for better visibility and to resolve issue relating to text on line support in mobile SVG. The user can select the nearest restaurant regardless of type. Fig. 4 below demonstrates the SRF application ability to deliver user centric maps. The map area displayed in Fig. 4 is relevant to the users’ specific queries. The application also produces results when a user selects driving as their desired method of transport and ‘‘French’’ as their restaurant type with a menu price of €40. The user’s current location is the same as the two previous queries. The same XSL for the previous query is used to dynamically generate this map. The dynamically generated map offers all the same capabilities as the Walking XSL in Fig. 4. The SRF application also displays the routing information specific to transport
A. Hand et al. / Electronic Commerce Research and Applications 5 (2006) 201–208
207
Fig. 3. Walking route finder Dublin City.
information feed that was received from an outside source (AA road watch, traffic light statistics, News information feeds). For example, the dynamic outside traffic source informs of a 20-min delay on a street which is on the current route. The SRF application has the ability to adjust the dynamic traffic information in order to recalculate the shortest route. 6. Conclusion
Fig. 4. Dublin City walking nearest restaurant.
means and route selected. The development time and complexity of the car shortest route module into the SRF application was decreased because it is based on the Walking shortest route template and the core application logic. This demonstrates the power of the SAGESS architecture and the SAGE development strategy, as new application areas and product development is possible based on generic templates. The SRF application incorporates dynamic outside traffic information to improve on the LBS application result accuracy. New routes can be calculated based on the traffic
The prototype SRF LBS application was developed to demonstrate the strength of the SAGE development methodology and the capabilities of the SAGESS architecture and to offer content rich intelligent maps on wireless communication devices. The prototype application presented in this paper is a flexible, adaptable and easily maintainable solution; that offers more content rich facilities than any other current (2004) LBS application available. The SAGESS architecture and the SAGE development strategy deliver solutions that are wireless device OS independent, which enables a wide range of devices and technologies to co-exist in the LBS market. This mix of different software and technologies will lead to a strong competitive LBS market place not, that is not dominant by one technology. The use of open source technologies gives LBS developers a wide choice of development environments. This wide choice of technologies should decrease LBS application development cost and time.
208
A. Hand et al. / Electronic Commerce Research and Applications 5 (2006) 201–208
In conclusion, the SAGESS architecture and the SAGE development methodology offer substantial advantages to LBS application developers, LBS content providers, LBS customers and the LBS market place. The SAGE DT provides a cross platform LBS development toolkit that does not require complex installation or training to use. SAGESS and SAGE solve existing LBS development problems and produces cost-effective LBS applications. The use of a clearly define development methodology combined with the appropriate architecture, enables a content rich single solution to be applied to all wireless Internet devices. This solution can have in-depth functionality without placing a large strain on the user wireless device resources.
[11]
References
[12]
[1] Takeshi Natsuno, NTT DoCoMo’s I-mode service, in: Proc. Mobile Software Forum, September, London, UK, 1999. [2] J.D. Wilson, Mobile Technology Takes GIS to the Field. GEOWord, June, 2000. [3] Albena Mihovska, Jorge M. Pereira, Location-based VAS:filler applications for the next-generation mobile Interne, in: Personal, Indoor and Mobile Radio Communication, 2001 12th IEEE International Symposium, October, 2001. [4] Strategis Group, European Wireless Location Services, April, 2000. [5] Analysis, Mobile Location Services and Technologies, 2001. [6] IT’s Alive, LBS game, Botfighters, 2004 (on-line). (accessed 26.05.04). [7] A. Zipf, R. Malaka, Developing ‘‘location based services’’ (LBS) for tourism – The service providers view, in: P. Sheldon, K. Wo¨ber, D.
[8]
[9]
[10]
[13] [14] [15] [16] [18]
[19]
[20]
Fesenmaier (Eds.), Information and Communication Technologies in Tourism 2001, Proceedings of ENTER 2001, 8th International Conference. Montreal, Springer Computer Science, Wien, NewYork, pp. 83–92. M. Lo¨yto¨nen, Mobile devices and GIS in health – new opportunities and threats, in: Proceedings of the First European Conference for Geographic Information Sciences in Public Health, September, Sheffield, UK, 2001. Aphrodite Tsalgatidou, Jari Veijalainen, Requirements for mobile ecommerce. Paper presented in eWork and eBusiness Conference, Madrid, Spain, 18–20 October, 2000, in: Brian Stanford-Smith, Paul T. Kidd (Eds.), E-Business: Key Issues, Applications and Technologies, IOS Press, 2000, pp. 1037–1043. Webraska Mobile Technologies. Information on Webraska, services on LBS products and applications, 2002 (on-line). (accessed 27.02.03). ESRI, Orange Slovensko Uses ESRI’s GIS Software and Solutions for Location-Based Services. Directions Magazine, March 06, 2003. 02, 2004. Information on 02 XDA II (on-line). (accessed 03.04.04). ESRI, Information on ESRI, 2004 (on-line). http://www.esri.com (accessed 26.05.04).
An architecture and development methodology for location-based services Aaron Hand, John Cardiff, Patricia Magee *, Jimmy Doody Institute of Technology Tallaght, Dublin, Ireland Received 10 June 2005; received in revised form 25 July 2005; accepted 1 September 2005 Available online 21 April 2006
Abstract This paper presents SAGESS (spatial application generic environment system standards), an open framework location-based services (LBS) development architecture. It can be implemented without any third party software, and provides LBS developers with complete development control and technology choices. It also describes SAGE (spatial application generic environment), a methodology for creating LBS applications. It has the advantage of creating LBS applications that are light on the wireless device resources and are OS independent. It gives LBS developers the capability to build LBS applications based on generic templates, decreasing development cost and time. This paper presents a study of the deployment of a prototype LBS application on the SAGESS architecture platform, developed using the SAGE development toolkit. Ó 2006 Elsevier B.V. All rights reserved. Keywords: Location-based services; Development methodologies
1. Introduction Wireless telecommunication technology advances and the mass integration of wireless communication devices into society have created the next generation of computing, the mobile generation. The mobile generation does not restrict users to a fixed desktop location but allows anywhere anytime mobile computing. Wireless devices are no longer just simple communication devices and the demand for non-voice services have already been demonstrated by GSM’s short message service (SMS) and Japan’s NTT DoCoMo’s imode services [1]. NTT DoCoMo’s imode Internet services have signed about 2 million customers in a little over two years since its release. The future of most enterprise systems will be based on their adaptation to this mobile era [2] and applications built that can take advantage of this era. The applications
*
Corresponding author. Fax: +353 1404 2700. E-mail address: [email protected] (P. Magee).
1567-4223/$ - see front matter Ó 2006 Elsevier B.V. All rights reserved. doi:10.1016/j.elerap.2005.09.006
expected to dominate the mobile generation are locationbased services (LBS). LBS applications are accessible with a wireless telecommunication device through a telecommunication network and exploit the ability of a wireless device location to provide a service. LBS applications provide services like ‘‘Where is the closest restaurant?’’ ‘‘How do I get back to my house from here?’’ ‘‘Where is my friend located?’’ LBS have been identified as the ‘‘next killer application area’’ [3] with an industrial revenue prediction of over $32 billion in Europe by 2005 [4] and an expected $680 million global customer base by 2006 [5]. LBS applications have a mandatory requirement for location information. This information is obtained in geocoordinate format based on a geographical coordinate system used. This location information must then be spatially processed to determine the user’s location. The spatial processing involves the comparison of the geocoordinate to the spatial data stored inside a data reservoir. This mandatory manipulation of stored data makes LBS applications data intensive Error! Reference source not found. . . In many cases, LBS applications are required to
202
A. Hand et al. / Electronic Commerce Research and Applications 5 (2006) 201–208
manipulate and access stored data multiple times in order to produce the LBS solution. The more accurate and diverse the stored spatial data is, the more accurate and in-depth the LBS solution will be. There are various different LBS applications in many different commercial sections like tourism [7], business, health [8] and gaming [6]. LBS tourist applications provide a wide range of localised information: landmarks, restaurants, petrol stations, ATM locations, etc. Tourist information services must deliver content that is culturally correct and suited for the user’s wireless device. Mobile commerce or m-commerce is another type of LBS applications. Mobile users receive information about sales and prices of goods that are in their area. The user can buy these goods while on the move and collect them a few minutes later. This concept is the same as e-commerce [9] except that the user’s location is taken into consideration. M-commerce must address privacy issues and security of payment. LBS applications can be used to track the movement of goods, vehicles people, packages etc. The tracking of truck vehicles is commonplace but LBS applications could be used to track goods indoors. The tracking of goods inside a vehicle can assist in making last minute delivery changes. A LBS application could be used to calculate the shortest route for the truck and its cargo. LBS applications can assist in goods retrieval if stolen. A LBS application can be used to locate an emergency phone call location. This would assist rescue teams to arrive at the location faster. The call location would also assist the dispatcher to select the rescue services that is geographical the closest to the caller. By using emergency call location and routing LBS application, the fire brigade could arrive at the fire by the fastest possible route, considering dynamic features like traffic congestion. Games that can incorporate location information would provide an additional challenge to mobile game playing. This type of gaming is already starting to be released but with requirements for Java enabled phones to avail of the full functionality has caused user acceptance to be slow. A LBS application can assist with navigation and routing. Dynamic traffic information can be sent to a user about roadblocks or traffic congestion along a route. LBS applications can calculate the shortest route from the user’s current location considering all these factors. LBS applications development is starting to progress with a wide range of LBS development companies. Webraska, an LBS solution provider, developed the ParisDakar Motorcycle Race [10] tracking LBS application. Orange Slovensko, the Slovakian telecommunication company, developed an LBS application [11] for locating facilities such as hotels, ATMs, fuel stations, restaurants, etc. This LBS application is available on wireless devices by SMS or WAP (GPRS) and uses Cell ID for wireless device location. IT’s Alive, a Swedish LBS game company, devel-
oped the Botfighters [6] LBS game. In Botfighters, players run around chasing other players out in the streets. Game interaction is by SMS. To have more interactive functionality, a Java J2ME application must be installed on the wireless device Botfighters is available in Sweden, Finland, Ireland and Russia. Location-based services (LBS) provide users of mobile devices with personalized services tailored to their current location. They open a new market for developers, cellular network operators, and service providers to develop and deploy value-added services: advising users of current traffic conditions, supplying routing information, helping them find nearby restaurants, and many more. The author developed a prototype application: Service Route Finder (SRF) using the SAGE Development Toolkit. The prototype was developed following the SAGE development methodology and deployed on the SAGESS technical implementation architecture. The Service Route Finder (SRF) LBS application is a dynamic mobile solution for locating services (restaurants, ATM’s, hotels, cinema, etc.) on low resource devices over standard communication protocols. This paper begins with a description of the SAGESS technical implementation in Section 2 and how the SAGE guidelines apply. Section 3 then details the implementation structure and features of the SRF application. Section 4 gives an overview of the map content used in the prototype. The paper continues by explaining the development of the prototype application in Section 5. The conclusions from this study are presented in Section 5 with particular emphasis on the usefulness of the SAGESS architecture and the SAGE development methodology for LBS application developers, and the other players in the LBS market place. 2. SAGESS technical implementation architecture The SAGESS generic platform is a three-tier architecture, with three internal components. This section details the architecture of SAGESS, on which the prototype was developed. Fig. 1, demonstrates an overall diagram of the SAGESS architecture. The numbers in the diagram represent the flow of data through the architecture. 2.1. Client communication tier The client communication tier is a protocol independent tier, where the users’ location is established and where communication with the application tier occurs. Users can be any person with a wireless communication device that has Internet capabilities. Wireless devices with Internet connections range from the simple Siemens C60 to the multifunctional 02 XDK II [12]. The user accesses the LBS application by entering the application Uniform Resource Locator (URL) in to their Internet browser. Any location method (A-GPS, COO, Bluetooth, etc.) can be used to locate the user’s current
A. Hand et al. / Electronic Commerce Research and Applications 5 (2006) 201–208
203
Fig. 1. SAGESS architecture.
location. A user geographical coordinates can be of any format, including a height factor for users who are up a mountain. Wireless communication between the client communication tier and the application tier can be achieved by any form of wireless Internet protocol communication or technology, such as GPRS on 2.5 G networks, EDGE on 3 G networks, or imode packet switching technology. At the Client communication tier the users interact with the LBS application Internet page and choose their LBS application options. 2.2. Application tier The application tier performs all result-set mark-up into the appropriate output display for the user’s wireless device. On the application tier SAGESS generic architecture has two components: a SQL transformer and a display processor. The SQL/XML transformer was implemented using the Oracle XDK for Java component. This technology offers many different types of XML parsing based on different technologies. The key component inside the XDK package is the XML SQL Utility (XSU) for Java. The XML SQL Utility (XSU) for Java generates dynamic XML documents from SQL queries. This utility can be called from inside a Java application or as standalone XSQL data pages.
The XSU can output data as text, Document Object Model or a JDBC Result Set Object. XSU supports all data types supported in Oracle 9i database server and table operations (inserts, updates and deletes). This is a key point when dealing with complex Oracle geometry types, which contain three different array type structures. XSU performs database connections through JDBC drivers. Oracle provides specific JDBC drivers to optimise performance, but XSU will run with any industrial accepted JDBC driver. In the dynamic XML documents generated, nametags correspond to the table column names inside the database, and the value between the nametags corresponds to the table column value. The display processor was implemented using an eXtensible Stylesheet Transformations (XSLT) processor. A XSLT processor transforms or renders XML documents based on the formatting rules defined in the XSL stylesheet. There are many free XSLT processors and many come preinstalled with Internet servers. The XSLT processor can render XML document into a specific or a range of different markup formats (SVG, HTML, PDF, WML, VRML), depending on the wireless device capabilities. XSLT processors apply XSL stylesheets, which detail how XML nametags will be displayed. For example, a HTML XSL can define a XML nametag be displayed as bold text in a HTML document, where in a SVG XSL the same XML document nametag could be a heading on top of a diagram.
204
A. Hand et al. / Electronic Commerce Research and Applications 5 (2006) 201–208
The developing language XSQL (XML/SQL) is implemented on the application tier to inform the XML SQL utility what SQL query to execute and which XSL stylesheet to apply. XSQL is the control file that invokes the two application tier components. XSQL are text documents that are based on the open standards of XML. The SQL translator formats SQL result sets into an open source format. The use of open source formats means that a wide range of development language such as Java, C, and C++ can be used to coordinate the SQL translator and display processor. XSQL was chosen as its execution times are much faster with the application components and the Internet server recompiles XSQL files, making changes instantly effective. 2.3. Geographic information system tier The Geographic information system (GIS) information tier will perform all LBS application query processing. The GIS tier stores, modifies and retrieves spatial data sets based on the LBS application query from the application tier SQL/XML transformer component. The spatial database chosen was Oracle 9i with Spatial Cartridge option, implemented on Red Hat Linux 8 and Red Hat Linux 9. Oracle was chosen, as it is one of the most popular if not arguably the most popular database in the world. Oracle was also used in other LBS architectures [13–15] and was the database for J-Phone J-Navi [16]. The Oracle database is made up of three structures: geographical tables, application specific tables and stored LBS application code. This data can be imported directly into the database without the need for data type conversions. The LBS application code was developed using PL/SQL, an advance type of SQL. The PL/SQL code was compiled into stored procedures that were grouped together to form packages. Oracle packages offer benefits of information sharing and reusability of code. The LBS application code performs the mandatory LBS location query using data stored in the geographical tables and then executes the remaining code using data in the application specific tables. Application specific tables retrieve dynamic data from external system sources like Internet pages and SMS updates about real time event content that affects the LBS application code. The SAGESS implementation architecture utilises the open standard of XML and XSL to create content rich LBS applications. XML was used as XML allows data integration from heterogeneous sources and XML facilitates interoperability between the SAGESS architecture components. XSL was used firstly because it is ideally suited for XML display and secondly because XSL stylesheets can be created and modified in a simple text editor, like notepad. The low cost of XSL stylesheet development will decrease LBS application cost and create a more competitive LBS application.
SAGE presents a LBS development methodology, which is ideally suited for the data centric design of the SAGESS architecture. This next section details the SAGE development steps for the SAGESS technical implementation. 3. The development of SAGE on SAGESS technical implementation 3.1. Step one: development of LBS application code The LBS application code was developed using database stored procedures and packages. Database stored procedures and packages are supported by from a wide range of database companies such as Oracle and the open source database MYSQL. The use of database stored procedures and packages satisfies step 1 of SAGE, as the LBS application code is stored inside the database. 3.2. Step two: data design The data design of application specific tables, geographical tables and user object/tables must follow the guidelines of SAGE naming scheme. The user objects/tables column names are based on the application specific tables and the geometry tables. Once these column names are established, all other user objects/tables are automatically generated from this template. Users data stored inside the database can be either as a table or an object relation table. Object relation tables are recommended, as user specific data types and object functions can be created to speed up the data access. These object functions can also add an extra layer of security. 3.3. Step three: development of display format rule document In step 3, XSL stylesheets are used as the formatting rule documents. The naming scheme for XSL stylesheet nametags are based on the generic names of previous XSL stylesheet name and the table column names definitions. 3.4. Step four: creation of user interface The fourth step of SAGE is the development of the user interface. The SAGE development toolkit is used to develop the user interface as it speeds up developing time and generates a GUI that gathers the required inputs necessary for the LBS stored procedures. 4. Prototype map content The prototype developed generates content rich twodimensional (2D) map images. These images must be able to scale for different screen sizes, be compact in file size and be device independent. Vector based image types are mathematically based, allowing for images to be scaled without loss of quality and have low storage quality. 2D vector based images are available in two contrasting
A. Hand et al. / Electronic Commerce Research and Applications 5 (2006) 201–208
formats: Macromedia Flash and Scaleable Vector Graphics (SVG). Macromedia Flash is a proprietary driven, non-open standard approach to 2D vector graphics. All major desktop Internet browsers support it. It is also supported in a scale down format on the Pocket PC and many 3G mobile devices. W3C made two SVG profiles of full SVG: SVG Tiny and SVG Basic. These two profiles are a susbet of the full SVG and are refered to as Mobile SVG. Mobile SVG was developed because full SVG was deemed to large for mobile devices. SVG Tiny is aimed at content rich wireless mobile phone devices. SVG Basic is aimed at handheld PDA’s. The SRF prototype application dynamically generates SVG images in a range of SVG formats (full and Tiny). The SVG image type content was selected for several reasons. Firstly, its open standards suit the SAGE development methodology. Secondly, it has mobile format designed for wireless communication devices. Finally, SVG delivers the capability to generate intelligent maps that offer greater flexibility than simple raster images (GIF, JPG, etc.). 5. Prototype: service route finder application The SRF is a LBS prototype application that was implemented on the SAGESS technical architecture. SRF was developed using the SAGE DT based on the SAGE development methodology. SRF is a tourist style LBS application that provides localised restaurant information. This type of application has been popular in research areas [16,18,19]. The user can select a restaurant based on the type and price. The SRF prototype application was tested on two areas: Dublin City and New York City. ESRI [20] provided the map for New York City. The map of Dublin City was created by the author and is based on a non-electronic commercial map of the city. The author created the map of Dublin to demonstrate a solution to the problem of obtaining geographical map data, for certain areas. The map creation followed the guidelines of cartography map development and database geometric types. The SRF application has a variety of extra features, such as It finds the shortest route to the service location. It calculates the shortest route based on transport method, dynamic traffic information and road maintenance information. It estimates the arrival time and distance along the route path. It provides a re-routing service; back to the user’s saved location. It provides additional LBS services like the closest ATMs, car parks and monuments along the route. It incorporates a link to the selected restaurant Internet page if present.
205
It allows map images to be scaled and zoom on without loss of quality. The SRF application delivers user specific maps in SVG format. The SVG maps are automatically generated and can be displayed on any Internet browser device that has SVG support. This LBS application code accepts the parameters of the user location coordinates and service criteria. The SRF LBS application code incorporates a shortest route linked-based algorithm. The LBS application code dynamically integrates traffic updates, restaurant and road-works information from the application specific table in order to produce the dynamic shortest route. The author extended the link-based algorithm by adding a service area. The service area is based on the distance from the user’s current location to the service location multiplied by a search size value. The search size value is based on the size of the city. The service area dramatically speeds up the shortest route calculation, as roads outside the service area are excluded from the search. If no route can be found, then the service area is increased. The shortest route algorithm only searches entire roads, so if the start of a motorway is found, the entire motor junction will be included inside the area. The shortest route algorithm takes into consideration road speeds limits and other outside factors. Fig. 2 demonstrates an overview of the SRF technical implementation for Dublin City. An explanation of the data flow through the SRF application is explained in the steps below: 1. User enters the URL address of the LBS application Internet page (Client communication tier). 2. The user selects from the LBS application Internet page his/her restaurant search criteria (type and price range) and their current method of transport (driving or walking). This information along with their current location is sent to the XSQL datapage (Client communication tier). 3. The XSQL datapage sends the formatted query to the SQL-XML translator (Application tier). 4. The SQL/XML translator makes a JDBC connection to the database and executes the stored LBS application code defined in the XSQL datapage (GIS tier). 5. The LBS application code accesses the geographical tables to calculate the user’s location. After this calculation, the LBS application code accesses the application specific tables to find the closest restaurant that meets the user’s criteria. Once the restaurant is found, a dynamic shortest route is calculated based on the user and the restaurant location. The shortest route incorporates external real time event information from its application specific tables (GIS tier). 6. The complete SQL result-set is returned to the SQLXML translator and the XML parser inside creates a dynamic XML document, with the defined XML nametags based on the table column names (Application tier).
206
A. Hand et al. / Electronic Commerce Research and Applications 5 (2006) 201–208
Fig. 2. SRF implementation architecture overview.
7. The XSQL data page then informs the display processor (XSLT) to apply the relevant XSL stylesheet to the dynamic XML document, based on the wireless device capabilities. A SVG stylesheet is applied to the dynamic XML document and a dynamic user specific SVG map image is displayed (Application tier). The SRF application accesses different geographical tables based on transport method (walking, driving, subway, train, etc.). A different shortest route is calculated based on these geographical tables. 5.1. SRF scenarios The SRF prototype application was developed for two test methods of transport: driving and walking. In the first scenario, walking is the method of transport and Dublin City is the test city. In scenario one, the user launches an Internet browser on their wireless communication device and goes to the SRF Internet page for that city. The user then selects from a list of restaurant types and a price ranges per person. The user selects ‘‘French’’ as his/her restaurant type and ‘‘€40’’ as his/her price range. Fig. 3 demonstrates the dynamic SVG map image created from the user’s choices.
The dynamically generated SVG maps offer intelligent map features, not representative in non-electronic maps. These intelligent features include a road text enhancement, route travel details and restaurant Internet address. The dynamically generated SVG maps offer intelligent map features, not representative in non-electronic maps. These intelligent features include a road text enhancement, route travel details and restaurant Internet address hyperlinks. Road text enhancement displays the name of the road in larger text when the user clicks on a road. This feature is designed for better visibility and to resolve issue relating to text on line support in mobile SVG. The user can select the nearest restaurant regardless of type. Fig. 4 below demonstrates the SRF application ability to deliver user centric maps. The map area displayed in Fig. 4 is relevant to the users’ specific queries. The application also produces results when a user selects driving as their desired method of transport and ‘‘French’’ as their restaurant type with a menu price of €40. The user’s current location is the same as the two previous queries. The same XSL for the previous query is used to dynamically generate this map. The dynamically generated map offers all the same capabilities as the Walking XSL in Fig. 4. The SRF application also displays the routing information specific to transport
A. Hand et al. / Electronic Commerce Research and Applications 5 (2006) 201–208
207
Fig. 3. Walking route finder Dublin City.
information feed that was received from an outside source (AA road watch, traffic light statistics, News information feeds). For example, the dynamic outside traffic source informs of a 20-min delay on a street which is on the current route. The SRF application has the ability to adjust the dynamic traffic information in order to recalculate the shortest route. 6. Conclusion
Fig. 4. Dublin City walking nearest restaurant.
means and route selected. The development time and complexity of the car shortest route module into the SRF application was decreased because it is based on the Walking shortest route template and the core application logic. This demonstrates the power of the SAGESS architecture and the SAGE development strategy, as new application areas and product development is possible based on generic templates. The SRF application incorporates dynamic outside traffic information to improve on the LBS application result accuracy. New routes can be calculated based on the traffic
The prototype SRF LBS application was developed to demonstrate the strength of the SAGE development methodology and the capabilities of the SAGESS architecture and to offer content rich intelligent maps on wireless communication devices. The prototype application presented in this paper is a flexible, adaptable and easily maintainable solution; that offers more content rich facilities than any other current (2004) LBS application available. The SAGESS architecture and the SAGE development strategy deliver solutions that are wireless device OS independent, which enables a wide range of devices and technologies to co-exist in the LBS market. This mix of different software and technologies will lead to a strong competitive LBS market place not, that is not dominant by one technology. The use of open source technologies gives LBS developers a wide choice of development environments. This wide choice of technologies should decrease LBS application development cost and time.
208
A. Hand et al. / Electronic Commerce Research and Applications 5 (2006) 201–208
In conclusion, the SAGESS architecture and the SAGE development methodology offer substantial advantages to LBS application developers, LBS content providers, LBS customers and the LBS market place. The SAGE DT provides a cross platform LBS development toolkit that does not require complex installation or training to use. SAGESS and SAGE solve existing LBS development problems and produces cost-effective LBS applications. The use of a clearly define development methodology combined with the appropriate architecture, enables a content rich single solution to be applied to all wireless Internet devices. This solution can have in-depth functionality without placing a large strain on the user wireless device resources.
[11]
References
[12]
[1] Takeshi Natsuno, NTT DoCoMo’s I-mode service, in: Proc. Mobile Software Forum, September, London, UK, 1999. [2] J.D. Wilson, Mobile Technology Takes GIS to the Field. GEOWord, June, 2000. [3] Albena Mihovska, Jorge M. Pereira, Location-based VAS:filler applications for the next-generation mobile Interne, in: Personal, Indoor and Mobile Radio Communication, 2001 12th IEEE International Symposium, October, 2001. [4] Strategis Group, European Wireless Location Services, April, 2000. [5] Analysis, Mobile Location Services and Technologies, 2001. [6] IT’s Alive, LBS game, Botfighters, 2004 (on-line).
[8]
[9]
[10]
[13] [14] [15] [16] [18]
[19]
[20]
Fesenmaier (Eds.), Information and Communication Technologies in Tourism 2001, Proceedings of ENTER 2001, 8th International Conference. Montreal, Springer Computer Science, Wien, NewYork, pp. 83–92. M. Lo¨yto¨nen, Mobile devices and GIS in health – new opportunities and threats, in: Proceedings of the First European Conference for Geographic Information Sciences in Public Health, September, Sheffield, UK, 2001. Aphrodite Tsalgatidou, Jari Veijalainen, Requirements for mobile ecommerce. Paper presented in eWork and eBusiness Conference, Madrid, Spain, 18–20 October, 2000, in: Brian Stanford-Smith, Paul T. Kidd (Eds.), E-Business: Key Issues, Applications and Technologies, IOS Press, 2000, pp. 1037–1043. Webraska Mobile Technologies. Information on Webraska, services on LBS products and applications, 2002 (on-line).