An overview of mobile applications architecture and the associated technologies Sofien BEJI, Nabil El Kadhi RIADI Lab Tunisia, L.E.R.I.A. Lab EPITECH France [email protected], [email protected] Abstract A mobile service covers a large field of technologies ranging from the mobile device such as a PDA or a phone to the enterprise content server through all the wired and wireless networks between them. In this paper, the focus is given to the client side application, the associated technologies and chosen frameworks to built these kind of contents. Some samples of technologies will be presented ranging from the Wireless Web with WML and xHTML contents to fat client based technology mainly the J2ME platform. APIs and protocols for messaging and synchronization are also part of mobile applications. A brief overview of security features is presented at the last section of this paper.

1. Introduction According to the GSM Association [28] the number of mobile subscribers was about 2,165 billions in Nov. 2006 whereas it was about 763,7 millions during the same period in 2002. In 2006, the number of cellular subscriptions rose by 25.8 per cent (World Cellular Information System). The first mobile networks were used for voice communications only, now mobility is playing a sensitive role in the company information system. Either for personal uses like messaging or for enterprise integration like mobile to computer synchronization. The need for mobile applications is growing and a new wave of m-technologies is now emerging. Mobile applications can be based on wireless web access or thik client architecture. Messaging and synchronization are also useful fields.

2. The mobile application anatomy The client side of the mobile application can be divided to: • The device. • The mobile operating system. • The web based applications.

The framework applications. The Messaging services. The Connectivity options. The Synchronization layer. Hardware device features are in general vendor and editor made, that is why we consider that it is beyond the scope of this paper to deal with such features also as the mobile operating system inside. Next sections describes the developer made applications: web and framework based. • • • •

3. Web based applications 3.1 WAP and WML technologies A WAP enabled system consists of: A Web server A WAP gateway A WAP device Servers provide application services to the end user. The interaction between the end user and the server is packaged as a set of standard WML documents. Services are basically composed by static documents stored on server, or dynamically produced ones. Technologies used behind the WAP architecture are both localized on client and server side. For the server side, the same technologies in enterprise back-office are used: HyperText Transfer Protocol (HTTP) [22] Server, Content management system (e.g. Database Management System) and so on. On the client side, the browser can display wireless dedicated Markup Language pages WML [3]. A WML page is called a deck and is composed of one or many cards. The compiled version of a WML file is a WMLc file. WML is a subset of SGML [4] casted with Wireless tags. Like any client side technology, WML has its scripting language: WMLScript [5]. WMLScript is derived from ECMAScript [6] and commonly used for: • Reducing network round-trips and enhancing functionality. • Field validation. • Device extensions. • • • •

Origin servers and WML user agents exchange WML and WMLScript [5]. In particular, a user, wishing to access a service from an origin server, submits a request to the origin server using a WML user agent. The user agent requests the service from the origin server on behalf of the user using some URL scheme operation (e.g., HTTP GET request method.) The origin server replying to the user’s request by sending back a single deck. Presumably this deck is initially in a textual format. On their way back to the client, textual decks are expected to pass through a gateway where they are converted into formats better suited for over-the-air transmission and limited device processing. Once the gateway receives the deck from the origin server, it does all the necessary conversions between the textual and binary formats. A WML encoder in the gateway converts each WML deck into its binary format. The interface between WML pages and the built-in telephony functions of a mobile device is made by the Wireless Telephony Application Interface (WTAI) [29]. There are some WTAI standard functions and some proprietary device ones. The WTAI functions may be invoked by WMLScript [5] or by a href value. The href value can be specified with an address tag element using a dedicated WTAI Unified Resource Identifier (URI) encoding scheme [30]. The “tel” URI scheme specifies a phone number. When the scheme is invoked, the browser asks the user whether to place a voice-call, a video-call (if supported), send an SMS, or add it to the phonebook (e.g. Call me). WTAI includes: call control, network text messaging, phone book interface, indicator control and event processing. Many WML browsers are equipped with a file converter which converts standard web format such as GIF, JPG [8] into a Wireless BitMap (WBmp) [7].

