Mobile Access to Distributed Data Sources

Transcription

1 Mobile Access to Distributed Data Sources Alessandro Andreadis, Giuliano Benelli, Pasquale Fedele, and Giovanni Giambene Dipartimento di Ingegneria dell Informazione - Università degli Studi di Siena, Via Roma, Siena, ITALY, {andreadis,benelli,giambene}@unisi.it, f.pasquale@tin.it Abstract. The widespread diffusion of mobile communication systems is paving the way for new information services to be provided to users. This paper deals with the Personalised Access to Local Information and services for tourists (PALIO-IST 20656) Project within the fifth research framework of the European Commission. The focus is on tourists that need to access information on the city or on the region they are visiting by means of a mobile device (e.g., a cellular phone) or at specific locations (kiosks). The PALIO project will experiment innovative solutions for providing information contents to users in different formats and for accessing distributed databases. An architectural approach and technical solutions towards the realization of personalized and context-aware mobile information services are here presented. 1 Introduction The Personalised Access to Local Information and services for tourists (PALIO- IST 20656) project aims at providing tourist services to mobile and fixed users for facilitating their city sightseeing [1]. In the PALIO Project, the user must be able to access services not only by using a common personal computer at home, but also on site, by means of a cellular phone or a Personal Digital Assistant (PDA). Accordingly, the provision of personalized services anywhere and anytime requires that the information system be adaptable and scalable, depending on heterogeneous client devices (e.g., different displays, computation capabilities, software releases), user preferences and access networks (e.g., available bit-rate). Content adaptation to the access device implies to provide the contents with suitable markup languages; whereas, the adaptation to the access technology will require the adoption of scalability of the presented content still allowed by means of markup languages, as explained later in this paper. Within the PALIO system, the Augmented Virtual City centre (AVC) adapts the presentation of information to the different access and client technologies (see Fig. 1). The PALIO Project prototype will test real-time information on traffic situation and location-specific information for tourists. PALIO test sites will be carried out in the island of Crete (Greece) and in the towns of Siena and Florence (Italy). The PALIO partners are: ASSIOMA S.p.A. (I), Florence Municipality (I), Forschungszentrum Informationtechnik GmbH A.B. Chaudhri et al. (Eds.): EDBT 2002 Workshops, LNCS 2490, pp , c Springer-Verlag Berlin Heidelberg 2002

2 Mobile Access to Distributed Data Sources 463 (D), FORTHnet S.A. (GR), Foundation Research & Technology (GR), MA Systems and Control Ltd. (UK), National Research Council (I), Siena Municipality (I), Telecom Italia Mobile S.p.A. (I) and University of Siena (I). Fig. 1. PALIO general architecture. 2 System Architecture The general system architecture shown in Fig. 1 encompasses four main building blocks: the communication platform comprising the Internet, network interfaces and gateways necessary to integrate the distributed components of the PALIO system; the AVC, with adaptation and control functions; the Distributed Information Centres in the territory, that are the data sources; the Localization Systems, needed to identify the position of the tourist in outdoor environments (i.e., GPS and/or mobile network based solutions; indoor solutions are under investigation). The communication platform, based on the HTTP protocol [2], allows the interconnection of the different and geographically dispersed elements of the PALIO system. In particular, the elements of the communication platform are the WAP/SMS server [3], the gateway towards the mobile (GSM/GPRS/UMTS)

3 464 A. Andreadis et al. network (including also the location server [4] of the mobile operator) and the gateway towards the fixed (ISDN/PSTN) network. The AVC centre consists of the following elements: The User Communication Layer (UCL), an abstract entity allowing the communication of the AVC with the other servers (i.e., Web&WAP server, WAP gateway, SMS server, and localization server), in a common format; The Service Control Centre (SCC), the heart of the PALIO system. It provides the runtime platform for the system information services; The Generic Information Server (GIS) for allowing the access to the distributed information space through the Internet. In particular, the GIS permits the information retrieval from distributed databases and provides the obtained contents in a common format for the SCC; The adaptation infrastructure, responsible for content and interface adaptation in the PALIO system. It represents one of the most innovative technological developments of the PALIO Project. This infrastructure is composed of an Adapter, a User Model Server (UMS) and a Context Model Server (CMS). The Adapter is the basic adaptation component of the system. It integrates information concerning the user, the context of use, the access environment and the interaction history. It provides adaptation guidelines to be adopted in the SCC to produce an adapted output content and representation. The UMS integrates and manages information concerning user characteristics (e.g., interests, interaction style, disabilities) in the forms of both individual user profiles (constructed during interactive sessions) and user stereotypes (for groups of users that share a number of characteristics). Finally, the CMS assembles context profiles, by using information retrieved from the Usage Context Repository (UCR) and informs the adapter about the current context. 3 System Model We can consider the SCC as a round-robin task engine that manages the flow of operations within the AVC, as detailed below with the steps represented in Fig. 2. Java [5] and XML technologies will be the basis for the realization of an integrated environment for information retrieval and representation in the PALIO project. Java, as programming language for server side applications, supports servlets, an efficient approach for creating Web applications, and Java Server Pages (JSP) [6],[7], an easy solution for generating documents based on markup languages (e.g., XML). Here, we describe the required steps from the generation of the client request, to the final response of the system (Fig. 2).

