Mobile Communication Middleware

Mobile Communication Middleware Lekometsa Mokhesi lmokhesi@cs.uct.ac.za Supervised by: Prof. Ken MacGregor Department of Computer Science University of Cape Town October 2007

Abstract This report presents a mobile middleware toolkit, which is a framework that enables application developers to develop ubiquitous, protocol and communication technology independent applications. Currently, communication between mobile devices and other mobile devices and servers requires the knowledge of the type of communication and the appropriate communication protocol. This has unfortunate results in that an application which uses one of the SMS protocols cannot be run using an Always on protocol such as used by GPRS without being changed. Presented in this report is a Mobile Middleware toolkit which provides an application developer with a series of Application Programming Interface which can be used irrespective of the underlying protocol to be used. Thus, the reconfiguration for different network protocol takes place in reconfiguring the Middleware and the application remains unchanged. Keywords: Middleware, Mobile Computing, Networks, Wireless, Interoperability 2

3

Table of contents 1. Introduction...1 1.1 Motivation....1 1.2 Project Outcomes.....2 2. Background and Related Concepts.....3 2.1. Message Oriented Middleware........3 2.1.1. Message queuing.. 3 2.1.2. Publish/Subscribe.....4 2.2. Java Messaging Service.....4 2.2.1. JMS overview.... 4 2.2.2. JMS API Architecture....4 2.2.3. Message Queuing........5 2.2.4. Publish-Subscribe......5 2.3. JMS API Programming Model... 6 2.3.1. JMS API Building Blocks.........6 2.3.2. JMS Administered Objects.7 2.4. Wireless Networks......10 2.4.1. Wireless LANs...10 2.4.2. Mobile Cellular Networks..10 2.4.3. Personal Area Networks.....12 2.5. Java 2 Micro Edition...8 2.4.1. Configurations......9 2.4.2. Profiles.....9 2.4.3. Optional Packages.....10 2.4.4. CVM and KVM......10 2.6. J2ME and JMS....16 3. Design.......16 3.1. Middleware Overview...16 3.2. Middleware Requirements....16 3.3. Design Decisions.......16 3.3.1. Choosing Application Layer Protocols.. 16 3.3.2. Choosing a JMS platform...16 3.4. Asynchronous Messaging Platform.. 17 3.5. Mobile devices as JMS clients.. 17 3.7. Jtom (Java to Mobile)....18 3.8. Jtom Technology......18 3.9. Overall toolkit design 19 3.10. Communication in disruptive environments...19 4

4. Implementation.20 4.1. Overview...20 4.2. Jtom v2.1.3 20 4.3. JBoss Application Server 4.0.0.20 4.4. Full API 20 5. Project Evaluation 21 6. Conclusion 21 7. Future Work. 21 7.1. More Protocols..21 7.2. Autonomic Communication.21 8 References.22 5

List of figures Figure 1: Basic architecture of JMS System..4 Figure 2: Point to Point Messaging...5 Figure 3: Publish/Subscribe Messaging....6 Figure 4: JMS API Programming Model.. 7 Figure 5: Java 2 Micro Edition (J2ME).8 Figure 6: ibus/mobile Architecture.11 Figure 7: Architectural overview of jtom 18 Figure 8: Class diagram for the JMS framework in toolkit......20 Figure 9: Components of the JMS-SIP System....21 Figure 10: JMSIPO welcome screen....23 Figure 11: JMSIPO JMS settings.24 Figure 12: JMSIPO chat sending and receiving...25 6

1. Introduction Computing is becoming increasingly mobile and ubiquitous. We are approaching a point whereby there is an increased demand for a number of applications and services for mobile users [1]. Mobility has now become the central aspect of everyday life with mobile users expecting to be always-best-connected in whatever location they are and in whatever task they are performing [2]. This creates a serious need for the development of ubiquitous applications. In the ubiquitous paradigm, the user can have access to services or run their applications anywhere, at any time, and with any terminal device he or she desires to use. This notion of anywhere/anytime access behaviour of such ubiquitous applications necessitates the availability of multitechnology systems and software supporting flexible communication 1.1. Problem Statement Ubiquitous applications in multi-technology systems introduce great challenges to application developers. This is because; communication-technology based applications are currently inflexible in that they are built specific to a communication technology and protocol to be used. Consequently, if the application has to run on an alternative protocol, it has to be changed, or at worse redesigned. For instance, because of perpetual compromise of security systems in financial institutions i.e. banks, strong security measures are constantly being re-evaluated and implemented to counteract this adamant security attacks. One of the measures is the use of one-time passwords in banks for the use in electronic banking. This password is often sent from the bank s backend application to the customer s mobile phone via SMS and can be used only for that session. SMS utilizes asynchronous communication and has a delivery validity of 48 hours. This means, in high GSM network usage, the customer might not receive the password immediately, but might be forced to wait to up to 48 hours to receive the password or in worst case, not receive it at all because it expired. This is undesirable, especially in electronic transactions, hence; demands for a new kind of approach that allows alternative methods of messaging to be used. 1.2. Proposed Solution The ability for a mobile application to utilize any application layer protocol that satisfies its requirement becomes increasingly important. As a result, application developers overload can be considerably reduced by means of middleware, which provides a level of abstraction for the application layer and hides the common functionalities and complexity of the underlying infrastructure behind generic and 7

