35
Mobile Communication Middleware Lekometsa Mokhesi [email protected] Supervised by: Prof. Ken MacGregor Department of Computer Science University of Cape Town October 2007
Mobile Communication Middleware
Lekometsa Mokhesi
Supervised by:
Prof. Ken MacGregor
Department of Computer Science
University of Cape Town
October 2007
2
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
3
4
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
5
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
6
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
7
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 multi-
technology 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
8
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.
9
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
10
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
11
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 message-
oriented 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 Sever JMS Producer JMS Consumer
Messages Messages Message
Producer
Point-to-Point
Queues
Message
Consumer
Publish-
Subscribe
Topics
Fig 1: Basic architecture of JMS System
12
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].
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.
Acknowledges
Consumes
Sends
Client 1 Client 2
Msg
Queue
Msg
Fig 2: Point to Point Messaging
13
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.
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.
Subscribes
Delivers
Delivers
Subscribes Publishes
Client 1
Client 3
Msg
Msg
Topic
Client 2
Msg
Fig 3: Publish/Subscribe Messaging
14
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).
Receives
from
Sends
to
Creates
Creates
Creates
Creates
Creates
Connection
Factory
Connection
Message
Producer
Message
Consumer
Destination
Message
Destination
Session
Fig 4: JMS API Programming Model
15
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
16
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
17
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.
18
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
Fig 5 Java 2 Micro Edition (J2ME)
Java 2
Enterpris
e Edition
(J2EE)
Java 2
Standard
Edition
(J2SE)
CDC
MIDP
CLDC
Java Virtual Machine KVM
Profile
Level
Configurati
on Level
19
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.
20
• 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.
21
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].
22
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].
23
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.
24
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
25
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
26
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.
27
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:
28
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.
SIP Client
JMSClent
SIP Servlet
SIP Server
JMS provider
Sends Message Receives message
Wireless Network
LAN
29
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.
30
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
31
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
32
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
33
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.
34
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 10th
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.my-
channels.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
35
[15] ITSD Consulting, “Jtom technology”,
http://www.jtom.de/jtom_Technology.28.0.html?&L=2 accessed October 2007
[16] Softwired-inc, “iBus/Mobile description” http://www.softwired-
inc.com/products/mobile/mobile.html accessed September 2007
[17] Wireless-center, “JMS in commercial wireless middleware products”
http://www.wireless-center.net/Mobile-and-Wireless/2499.html accessed September
2007
[18] IBM, “Wireless messaging with JXTA”,
http://www.ibm.com/developerworks/wireless/library/wi-jxta/ accessed September
2007
[19] University of California at Berkeley, “Message Oriented Middleware”
http://www2.sims.berkeley.edu/courses/is206/f97/GroupB/mom/ accessed October
2007
[20] IBM, “temporary queues”,
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.web
sphere.pmc.express.doc/concepts/cjn0002_.html accessed October 2007
[21] ITSD Consulting, “Jtom Mobile Computing”
http://www.jtom.de/uploads/media/WhitePaper_EN.pdf accessed October 2007
[22] Red hat Middleware, “JBoss Application Server 4.0.”
http://labs.jboss.com/jbossas/downloads/ Accessed October 2007
[23] Jiyong, P. Saehwa, K.Wooseok, Y. Seongsoo, H. “Designing Real-Time and
Fault-Tolerant Middleware for Automotive Software”, SICE-ICASE International
Joint Conference, Korea, October 2006