4 Mobile Access to Distributed Data Sources The request from the client (i.e., the tourist) reaches the SCC by means of the HTTP protocol through the UCL. The UCL transforms the request in an XML file, before passing it to the SCC. The UCL is also responsible for requesting the position information, according to the selected localization method. 2. The SCC acquires from the client request all the necessary information (i.e., user identification, user agent type, location and type of request). 3. The Adapter receives the information regarding the request, the user, the client device, the client agent and the location and forwards it to both UMS and CMS. The adapter also forwards some parts of the request to the decision making engine, which holds adaptation rules and a decision making model. 4. The decision making engine requests and gets from the UMS and the CMS the appropriate user and context based information. 5. UMS and CMS get from the relevant repositories the user profile and the context situation (UCR). 6. UMS and CMS update the user profiles and the context situations, respectively, by using the information coming from step The decision taken by the decision making engine is mapped to a proper adaptation action. 8. The adaptation action is passed to the SCC. 9. The request is adapted by the SCC on the basis of the instructions from step The request is analyzed before forwarding it to the GIS. 11. The request is forwarded to GIS. 12. The request is analyzed in order to formulate the necessary query to interrogate the database that contains the desired information. 13. Queries are forwarded to data sources. 14. The response is generated. 15. The responses are forwarded to SCC.

5 466 A. Andreadis et al. 16. All the information (provided by the GIS in XML format) is collected within the SCC. 17. The response is assembled by the SCC with the help of instructions passed from step 8 and with some service domain rules. 18. Final construction of the response. 19. The XML response is generated and sent to the UCL. 4 Technical Implementations We describe below the present achievements within the PALIO Project. 4.1 Identification of the Client Device When a user makes a request to the PALIO system, the AVC is able to identify the client device characteristics by extracting information contained in the header of the received HTTP packet. This task can be performed by a Java servlet. The packet header fields used for this purpose are: HTTP ACCEPT, containing the list of the Multipurpose Internet Mail Extensions (MIME) types accepted by the client; HTTP USER AGENT, listing the most significant products information about the client. It is a string like product/version. Thus, the AVC is able to identify the capabilities of a client device, such as the accepted MIME types, display size, browser type and version, etc. This information allows defining terminal classification rules used by the Adapter. Such rules can be either very specific (by using name and product version) or generic (based on accepted MIME types; e.g., WML or HTML browser support). 4.2 Metadata Schema Language XML has been adopted as the communication language within the building blocks of the AVC. XML describes a class of data objects called XML documents and partially describes the behavior of computer programs that process them [8]. XML is a flexible way to create common information formats and share both the format and the data on the World Wide Web, Intranets and elsewhere. The process followed to create XML documents is:

6 Mobile Access to Distributed Data Sources 467 Fig. 2. Flow control within the AVC. Identify all the objects defined in the ontology. For each object, identify its attributes. Based on the above, create a schema, a description of the syntax and semantics of an XML document. Use of the schema to create an XML document.

7 468 A. Andreadis et al. The design of a schema language for XML data is actually a difficult procedure, and there have been a number of proposals; among them, we consider: DTD (part of XML 1.0), and XML Schema. A Document Type Definition (DTD) describes and validates the structure of a specific type of XML document. In other words, the DTD describes the valid XML tags, the order of the tags, whether the tags are optional, the type of data contained within the tags, the tag attributes, the attribute values, processing instructions, entities, and so on. An XML Schema is used for the description and the validation of both the structure and the content of an XML document. XML Schema main modeling primitives are elements. Elements may be simple, composed or mixed. XML Schema also allows the definition of stronger requirements via a grammar: sequence and choice of attributes applied to an instance can be defined. The notion of type-derivation is also incorporated in the XML Schema. As mentioned before, the main difference between XML Schema and DTD is that the second one can t validate the content of an XML document. That means that it is impossible to create a Java class starting from a DTD since it is not typed; every element is processed as a string. Since it is necessary to include types, it would be better for the PALIO System to use XML Schema instead of DTD. 4.3 Integration of Distributed Data Sources Two slightly different approaches regarding the communication of the GIS with the Distributed Information Servers can be adopted in the PALIO Project. The first approach is based on the Mappamondo database, that provides a mapping of the available data sources. Mappamondo supplies all the parameters needed for accessing the DBs (URL, driver, user id, password, etc) and a link to an XML file (see Fig. 3) describing the structure of every data source. In this way it is possible to know which data source contains the information requested by the user and the necessary parameters for the access. Data are extracted by means of Standard Query Language (SQL) queries and Java Database Connectivity (JDBC) connections; then, they are encapsulated in XML tags and finally the XML response is generated from the GIS and delivered to the SCC. The second approach is based on the Simple Object Access Protocol (SOAP) [9]. SOAP is a lightweight XML-based protocol for the exchange of information in a decentralized, distributed environment. SOAP consists of three parts: (i) the SOAP envelope construct defines an overall framework for expressing what is in a message, who should deal with it, and whether it is optional or mandatory; (ii) the SOAP encoding rules define a serialization mechanism that can be used to exchange instances of application-defined data types; (iii) the SOAP RPC representation defines a convention that can be used to represent remote procedure calls and responses. According to this approach, an XML document containing the user query is sent to the GIS from the SCC. The role of the GIS is to forward this document to the appropriate Distributed Information Server, so that the needed information can be retrieved. The main difference from the Mappamondo approach is that in this case the GIS does not communicate directly