simple interfaces [1], together with a toolkit that provides application programming interfaces which can be used irrespective of the underlying communication protocol to be used. 1.3. Project Outcomes The project developed a middleware toolkit which is built on a synergy of two representative application layer protocols. This toolkit is to provide application developers a series of interfaces which can be used irrespective of the underlying protocol to be used. 1.4. Project Evaluation To test the effectiveness of the toolkit, a test application will be developed using the toolkit. This test application will be developed for one protocol and observing how easy it is to port it to another protocol. 1.5. Division of Work The middleware functionality caters for two types of applications: Synchronous/Real time and asynchronous/loosely coupled messaging applications. As such both were divided into separate sections and assigned accordingly to the two member of the Mobile Middleware team. For synchronous applications, SIP (Session Initiated Protocol) was investigated, and JMS (Java Messaging Service) for loosely coupled applications. 1.6. Report Outline The report is divided as follows: section 2 gives the background and related concepts, section 3 gives the middleware design, section 4 will follow with the implementation, section 5 with project evaluation, section 6 gives the conclusion and section 7 will conclude with the future work. 8

2. Background and Related concepts 2.1. Middleware Middleware refers to software that mediates between an applications program and other entities e.g. the network, operating system or other applications programs. It manages the interaction between disparate applications across the heterogeneous computing platforms. Middleware, essentially, is a tool to make a distributed system deployment easier. One of the advantages of middleware is it provides location transparency, which means that components can be migrated between computers without any changes required to other components. There are different types of middleware including transactional middleware, message oriented middleware, object middleware and procedural middleware. This report will deal exclusively with message oriented middleware particularly in mobile computing paradigm. Before continuing with MoM (Message oriented middleware), a brief description of the other types of middleware is given. 2.1.1. Transactional Middleware Transactional middleware supports the development of systems involving transactions running across multiple hosts. A transaction ensures that the operations required will occur either on all hosts in the system, or no hosts in the system. Transactional middleware uses the two-phase commit (2PC) protocol to implement these transactions. The Distributed Transaction Processing (DTP) protocol defines a programmatic interface for 2PC, which is used by most relational database management systems. This allows servers and database management systems to be easily integrated. Transactional middleware supports both synchronous and asynchronous communication between hosts [23]. 2.1.2. Procedural Middleware Procedural middleware supports remote procedure calls (RPC) as its communication model. In this model, communications can be made by using primitives similar to local procedure calls. Specifically, a server exports several procedures for communication and a client invokes these procedures. Then, procedural middleware marshals an RPC into several messages and vice versa [23]. 2.1.3. Object Middleware 9

Object middleware is an evolution from procedural middleware. It adds to middleware the concept of object-oriented programming such as object identification through references and inheritance. This type of middleware enables independent development and distribution of each component since each interaction of components is defined by interfaces [23]. 2.2. Message Oriented Middleware Message Oriented Middleware MoM is a specific class of middleware that supports the exchange of general-purpose messages in a distributed, also referred to as uncoupled or loosely coupled application environment. MoM operates on the principles of message passing and/or message queuing supporting both synchronous and asynchronous interactions between distributed computing processes. MoM system ensures message delivery by using reliable queues and by providing the directory, security, and administrative services required to support messaging [19]. The loosely coupled architecture of MoM provides several advantages over traditional client/server systems. These advantages include: High degree of anonymity between message producer and consumer in a system, as for a consumer it does not matter which producer sent a given message. This in turn makes messaging systems very flexible and highly scalable, as entire subsystems can be replaced without the need to replace other parts of the system [3]. Persistent storage to back up the message transfer medium. This means that the sender and receiver do not need to connect to the network at the same time (asynchronous delivery). This becomes particularly useful when dealing with intermittent connections, such as those in mobile communications Latency hiding: In client/server systems, a client is typically suspended while its request is transmitted to the server, processed by the server, and a reply sent back to the client. With MoM, however, the request and reply phases are fully decoupled. Once a request message from the client is transmitted, the client can be freed and continue with other tasks. There are two common messaging paradigms supported by current MoM systems: Message queuing and Publish/Subscribe. 2.2.1. Message queuing 10

The message queuing paradigm is a one-to-one model, where a message sent by a message producer gets delivered to one of the interested message consumers. The main difference between this and the publish/subscribe paradigm is that only one of the interested message consumers will receive any one message. This one-to-one message distribution is useful in applications where there needs to be a one-to-one communication, but where the identity of the receiving client is less important [3]. An example of a messaging product using the message queuing model is that of IBM s MQSeries [4]. 2.2.2. Publish/Subscribe Also referred to as topic-based messaging is an asynchronous messaging paradigm whereby the providers of information (publishers) are decoupled from the consumers of that information (subscribers) using a broker [5].Subscribers express interest in one or more classes, and only receive messages that are of interest, without knowledge of what (if any) publishers there are [6]. An example of a messaging product using the publish/subscribe model is that of Tibco Inc. [7]. JMS is the MoM standard for Java. 2.3. Java Messaging Service 2.3.1. JMS overview The Java Message Service (JMS) is a specification developed by Sun Microsystems that provides a common way for Java applications to access each other via messageoriented middleware (MoM). The Java Message Service (JMS) was designed to make it easy to develop business applications that asynchronously send and receive business data and events. It defines a common enterprise messaging API that is designed to be easily and efficiently supported by a wide range of enterprise messaging products. 2.3.2. JMS API Architecture JMS Producer JMS Sever JMS Consumer Point-to-Point Queues Message Producer Messages Messages Message Consumer Publish- Subscribe Topics Fig 1: Basic architecture of JMS System 11