3.2 WAP 2.0 and Wireless Internet WML was suited to build application for devices with small screens. One disadvantage was the requirement for developers to learn a language that was somewhat different from HyperText Markup Language(HTML) [2]. For this reason, some carriers and phone manufacturers inside the WAP forum felt that the wireless mark-up should evolve in the direction of HTML to make developers' lives easier and development more economical. After many years of discussion about convergence with the World Wide Web Consortium (W3C) specifications for the wired web, the WAP Forum introduced the eXtensible HTML Mobile Profile (xHTML MP) and the discontinuation of WML [3].

In WAP 1.0 and WAP 1.2, a WAP [3] proxy was required to handle the protocol interworking between the client and the origin server. WAP 2.0 does not require a WAP proxy and the content is transferred through the HTTP [22], however using a proxy enhances performances and enables WAP push applications. The WAP 2.0 architecture is more suitable for Internet technologies than WAP 1.x, a set of new markup languages have been introduced to fit the mobile profile. xHTML, xHTML Mobile Profile, cHTML are dedicated to markup languages suitable for mobile technologies. The eXtensible HyperText Markup Language is a markup language that has the same expressive possibilities as HTML, but a stricter syntax. xHTML is an application of XML [10] and can be thought as the intersection of HTML and XML. The purpose of xHTML Basic was to define a stripped down version of xHTML for devices with limited capabilities such as mobile phones, televisions, Personal Data Assistants (PDA), vending machines, smart watches directly from the xHTML basic specifications. xHTML Basic was taking as a starting point. Some styling information was added in addition to a handful of style tags belonging to other xHTML 1.0 modules gives the xHTML Mobile Profile. Compact HTML or C-HTML [35] was developed by major Japanese handset manufacturers in 1998 and is an alternative to WML and xHTML Basic. Cascade Style Sheet (CSS) [31] are style sheets that control the presentation of content without sacrificing the device-independence. W3C is also defining CSS Mobile Profile (CSSMP) [32], a minimum set of features which are appropriate for mobile devices. WCSS is defined using a proper subset of CSS based on the W3C’s Mobile Profile. ECMAScript [6] Mobile Profile is designed to provide general scripting capabilities for the mobile applications environment. Specifically, ECMAScript Mobile Profile is used to complement the xHTML markup language. ECMAScript Mobile Profile is designed to overcome the limitations of small devices and to provide programmable functionality that can be used over narrow band communication links and with clients with limited capabilities. On the market place vendors and software editors are delivering a variety of device browsers with different capabilities and web developers are not producing standard contents. The impact of this diversity was a mobile wide range differences for the web content which drivers the W3C to set up the Mobile Web Best Practices [9]. The mobile web practices is a set of basic guidelines that aims to specify a uniform web content for all web content authors. Some headlines of the Mobile Web Practices are: delivery context,

navigation, page layout, page size, content type, image size, user input, tab order. Here is a description of the default delivery context which aims to specify the default format and content of the web pages for the mobile browsers. The default delivery context is defined by a set of assigned values to a set of parameters as shown in table I. TABLE I. DEFAULT VALUE PARAMETERS FOR MOBILE WEB BEST PRACTISES. Parameter Default value Usable 120 pixels minimum Screen Width xHTML – Basic Profile Markup Language Support Character UTF-8 Encoding Image Format JPEG Support GIF89a (non-interlaced, nontransparent, nonanimated) Maximum 20 kilobytes Total Page Weight Colors (A Web safe color is one that has Red/Green/Blue components chosen only from the values 0, 51, 102, 153, 204, and 255.) External CSS Level 1 Style Sheet Support HTTP/1.0 or more recent HTTP The Best Practice statements have been assembled by the Best Practice Working Group from a number of sources such as Opera, Nokia, Little Spring Design, Openwave, iMode and others.

4. Framework applications Mobile framework based applications are applications that run on a platform over the mobile operating system. The purpose of these platforms is to insure the application portability. Portability is especially crucial for phone applications regarding the variety of devices available. One of the most widely used platform is the Java framework especially the Java 2 Micro Edition (J2ME) for the mobile field [11]. In addition to its wide spread, many Java technology applications and developers skillful are available, that’s why dealing with the java mobile won’t require new skills.