8 Mobile Access to Distributed Data Sources 469 with the Distributed Information Servers, but with the corresponding middleware developed for each Information Server. Fig. 3. Structure of the Mappamondo database. Each middleware consists of a SOAP Server, containing information regarding the structure of the corresponding Information Server. In order to decide to which middleware user request is to be forwarded, a registry database is stored in the GIS, which contains several predefined geographical keywords. Each keyword is related to a middleware (through its IP and the address of the SOAP router). The role of the middleware is to retrieve data from the Information Server. As before, the data are extracted by means of SQL queries and JDBC connections. Then, the middleware formats these data (with predefined XML tags) and generates XML responses to be sent to the GIS. 4.4 Query Building and Execution One of the main characteristics of the PALIO system is the possibility to integrate and access multiple heterogeneous databases. The ideal approach is the JDBC API. JDBC has the advantage of enabling Java programs to execute SQL statements and therefore to interact with SQL-compliant databases, which are most common databases. JDBC drivers are divided into four types or levels:

9 470 A. Andreadis et al. Type 1: JDBC-ODBC Bridge. Type 1 driver translates all JDBC calls into ODBC (Open DataBase Connectivity) calls and sends them to the ODBC driver. As such, the ODBC driver, as well as, in many cases, the client database code, must be present on the client machine. Type 2: Native-API/partly Java driver. JDBC driver type 2 converts JDBC calls into database specific calls for databases such as SQL Server, Informix, Oracle, or Sybase. Type 2 driver communicates directly with the database server; therefore, it requires that some binary code be present on the client machine. Type 3: Net-protocol/all-Java driver. JDBC driver type 3 follows a three-tier approach [10] whereby the JDBC database requests are passed through the network to the middle-tier server. Then, the middle-tier server translates the request (directly or indirectly) to the database-specific native-connectivity interface to send the request to the database server. If the middle-tier server is written in Java; it can use a type 1 or type 2 JDBC driver. Type 4: Native-protocol/all-Java driver. JDBC driver type 4 converts JDBC calls into the vendor-specific DataBase Management System (DBMS) protocol so that client applications can communicate directly with the database server. Level 4 drivers are completely implemented in Java to achieve platform independence and to eliminate the management of administration issues. In PALIO, the phases preceding the databases access (e.g., adaptation, metadata consulting) allow acquiring all the necessary parameters to access distributed databases: database URL, drivers, userid, password, tables and field names that contains the requested information, etc. Such parameters can be supplied to a Java servlet that executes the query statements and generates the results in XML format. 5 Conclusions This paper has presented an architectural approach, based on the PALIO Project, towards the realization of personalized and context-aware mobile information services for tourists. Solutions have been proposed for accessing distributed databases and for providing adapted information to users, based on user agent identification techniques and on the adoption of XML as a common language for communication among the building blocks of the system.

10 Mobile Access to Distributed Data Sources 471 References 1. The PALIO Consortium Web page with URL: 2. Network Working Group: Hypertext Transfer Protocol - HTTP/1.1. (WWW page) URL: (June 1999). 3. Arehart, C. et al.: Professional WAP. Wrox press Ltd, Birmingham (2000). 4. ETSI TS : Digital Cellular Telecommunications System: Functional Stage 2 Description of Location Services in GERAN. ETSI, Sophia Antipolis (2001). 5. Naughton, P.: The Java Handbook. McGraw-Hill, Osborne (1996). 6. Maruyama, H., Tamura, K., Uramoto, N.: XML and Java: Developing Web Applications. Addison-Wesley, Boston (1999). 7. Hall, M.: Core Servlets and JavaServer Pages. Sun/Prentice Hall (2000). 8. Williams, K. et al: Professional XML Databases. Wrox Pres Ltd (2000). 9. Simple Object Access Protocol (SOAP) 1.1, web page: Kassem, N.: Designing Enterprise Applications with the Java TM 2 Platform, Enterprise Edition. Addison Wesley (June 2002).