The JMS system is composed of the following parts: JMS provider (JMS Server) is a messaging system that implements the JMS interfaces and provides the administrative and control features. JMS clients are the programs or components that produce or consume messages. Messages are the objects that communicate information between JMS clients. Administered objects are preconfigured JMS objects created by an administrator for the use of clients. The two kinds of JMS administered objects are destinations and connection factories. 2.3.3. Message Queuing Message queuing also referred to as point-to-point (PTP) built around the concept of message queues, senders, and receivers. Each message is addressed to a specific queue, and receiving clients extract messages from the queue(s) established to hold their messages. Queues retain all messages sent to them until the messages are consumed or until the messages expire [8]. Msg Msg Client 1 Client 2 Queue Consumes Sends Acknowledges Fig 2: Point to Point Messaging 2.3.4. Publish-Subscribe [8] In this model clients address messages to some node in the content hierarchy. Publishers and subscribers are generally anonymous and may dynamically publish or subscribe to the content hierarchy. The system takes care of distributing the messages arriving from a node s multiple publishers to its multiple subscribers. 12

The destination in the publish/subscribe domain is called a topic. The simple publish/subscribe example in the diagram below contains a single topic and two clients. One client subscribes to the topic and the other publishes messages to the topic. The topic takes care of distributing messages from the publisher to the subscriber. Assume the topic and both clients already exist and are connected as illustrated. Subscribes Client 2 Client 1 Msg Publishes Topic Delivers Msg Subscribes Client 3 Delivers Msg Fig 3: Publish/Subscribe Messaging 2.4. JMS API Programming Model 2.4.1. JMS API Building Blocks The basic building blocks of a JMS application consist of: Administered objects: connection factories and destinations. Connections Message producers Message consumers Messages Fig 3 shows how all these objects fit together in a JMS client application. 13

Connection Factory Creates Connection Creates Message Producer Creates Session Creates Message Consumer Sends to Creates Receives from Message Destination Destination Fig 4: JMS API Programming Model 2.4.2. JMS Administered Objects Two parts of a JMS application, destinations and connection factories, are best maintained administratively rather than programmatically. This is because the way in which these two entities are implemented can vary greatly from JMS provider to JMS provider. JMS clients access these objects through interfaces that are portable, so a client application can run with little or no change on more than one implementation of the JMS API. The other objects are handled programmatically. A connection factory is the object a client uses to create a connection to a provider. A connection factory encapsulates a set of connection configuration parameters that has been defined by an administrator. A destination is the object a client uses to specify the target of messages it produces and the source of messages it consumes. In the PTP messaging domain, destinations are called queues. In the pub/sub messaging domain, destinations are called topics. A JMS application can use multiple queues or topics (or both). 14

A connection encapsulates a virtual connection with a JMS provider. A connection could represent an open TCP/IP socket between a client and a provider service daemon. You use a connection to create one or more sessions. A session is a single-threaded context for producing and consuming messages. A session can be used to create the message producers, message consumers, messages, queue browsers, temporary queues and topics. A message is the entity sent between producers and consumers and can be an arbitrary Java object. A message producer is an object that is created by a session and used for sending messages to a destination. If the destination is a queue, the producer is called a sender; if the destination is a topic, the producer is called a publisher. A message consumer is an object that is created by a session and used for receiving messages sent to a destination. If the destination is a queue, the consumer is called a receiver; if the destination is a topic, the consumer is called a subscriber. A message listener is a type of message consumer used to consume messages asynchronously. A message listener will be set by a JMS client on a destination, and if a message is due to the client, the message listener s onmessage() method will be called. In the onmessage() method, the appropriate action upon message receipt needs to be defined. 2.5. Wireless Networks It is imperative in the context of mobile applications to briefly discuss wireless networks. A bearer is defined as that which carries messages or is sent on errands. In the context of wireless bearers, it means anything that can transport information from one device to the other of which one or both of these devices are mobile. Wireless bearers can be characterised as: Wireless Area Networks, Mobile Cellular Networks and Personal area networks. 2.5.1. Wireless LANs A wireless LAN or sometimes called a Local Area Wireless Network is one in which a use can connect to the local area network through a wireless radio connection. 2.5.2. Mobile Cellular Networks A Mobile cellular network can be characterised as xg, where x refers to the number corresponding to the level and G is the generation. Mobile Cellular Networks can also be classified as either connection oriented or packet switched. In connection oriented 15