4.1 The Java technology overview The Java programming language and the associated technologies are created by Sun Microsystems [26]. Sun offers three commercial Java based platforms: 4.1.1 Java 2 Enterprise Edition [27] Contains the Java Base Platform along with numerous enterprise APIs and tools. These include Enterprise JavaBeans [27], Java Server Pages [27], the Java Message Service [27], Servlets, XML [27], database connectivity via Java DataBase Connectivity (JDBC) [27], CORBA functionality via JavaIDL [27], and the Java Native Directory Interface (JNDI) [27]. 4.1.2 Java 2 Micro Edition (J2ME) It’s one of the major player in the mobile application software world and will be more detailed in the next section. According to the global context of our case study which focus on the mobile applications in the telephony field, J2ME is one of the widely used platforms. Because of application portability, J2ME was adopted by the world's leading cellular phone manufacturers (e.g. Nokia, SonyEricsson, Siemens, Motorola and others). Java Mobile Edition (ME) is a collection of technologies and specifications that developers can choose from and combine to construct a complete Java runtime environment that closely fits the requirements of a particular range of devices and target markets. Each combination is optimized for the memory, processing power, and I/O capabilities of a related category of devices. Mobile devices come with different forms, features and functionality, but often use similar processors and have similar amounts of memory. Therefore configurations were created, defining groups of products based on the available processor power and memory of each device. A configuration outlines the following: • The Java programming language features supported. • The Java Virtual Machine features supported. • The basic Java libraries and Application Programming Interfaces (APIs) supported. There are two standard configurations for the J2ME at this time: • Connected Device Configuration (CDC) [11]. • Connected Limited Device Configuration (CLDC) [11]. The CDC is targeted toward powerful devices like Internet TVs and car navigation systems. The CLDC is targeted toward less powerful devices like mobile

phones and PDAs. The vast majority of Java enabled mobile devices available to consumers today use CLDC. A profile defines a set of APIs which reside on top of a configuration and offers access to device specific capabilities. The Mobile Information Device Profile (MIDP) [11] is a profile to be used with the CLDC and provides a set of APIs for use by mobile devices. These APIs include classes for user interface, persistent storage and networking. CLDC is designed to bring the many advantages of the Java platform to network-connected devices that have limited processing power, memory, and graphical capability, such as cellular phones. CLDC can also be deployed in home appliances, TV set-top boxes, and point-of-sale terminals. Target devices typically have the following capabilities: A 16-bit or 32-bit processor with a clock speed of 16MHz or higher. At least 160 KB of non-volatile memory allocated for the CLDC libraries and virtual machine. At least 192 KB of total memory available for the Java platform. A low power consumption, often operating on battery power. A connectivity feature to some kind of network, often with a wireless, intermittent connection and limited bandwidth. On the other hand, the CDC configuration was designed to bring the many advantages of the Java platform to a broad range of network-connected consumer and embedded devices, including smart communicators, high-end PDAs, and set-top boxes. Devices that support CDC typically include a 32-bit microprocessor/controller and make about 2 MB of RAM and 2.5 MB of ROM available to the Java application environment. The Mobile Information Device Profile (MIDP) [11] is a key element of the J2ME [12]. When combined with the Connected Limited Device Configuration (CLDC) [11], MIDP provides a standard Java runtime environment for today's most popular mobile information devices, such as cell phones. The MIDP specification was defined through the Java Community [18] Process by an expert group of more than 50 companies, including leading device manufacturers, wireless carriers, and vendors of mobile software. CLDC and MIDP provide the core application functionality required by mobile applications [14], in the form of a standardized Java runtime environment and a rich set of Java APIs. Developers using MIDP can write applications and deploy them to mobile information devices. MIDP has been adopted for

millions of phones and PDAs, and is supported by leading Integrated Development Environments (IDEs).