networks, the sender of the information establishes a connection with the service provider before any data can be send. In packet switched networks, a device can send and receive packets without the need to connect to the service provider. The bearers in the mobile cellular networks are: 1G - First generation. 1G refers to the initial category of mobile wireless networks that used only analog technology and were developed primarily for voice services. 2G - Second generation. 2G refers generically to a category of mobile wireless networks and services that use digital technology. 2G wireless networks introduce support for data services. These networks have rather low speed. Examples include: GSM - GSM (Global System for Mobile communication) offers data transmission speeds of up to 9,600 bps. AMPS/DAMPS - sometimes spelled DAMPS, is a digital version of Advanced Mobile Phone Service. HSCSD - High-Speed Circuit-Switched Data (HSCSD) is circuit-switched wireless data transmission for mobile users at data rates up to 38.4 kbps, four times faster than the standard data rates of GSM. 2.5 G - Second generation plus. 2.5G refers generically to a category of mobile wireless networks that have a packet data overlay built on top of the circuit-switched voice network to support higher data rates than 2G mobile networks (2G networks support data in a circuit-switched model). Examples include: GPRS - General Packet Radio Services (GPRS) is a packet-based wireless communication service that promises data rates from 56 up to 114 Kbps and continuous connection to the Internet for mobile phone and computer users. GPRS is based on Global System for Mobile (GSM) communication and complements existing services such circuit-switched cellular phone connections and the Short Message Service (SMS). EDGE - Enhanced Data Rates for Global Evolution, a faster version of the GSM wireless service, is designed to deliver data at rates up to 384 kbps and enables the delivery of multimedia and other broadband applications to mobile phone and computer users. EDGE is a packet-oriented bearer delivering much higher speed than GPRS, anticipating the speed advances of UMTS. 3G - Third generation. 3G refers generically to a category of next-generation mobile networks which operate at a higher frequency bandwidth (typically 2.1 GHz and higher) and have a larger channel bandwidth. This enables 3G networks to support very high data rates, up to 2 Mbps. With the higher bandwidth, more data and 16

multimedia services are possible. 3G refers to the radio network and RF technology, and does not affect the switching core. 2.5.3. Personal Area Networks A personal area network (PAN) is the interconnection of information technology devices within the range of an individual person, typically within a range of 10 meters. Personal area network bearers include: Bluetooth - Bluetooth is an industrial specification for wireless personal area networks (PANs). Bluetooth provides a way to connect and exchange information between devices such as mobile phones, laptops, PCs, printers, digital cameras, and video game consoles over a secure, globally unlicensed short-range radio frequency [10]. Infrared - IR wireless is the use of wireless technology in devices or systems that convey data through infrared (IR) radiation. Infrared is electromagnetic energy at a wavelength or wavelengths somewhat longer than those of red light [11]. 2.6. J2ME (Java 2 Micro Edition) Java ME platform is a collection of technologies and specifications that can be combined to construct a complete Java runtime environment specifically to fit the requirements of the small device market [9]. Essentially, J2ME was introduced to provide programmers with a programming language with the benefits of Java, such as portability and familiarity, which would run on a large number of mobile devices. In order to achieve this, J2ME is not simply a cut down version of Java, but is designed to be modular, so as to best fit onto the full spectrum of resource availability [3]. There are three concepts that undergird J2ME technology: Configurations, Profiles and Optional packages. 17

Java 2 Enterpris e Edition (J2EE) Java 2 Standard Edition (J2SE) CDC MIDP CLDC Profile Level Configurati on Level Java Virtual Machine KVM Fig 5 Java 2 Micro Edition (J2ME) 2.6.1. Configurations Configuration is a complete java runtime comprising of three components: A java virtual machine to execute java bytecode. Native code to interface to the underlying system. A set of core java runtime classes. Different configurations define different requirements in order for device to use them. Although does not provide a complete java environment, the set of core classes is small and hence should be enhanced with additional classes provided by J2ME profiles. J2ME defines tow configurations: The Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC). CLDC defines a base set of application interfaces and virtual machines for resource constrained devices like mobile phones, pagers and personal digital assistants. These devices are characterised by small amounts of memory and/or slow processors. The CDC on the other hand includes a full java virtual machine and much larger set of core classes. 2.6.2. Profiles A profile adds domain-specific classes to the configuration to complement the missing functionalities. More specifically, it defines classes for building interactive applications. Several profiles have been defined up to age. Mobile Information Device Profile (MIDP) which is the main focus, a CLDC-based profile for running 18

applications on cell phones and pagers with small screens, wireless HTTP connectivity and limited memory. Other profiles include: Personal Digital Assistant Profile (PDAP), Foundation Profile (PF) and the Personal Basis Profile. 2.6.3. Optional Packages An optional package is a set of Application Programming Interfaces in addition to common functionalities that are not really to any specific classification, configuration or profile. For example, Bluetooth support is defined as an optional package. It cannot be part of a profile because none of the behaviours of a profile can be optional. If a device supports a profile, it must support it in its entirety. This would however limit the profile only to Bluetooth enabled devices. 2.6.4. CVM and KVM The other important concepts in J2ME are: KVM and CVM. These are the names of the java virtual machines for the CLDC (KVM) and the CDC (CVM). These were written specifically to work in the resource constrained environments of handheld or embedded devices. 2.7. J2ME and JMS JMS provides an acceptable method for communicating in the wireless domain, where unreliable connectivity is expected. As discussed by [12], JMS describes the interface to the messaging middleware; the implementation of the middleware is not specified. Also, integration of wireless mobile devices (such as phones, pagers, personal digital assistants or laptops) is not specified. Existing messaging middleware allows one to access the middleware from non-mobile devices (personal computers or server computers) over wired networks. These networks usually run communication protocols such as TCP/IP, HTTP or SSL. Supporting wireless mobile devices requires the vendor of the middleware to implement a message transmission protocol atop a wireless transport protocol (such as WAP, GSM, SMS, GPRS, or UMTS) and to integrate this message transmission protocol into the middleware. This leads to limited applicability for the following reasons: State of the art JMS messaging middleware requires more computer memory than is available on mobile devices. Mobile devices, which are often disconnected from a corporate network, are unsupported in state of the art JMS messaging middleware products. 19

Wireless protocols such as WAP, SMS, GPRS or UMTS are not supported by state of the art JMS messaging middleware products, unless the TCP/IP, HTTP or SSL protocol is used atop those wireless protocols. Though state of the art JMS messaging middleware products support communication protocols such as TCP/IP, HTTP, and SSL, they do not support any other communication protocols. Further, there are considerable performance impacts, as TCP, HTTP or SSL were designed for wired networks and thus do not perform well on wireless networks [12]. Because of the challenges outlined above, the implementation of JMS on mobile devices has not received much attention from the research community. Most of the solutions are either geared towards J2ME applications or JMS desktop applications but not the synergy of both. An example is Nirvana [13] which is a message oriented middleware solution that supports JMS. Nirvana comes with two products: Nirvana Enterprise and Nirvana JMS. Nirvana JMS provides only JMS functionality, while Nirvana Enterprise includes other MoM functionalities together with JMS. Nirvana provides a JMS implementation that is built on top of the Nirvana API. Nirvana's JMS implementation provides topic and queue functionality as per the JMS 1.1 specification [13]. Although, Nirvana defines a J2ME API that allows transparent access to content across Nirvana servers, this does not include JMS implementation on J2ME, hence can not be used as a JMS client. Other wireless MoM solutions in the market do not provide full implementation of the JMS on J2ME but rather build their J2ME messaging functionality on the Wireless Messaging API [14]. Example of such a middleware solution is jtom (Java to Mobile) [15]. jtom is a message-oriented middleware for interactive communication with application servers and legacy systems. It offers the developer a JNDI (Java Naming and Directory Interface) for the access to remote systems. Based on JNDI jtom enables the use JMS (Java Messaging Service). The implementation of the JMS-interface inside the jtom-framework is oriented at the WMA-implementation (Wireless Message API, JSR-120) for sending and receiving SMS/MMS. For the moment there is no difference between sending a SMS or a JMS [15]. As such, this provides a very limited functionality of JMS, the developer is only limited to the use of JNDI in order to lookup JMS objects on the JMS provider. The jtom server handles part of the JMS programming for the developer. E.g. JMS defines two administered objects: Connection factory and destinations. Jtom provides the JDNI to lookup this objects, and thereafter, the jtom server creates either a topic connection factory or a queue connection factory depending on the JDNI lookup object. Thereafter, the server creates and maintains a session on behalf of the J2ME client to the JMS provider. Ultimately, the server does a WMA to JMS conversion on messages to and from the JMS provider. 20

The developer does not have other JMS functionalities like: creating their own temporary JMS queues, which exist at runtime only for the duration of a connection. Only that connection can create MessageConsumers for the temporary JMS queue; for example, for use as the JMSReplyTo queue for service requests [20]. The only product in the market at the date of writing this document that provides full JMS implementation on J2ME is ibus//mobile from SoftWired [16], ibus//mobile makes use of wireless JMS (WJMS), a lightweight implementation of JMS. WJMS is capable of implementing both point-to-point and publish/subscribe in a Java library of only 70k, and at run-time, an ibus//mobile application requires as little as 50k heap space. The figure below shows the ibus//mobile architecture Fig 6 ibus/mobile Architecture 1 The components of this architecture are a JMS provider, a mobile JMS gateway, and the WJMS client library. The JMS gateway sits in between the clients and JMS provider. To the JMS provider, the gateway appears to be a regular JMS client. From the clients' point of view, however, the gateway acts as a communications hub and message format translator. The gateway guarantees delivery of messages to the receiving party. The WJMS client library is intended for deployment on programmable wireless devices, but as shown above, the ibus//mobile architecture also caters for nonprogrammable devices, such as pagers and cellular phones [17]. 21