5. The Messaging services The messaging service is one of the most used applications in the mobile world. The total number of messages sent during 2005 was about 30 billions [33]. Even though, the major use of messaging is in personto-person communication, it is also deployed in corporate and business applications. Messaging applications are deployed is technical notification concerning server or service status, in mobile commerce, telecommunication services, voting, vehicle positioning and so on. Sending an SMS can be implemented in different ways summarized in table II. TABLE II. SHORT MESSAGE SERVICE SENDER/RECEIVER CONFIGURATION Sender Receiver Use case A person sending Mobile Base a message device Transceiver through the air Station interface. Applicati An SMS An application on Gateway that sends SMS to different mobile networks through wired connection with an SMS gateway. Applicati An SMS Center An application on that needs an important data flow. Depending on the network type, GSM [28] (Global System For Mobile communications), GPRS [28] (General Packet Radio Service), the messaging application can be either Short message service (SMS) or Multimedia Message Service (MMS).

5.1 Short Message Service: SMS SMS is a text messaging service available on the GSM network. From the sender to the destination, the text message switches from a set of network nodes. The main components in the network messaging architecture can be divided in three parts: The GSM part: composed of the Base Transceiver Station (BTS) [16] and the Base Station Controller (BSC) [16] responsible of Over-The-Air transmission from/to the mobile device.

The Signaling System number 7(SS7): it’s a set of equipments in the GSM network responsible of storing, switching, checking subscriber profile. The SS7 includes the Short Message Service Centre (SMSC) [21]. The third part is the interface with the others networks and services such as fixed telephony, Internet and so on.

5.2 Multimedia Message Service: MMS MMS is a multimedia messaging service that gives the capability within a WAP Client to receive and process multimedia message types such as those providing for sound and video (JPEG, GIF, MP3, MPEG-4, etc.). In addition to the network transmission and switching elements, the MMS framework [15] contains components that manages multimedia contents: MMS Proxy-Relay – This is the system element that the MMS Client interacts with. It provides access to the components that provide message storage services, and it is responsible for messaging activities with other available messaging systems. Some implementations may combine this component with the MMS Server. MMS Server – This system element provides storage services for Multimedia messages. Some implementations may combine this component with the MMS Proxy -Relay. Interfaces: The MMS Proxy Relay is connected to email servers to allow interaction between MMS and email.

5.3 The WAP push Push is the delivery of content to the mobile device without previous user interaction. A Push operation is accomplished by allowing a Push Initiator (PI) [15] to transmit Push content and delivery instructions to a Push Proxy Gateway (PPG) [15], which then delivers the Push content to the WAP client. The PI is typically an application that runs on an ordinary Web server. It communicates with the PPG [15] using the Push Access Protocol (PAP) [15] over HTTP [22]. The PPG [15] uses the Push Over-The-Air (OTA) Protocol to deliver the Push content to the client.

6. Connectivity services Since we are focusing on connectivity services, in this paragraph, we will deal with Bluetooth [17] and Infrared [19] as means of connectivity in a mobile environment application. Without going in deeper with the lower layers of the architecture, upper layers and

associated services will be detailed in relation to the context of mobile applications.

6.1 Bluetooth Bluetooth [17] wireless technology is a short-range communications system that intend to replace the cable(s) connecting portable and/or fixed electronic devices. The Bluetooth core system consists of a radio frequency (RF) transceiver, base band, and protocol stack. The system offers services that enable devices connection and the variety exchange of data classes between these devices. Many phone Software Development Kit (SDK) make it possible to enable Bluetooth service calling through Application Programming Interface (API). One of the popular Bluetooth APIs is The Java APIs for the Bluetooth Wireless Technology (JABWT) standardized by the Java Community Process as the JSR-82 [18]. To setup a Bluetooth application using the JSR-82, the following steps are required [13] : stack initialization, device management, device discovery, service discovery and communication.

6.2 Infrared The Infrared Data Association (IrDA) [19] defines specifications for infrared wireless communication. One of the most used is the OBject EXchange protocol [19], OBEX. OBEX also termed as IrOBEX is a communications protocol that facilitates the exchange of binary objects between devices such as business cards, data and even applications. It is maintained by the Infrared Data Association but has also been adopted by the Bluetooth Special Interest Group. OBEX is similar in design and function to HTTP [22] in that a client uses a reliable transport to connect to a server and may then request or provide objects. More details about OBEX can be found in [19].