Therefore, it could be said that the client library is optional and depends on the nature of the client device. Scalability is addressed by having several gateways, each supporting hundreds or thousands of mobile devices. The JMS provider would implement load sharing and fault tolerance to cope with the increased demand for resources. Furthermore, two or more JMS providers in a wide area network can be connected using HTTP or SSL. This configuration may appear where a company implements data centers in different regions of a country or even in different countries [17]. The ibus//mobile product provides access controls in the form of userid/ password combinations for queues and topics, and encrypts data transmitted between mobile devices and the gateway. ibus//mobile is able to run on top of most wireless bearers using an appropriate protocol stack. Protocol stacks are instantiated by protocol loaders, and protocol loaders are available for SMS, GPRS, and TCP, among others [17]. 22

3. Design 3.1. Middleware Overview The middleware functionality has been divided into two distinct components, to target two communication types between mobile applications: synchronous and asynchronous communication. A suitable framework for each communication type had to be carefully chosen in order to facilitate a robust platform for development of such applications. 3.2. Middleware Requirements The requirement for the middleware was to provide specifically a middleware toolkit that will assist mobile application developers in developing protocol independent applications. This protocol independency is primary focused at the application level. Hence, the exercise was to find an abstraction on the commonalities in functionalities of the protocols and create a singe API henceforth. 3.3. Design Decisions 3.3.1. Choosing Application Layer Protocols Two representative protocols from the mobile communication paradigm had to be chosen in order to implement the functionality of the middleware which merges both synchronous and asynchronous communication. JMS and SIP (Session Initiation Protocol) were the two chosen protocols that the middleware toolkit is built upon. 3.3.2. Choosing a JMS platform Since the focus of this part of the work is on JMS messaging, a suitable JMS platform has to be chosen. As already outlined previously, JMS defines a specification for sending messages between two or more clients, but the implementation is left to third party vendors. Two of the competing frameworks were: ibus//mobile and jtom. Although ibus//mobile provides the full implementation of JMS on J2ME, there are few problems associated with it. ibus//mobile wireless JMS client library for MIDP includes some classes in the javax. namespace. However, since the release of MIDP 2.x Sun enforced their namespace policy with the release of MIDP platforms to not accept third-party javax package code. A solution to this is obfuscation. However, the obfuscation procedure performed had negative results in that the tools used for obfuscation allow different levels of obfuscation. When the level is to low, the MIDP does not allow third party javax package hence cannot compile the package. If the level to high, the obfuscation deletes some of the classes included in the javax package hence, cannot execute due to runtime errors on missing classes. Therefore, ibus//mobile client library could not be used. The only option left was jtom. 23

3.4. Asynchronous Messaging Platform The contribution to the middleware outlined in this document is on wireless platforms that facilitates development of asynchronous applications. The chosen platform for such applications is jtom (Java to Mobile) message oriented middleware. Jtom is a framework the implements the message oriented middleware infrastructure for mobile devices (mobile phones, smart phones, PDAs) with server side systems [15]. Before we discuss jtom, it might be worthwhile to review some of the concepts from JMS and discuss how they now relate to mobile devices. 3.5. Mobile devices as JMS clients To act as a JMS client, the Mobile device needs to implement the client-side set of JMS functions. This generally includes implementing the support of the following JMS client features: The ability to use connection factories to establish connections with the provider. This means you need to implement the QueueConnectionFactory and TopicConnectionFactory classes in the Mobile device. This lets you the developer create QueueConnection and TopicConnection objects using their respective connection factories. The ability to create and maintain Queue and Topic objects corresponding to the queues and topics maintained on the provider. The inclusion of Mobile client features such as message authoring, message sending and receiving, and session-related JMS client-side classes [18]. The Mobile device also must provide a JNDI client, which can hook into a server and ask it for JNDI lookup. The JNDI client enables the Mobile device to look up different administered objects used to communicate with the JMS provider. JMS clients look up connection factories and destination objects on the provider. After a client has a valid connection factory, it creates connections and sessions using the factory. Then, it writes JMS messages and uses the connection and session objects to send and receive messages [18]. Naturally, it cannot be expected for mobile device with just 160 KB of memory to do all these. The JMS API was not designed with low-end, limited-resource devices in mind. Every machine running a JMS client might not be a powerful server, but it will at least be a desktop machine with reasonable processing capability [18]. The reduced processing capabilities and inherent mobility of a Mobile device make it difficult to run JMS client applications directly on it. However, you can still enable mobile devices to act as messaging clients. You can use a middleware entity (a proxy or a relay) to achieve messaging between mobile clients and enterprise systems. The Mobile device won't actually need to do any heavy processing. It simply issues orders and commands to the relay, which do all the necessary processing. For example, the Mobile device will ask the relay to perform the JNDI lookup; the relay performs the lookup (for example, communication with the server) and sends the result back to the device. This configuration lets the low-resourced mobile device be 24

part of a JMS network, without performing the heavy processing that normal JMS clients require [18]. 3.7. Jtom (Java to Mobile) Jtom is a java framework which supports the development process for mobile distributed applications [21]. With jtom a message-oriented middleware (MOM) is developed for an interactive communication with application servers and legacy systems. jtom delivers interfaces to connect to relevant application servers like BEA, IBM, WebSphere, JBoss. jtom provides the developer with a JNDI (Java Naming and Directory Interface) in order to access backend systems remotely. Based on JNDI jtom enables you to use JMS (Java Messaging Service). With this technology messages can be exchanged over the air between server and client. 3.8. Jtom Technology The architecture of jtom consists of a client component, a server component and a management system. Fig 7: Architectural overview of jtom 2 25

The client program developed with jtom contains the technical logic and further the jtom client component for the communication with an application server. This program runs on J2ME compatible mobile devices. Based on jtom the mobile device initialises a secure connection via the internet (WLAN, GPRS, and UMTS) to a servlet engine (e.g. tomcat) and communicates with the jtom server component. jtom server component features a secure session management and allows to continue the course of business after a connection failure. 3.9. Overall toolkit design The overall toolkit is to provide a framework for developing an application that can run on both JMS and SIP infrastructure. Which means, what is required is an abstraction of the JMS and SIP methodologies that allow an application that uses JMS to be ported to SIP and vice versa without being changed. An additional functionality to the middleware is to enable protocol transparency. By protocol transparency we mean being able for a mobile client to communicate for instance with another mobile client regardless of the protocol used by either clients. This functionality can be realised if only the two participating protocols utilize an intermediary entity for communication. In the case of SIP, an intermediary entity (SIP server) is usually used to establish communication between two clients. After the communication is established, the clients can communication directly. On the other hand, with JMS, since it employs asynchronous mode of communication, there is always an intermediary entity (JMS provider) involved. 3.10. Communication in disruptive environments The middleware functionality is to be extended to cater for communication in disruptive environments. This aspect is particularly applicable if the client establishing a communication is using SIP. Since SIP is connection oriented, clients have to establish a connection before communicating. If the other client is not available for communication, then the client that tried to establish communication can send them a JMS message. Furthermore, if the connection between two SIP clients is disrupted, then the middleware should reroute the affected messages via JMS. Again, SIP clients can enable to receive their JMS messages while connected via SIP. 26

4. Implementation 4.1. Overview The asynchronous messaging of the framework was implemented using jtom v2.1.3. This framework essentially enables the development of JMS clients on CLDC 1.0 and MIDP 2.0. This client library enables connection to a JMS provider, sending and receiving messages to and from defined messages queues on the JMS provider. The library also includes the implementation of messages buffering on the client side in case of network failures and the ability to reconnect henceforth. The library also allows the implementation of a JMS client within a SIP connection. This functionality allows the SIP connection to have access to their JMS messages without the need to reconnect using JMS. Lastly, the library contains a JMS client that receives messages from the SIP server and sends them to the relevant queues in the case of network failure within a SIP connection. Below is the class diagram of the API. This diagram illustrates the JMS framework in the API. Fig 8: Class diagram for the JMS framework in toolkit Connector The connector class, which is inherited from the jtom.microedition.io.connector is an interface for opening a connection. In the JMS context, this connector implements connector.open(connectionurl) which basically opens a connection to the specified host in the ConnectionURL. The URL has the following structure: 27

wma2jms:// - protocol for sending and receiving JMS-messages http://localhost:8080/jtomserver/midpservice; - URL for the jtom-servlet jtom/connection; - bean for the mapping between WMA- and JMS-messages factory=connectionfactory; - relevant for JMS name= anisaqueue; - name of the existing queue in the JMS-provider type=queue; - Destination type (could also be a TOPIC) user=anisa; - user associated with the destination (optional) password=middleware - password for the queue destination (optional) MessageConnection MessageConnection defines the functionality for sending and receiving messages. MessageListener this is set by the MessageConnection, The MessageListener interface provides a mechanism for the application to be notified of incoming messages. When an incoming message arrives, the notifyincomingmessage() method is called. The notifyincomingmessage(), calls a receive method. The receive method has different variations depending on how the application intends on receiving the messages. The variations are: receiveall(), receivesome(selector), receive(). JMSIPFactory this is created by the MessageConnection, and it provides the mechanism for setting a specific connection type. For a JMS connection, this implements a method for creating a JMS message. JMSIPMessage This interface provides functionality on either a JMS or a SIP message. The implemented methods are: addheader(),getpayload(),setpayload(),getconfig(),setjmsmessage(),getjmsmessag e(). On the server side, the library also has JMS client implementation that can be used in disruptive environments, where network connectivity is intermittent. Below is the description of the components involved. LAN SIP Server SIP Servlet JMSClent Wireless Network SIP Client Sends Message Receives message JMS provider 28

Fig 9: Components of the JMS-SIP System The SIP servlet component does the user registry with the SIP server, binding the user s URI with their IP address. An internal database is maintained for mapping a sip user s URI with their JMS queue. In case of a network failure between a SIP session, the SIP servlet sends the affected messages to the JMS client which the forwards the messages to the appropriate queues in the JMS provider. The implementation was tested on JBoss Application Server 4.0.0 as a JMS provider. 4.2. Jtom v2.1.3 The latest version of jtom (2.1.3) provided a client library that allowed a smaller JAR size. This aspect is advantageous, particularly since mobile devices are resource constrained. This version also facilitated authentication against the JMS provider with a combination of a username and password. 4.3. JBoss Application Server 4.0.0 JBoss AS 4.0 implements the JMS (Java Messaging Service) 1.1 specification instead of the JMS 1.0 in JBoss AS 3.2. In JMS 1.0, client programming for the Point-to- Point and Pub/Sub domains was done using similar but separate class hierarchies. In JMS 1.1, there is now a domain-independent approach to programming the client application [22]. 4.4. Full API The full API is a combination of the JMS and SIP frameworks. The core communication interfaces of the combined API are: JMSIPConnector MessageListener SipClientConnectionListener clientlistener, SipServerConnectionListener serverlistener notifyincomingmessage notifyresponse The middleware is also bearer agnostic in that it utilises any bearer infrastructure that is supported by the mobile device as long as that particular application type is supported. 29