7. Synchronization The exponential growth of mobile devices and the lack of a common data synchronization protocol emerges several “Islands” of data with conflicting communications ways. The continued expansion of data on devices and applications is accelerating the need for a data synchronization language. SyncML is a Data Synchronization protocol based on the XML technology [10] that supports a variety of transport protocols (WSP/WAP, HTTP, OBEX). A syncML platforms is a typical client/server architecture. There are numerous real-world use cases

for SyncML ranging from backup and restore data to automatic device configuration. More details about SyncML can be found in [20].

8. Comments Mobile applications are the result of many technologies integration. The front component is composed of the mobile device, and the back office is the enterprise services mainly hosted on servers. The delivery of data to the device is held by a wireless network or a telecommunication provider in the context of mobile telephony. Each part of this architecture has its own technologies. Devices are manufacturers’ products, software and developing tools are the result of information processing editors and networks are set up by telecommunication company. Nowadays, all these technologies are merging to offer one service that can be accessed through a mobile device, whatever is the server or the network behind. Such an integration is not so fluent due to many reasons. From the device industry, there is a big diversity of devices and companies are adding several functionalities to their products to make the best market offer. For data transfer and networks, standards are not the same from one country to an other. Mobile Internet in Japan and France are not the same due to some proprietary protocols. As a consequence of such a diversity, a need of standardization and portability are felt inside the developers community. The main guidelines available for making and offering standard services in the mobile world are available through these three organizations: Open Mobile Alliance (OMA) [23], World Wide Web Consortium (W3C) [24] and the 3rd Generation Partnership Project (3GPP) [25]. Mainly the mission of the W3C is to provide the core languages and the conceptual architecture, the OMA is responsible of the use of the W3C technologies and the use of the appropriate bearer and COmpression and DECcompression (codecs). Finally 3GPP provides the appropriate codecs and communication optimization.

9. Mobile Security As detailed in the previous sections, a set of techniques, protocols and hardware components are implicated in mobile applications. Nowadays, a set of sensible data are transferred through mobile applications. Such data need of course a high level of security and necessitate a set of security services. To be able to include such features, we have to consider both client and server sides. Server side

vulnerabilities are same as in any classical/standard distributed net application, attacks and vulnerabilities such as injection, denial of service, unauthorized access and so on, remains the same. Particularly we have to focus on the client side which holds personal information such as contacts, SMS, appointments, tasks and can also be used as payment terminal for commercial transactions. For web applications and by similarity to regular browser applications, mobile ones are vulnerable to script injection, cookies theft, Ajax attack [34] which can be conducted from a mobile device. Dealing with security services in a mobile phone context includes additional vulnerabilities because of the use of communication protocols. For example, without authentication setup, Bluetooth connection can be established without users’ authorization. Taking in account all those features, we can sort the mobile vulnerabilities in domain classes: web, framework, messaging and synchronization. Defining and implementing the most appropriate security is in fact a challenge needing to consider vulnerability categories, languages, development tools and also hardware constraints. Of course some existing techniques can be applied but they should be personalized and “rebuilt” to feet with mobile phone applications. That’s why we believe that having an appropriate designing method is of a big interest in assigning security parameters and features to different participants in a classical mobile phone application.

10. Conclusion Mobile and wireless applications can be presented in more than a way, they can be discussed from a network view or also from a hardware device one. Here, we have presented an overview of mobile applications according to the software layer. The focus was given to the application part which is developer made. Two kinds of applications have been released: browsing content and host applications. Browsing content mobile applications are merging to the standard Internet Technologies to make it possible the make-one use many model. Host applications are mainly running over the J2ME framework which is dedicated to mobile devices with limited resources (Processing, memory and energy). Unlike in standard application development tools, SDK and IDE are not limited to software editors like Microsoft, Borland, Macromedia and the others but there is also a major part of SDK that are issued by telephony manufactures. Because of this diversity, there is a significant lack of portability and common used standards.

About connectivity, mobile devices can be connected in a one-to-one or one-to-many schema; a typical one-to-one connection can be the devices’ synchronization or connection in a PAN through irDA or Bluetooth. One-to-many connections can be either in a classical way such as IP connection or with dedicated mobile forms like SMS or MMS. Developer made applications communicate with a couple of environment resources: the enterprise resource side and the mobile device resource and this is done through a set of software layers and protocols. These interfaces represent an important source of risk and are worthy to be taken in account earlier during the application design process. Hence, the need of a methodology taking an account security aspects at all life cycle stages is crucial to mobile applications developers.

References [1] P, King and T, Hyland, “Handheld Device Markup Language Specification”, The world wide web consortium 1997. Available: http://www.w3.org/TR/NOTE-SubmissionHDML-spec.html. [2] HyperText Markup Language, The world wide web consortium. Available: http://www.w3.org/MarkUp/ [3] Wireless Markup Language Specification, The Wap forum, 1998. Available: http://www.wapforum.org/what/technical/wml-30-apr-98.pdf [4] F. Goldfarb, The SGML Handbook, 1990. [5] WMLScript Language Specification, The Wap forum, 1998. Available: http://www.wapforum.org/what/technical/wmlss-30-apr98.pdf [6] ECMAScript Language Specification, ECMA International, December 1999. Available: http://www.ecma-international.org/publications/files/ECMAST/Ecma-262.pdf [7] Wireless Application Environment Specification, The WAP forum, Nov 2001. [8] Graphics on the web, The world wide web consortium. Available: http://www.w3.org/Graphics/ [9] Mobile Web Best Practices 1.0, The world wide web consortium, November 2006. Available: http://www.w3.org/TR/mobile-bp [10] Extensible Markup Language (XML), The world wide web consortium. Available: http://www.w3.org/XML/ [11] M. J. Yuan, “Entreprise J2ME, DEVELOPING MOBILE JAVA APPLICATIONS“, Ed. Upper Saddle River: Prentice Hall PTR, 2006, pp. 20-25. [12] C. Cavaness, B. Keeton, J. Friesen, J. Weber. Using Java 2 Standard Edition. Que, 2000. [13] A. N. Klingsheim, “J2ME Bluetooth Programming (Master Science thesis)” , Department of Informatics, University of Bergen, June 2004.

[14] P. Lamsal, “J2ME Architecture & Related Java Embedded Technologies (Degree in Computer Science) “,Dublin Institute of Technology, 2004. [15] Wap push technology overview, Openwave, May 2002. Available: http://developer.openwave.com/docs/wappush_tech_overvie w.pdf [16] A. Tanenbaum, Reseaux, 3rd edition, Prentice Hall, 1997, pp. 271-273. [17] The Official Bluetooth Membership site, Available: http://www.bluetooth.org [18] The Java Community Process. Available: http://www.jcp.org [19] Infrared Data Association. Available: http://www.irda.org [20] Data Synchronization Specification, Open mobile Alliance, May-2001. [21] W Enck, P Traynor, P McDaniel, T La Porta, “Exploiting Open Functionality in SMS Capable Cellular Networks”, Proceedings of the 12th ACM conference on Computer and communications security, USA, 2005. [22] Hypertext Transfer Protocol, The world wide web consortium. [23] Open Mobile Alliance web site. http://www.openmobilealliance.org [24] World Wide Web Consortium. http://www.w3c.org [25] 3rd Generation Partnership Project. http://www.3gpp.org [26] Sun Microsystems web site. http://www.sun.com [27] S. Allamaraju, C. Beust, M. Wilcox, “Professional Java Server Programming J2EE”, 1.3. Wrox Press, 2001. [28] The GSM Association web site. http://www.gsm.org [29] Wireless Telephony Application Interface Specification. WAP Forum. [30] Universal Resource Identifiers, The world wide web consortium. Available : http://www.w3.org/Addressing/URL/URI_Overview.html [31] The Cascade Style Sheet, level 2 – CSS2 specification, The world wide web consortium. Available : http://www.w3.org/TR/REC-CSS2/ [32] CSS Mobile Profile 2.0, The world wide web consortium. Available : http://www.w3.org/TR/css-mobile/ [33] The mobile Data Association. http://www.themda.org [34] B. Offman, “Ajax Securiy Dangers”, SPI Labs. [35] T. Kamada, “Compact HTML for Small Information Appliances”. World Wide Web Consortium discussion note.