5. Project Evaluation In order to evaluate the effectiveness of the toolkit, a sample chat application (JMSIPO chat) was built which could either connect using SIP of JMS for communication. When the application starts, the user can either decide to connect using JMS or SIP as shown below: Fig 10: JMSIPO welcome screen After the user selects their protocol of choice, then they have to configure their JMS setting, which includes: Server IP, Own Queue, and Destination Queue Name 30

Fig 11: JMSIPO JMS settings Server IP - This signifies the JMS provider. Own Queue - The user s own queue for listening for messages Destination Queue Name - The recipients queue name If the user selects SIP, then additional parameters, such as the recipients URI are provided. Then the users can start sending and receiving messages 31

Fig 12: JMSIPO chat sending and receiving Particular to JMS, the application maintained an internal queuing for messages that failed to due to connection failure. These messages are resend as soon as a connection to the JMS provider is re-established. This functionality ensures that messages are not lost due to network failures. On the other hand, particular to SIP, the application enabled JMS message retrieval while still connected via SIP. This functionality allows the SIP clients to retrieve their messages that may have been sent to them while offline if they decide to connect using SIP. 6. Conclusion The aim of the project was develop a mobile communication middleware toolkit which provides application developers with a series of application programming interfaces that enable them to develop application layer- independent protocols. The representative application layer protocols that were used for this middleware are JMS (Java Messaging Service), for asynchronous, loosely coupled communication and SIP (Session initiation Protocol) for synchronous, connection oriented communication. The resulting middleware classes enables developers to create a single application that can run on both JMS and SIP. 7. Future Work 7.1. More Protocols 32

An apparent extension to this middleware is to include more application layer protocols, for instance such as those used in instant messaging applications and sms. 7.2. Autonomic Communication Since the middleware is bearer agnostic, one of the possible extensions is to incorporate an autonomic behaviour to the middleware for handling network handover. Meaning, the middleware should be able to detect and do network handover based on certain condition e.g. quality of service, user preferences etc. For quality of service, the middleware should do a network handover from when the quality of service degrades on the bearer that the application is currently running and provide an alternative to shift to another bearer that is suitable for the application to run on. On user preferences, if say the user is running the application on a commercial network such as GPRS etc and they walk into a local WIFI network, the middleware should provide handover. In this case the handover will be triggered by user preferences relating to costs. 33

8 References: [1] Salminen T & Riekki J, Lightweight middleware architecture for mobile phones. Proc. 2005 International Conference on Pervasive Systems and Computing, Las Vegas, NE, 147-153, 2005 [2] Ghizzioli, R., Greenwood, D, "The RASCAL System for Managing Autonomic Communication in Disruptive Environments" in proc. of the 1st IEEE Workshop on Autonomic Communication and Network Management (ACNM), as part of the 10 th IFIP/IEEE International Symposium on Integrated Network Management, Munich, Germany, 2007. [3] Einar, V, Extending an enterprise messaging system to support mobile devices Department of Computing Science, Newcastle University, 2001 [4] IBM s MQSeries product overview page, http://www-3.ibm.com/software/ts/mqseries/ accessed October 2007 [5] IBM Websphere Message Broker, Publish Subscribe, version 6, release 0 ftp://ftp.software.ibm.com/software/integration/wbibrokers/docs/v6.0/messagebroker _Publish_Subscribe.pdf accessed October 2007 [6] Wikipedia Publish Subscribe, http://en.wikipedia.org/wiki/publish/subscribe accessed October 2007 [7] The Tibco website, http://www.tibco.com/ accessed October 2007 [8] Sun Microsystems, Java Messaging Service http://72.5.124.55/products/jms/tutorial/index.html accessed October 2007 [9] Sun Microsystems, Java 2 Micro Edition Specification http://java.sun.com/javame/index.jsp Accessed October 2007 [10] Wikipedia Bluetooth, http://en.wikipedia.org/wiki/bluetooth accessed October 2007 [11] TechTarget, Infrared Definition http://searchmobilecomputing.techtarget.com/sdefinition/0,,sid40_gci293474,00.html accessed October 2007 [12] FreePatentsOnline, Message Proxy System http://www.freepatentsonline.com/6721779.html Accessed October 2007 [13] My-Channels, Nirvana, http://www.mychannels.com/developers/nirvana/index.html accessed October 2007 [14] Sun Microsystems, Wireless Messaging API, http://java.sun.com/products/wma/index.jsp accessed October 2007 34