Embed Size (px)
Citation preview
0
WIRELESS JAVA MESSAGE SERVICE (JMS) MIDDLEWARE
A thesis presented in partial fulfilment of the requirements for the degree of Master of Science (IT) at Bond University,
Australia.
Andres Gonzalez
2002
Supervisor: Daniela Mehandjiska-Stavreva
1
ABSTRACT
The purpose of this project is to explore the current Wireless Java
Messaging Service (JMS) middleware technology and to identify key issues
when implementing a distributed service over wireless devices. Once
advantages and disadvantages of the technology are identified, decisions
can be made whether to use this technology when implementing a
distributed service over wireless devices. Alternative solutions have been
evaluated and considered to address shortcomings of the Wireless JMS
middleware technology. The application developed during the project has
implemented a JMS service using the most commonly used
publish/subscribe model. This model allows many publishers to send
messages to a topic and many subscribers to consume the messages.
MyNews is an application developed using JMS as a middleware between
mobile devices and enterprise applications. A user subscribes to topics
available in MyNews and receives information whenever a topic is updated,
either using e -mail or Short Message Service (SMS).
The subscribers are software components receiving messages from the
JMS server when messages become available, and sending them to mobile
devices. The JMS server is capable of sending messages without using a
subscriber component, but subscriber components have been deployed. A
mobile component has been implemented to send messages to a server
using JMS as a middleware.
Various design patterns have been identified and used during the design
and implementation of MyNews application. Alternative system
architectures have also been considered.
The project has also addressed software and hardware impediments faced
by projects with wireless service requirements. Available toolkits and useful
examples have been identified. MySQL, JDBM, OpenJMS, Tomcat and
Java 2 Micro Edition Toolkit technologies have been configured to
implement a basic wireless JMS infrastructure.
2
LIST OF FIGURES
Figure 2.1 N-tier architecture……………………………………………………… 9
Figure 2.2 Java 2 Ente rprise Edition architecture……………………………… 11
Figure 2.3 Messaging as a middleware between components………………. 12
Figure 2.4 Message Oriented Middleware……………………………………… 12
Figure 2.5 Queue Based (Point-to-Point) Model………………………………. 14
Figure 2.6 Publish/Subscribe model……………………………………………. 14
Figure 3.1 Bus architecture……………………………………………………… 18
Figure 3.2 Hub-and-Spoke architecture……………………………………….. 19
Figure 3.3 Structure of a JMS message………………………………………. 20
Figure 3.4 JMS messages types…………………………………………………. 21
Figure 4.1 OpenJMS GUI Tool………………………………………………….. 30
Figure 4.2 OpenJMS example…………………………………………………… 32
Figure 5.1 System architecture…………………………………………………. 38
Figure 5.2 Clustering in Publish/Subscribe domain…………………………… 40
Figure 5.3 Full replication clustering……………………………………………. 41
Figure 5.4 Topic home clustering………………………………………………. 42
Figure 6.1 User registration…………………………………………………….. 45
Figure 6.2 JMS sequence diagram…………………………………………….. 48
Figure 6.4 JMS publishing web interface………………………………………. 49
Figure 7.1 Integration Java Message Service and Enterprise Java Beans…….. 57
3
LIST OF TABLES
Table 3.1 Point-to-point and Publish/subscribe interfaces…………………….. 18
Table 3.2 Header fields…………………………………………………………. 20
Table 3.3 Standard properties…………………………………………………. 21
Table 3.4 General characteristics for each configuration…………………….. 23
Table 4.1 OpenJMS system requirements…………………………………….. 28
Table 4.2 OpenJMS environment variables…………………………………… 28
Table 6.1 Description of table user…………………………………………………. 44
Table B.1 Selector Operators………………………………………………….. 64
Table B.2 Literal selectors……………………………………………………….. 65
Table B.3 Selector examples……………………………………………………. 67
4
Chapter 1
INTRODUCTION
1.1. Aims
The purpose of this project is to explore the current Wireless Java
Messaging Service (JMS) middleware technology and to identify key issues
when implementing a distributed service over wireless devices. Once
advantages and disadvantages of the technology are identified, decisions
can be made whether to use this technology when implementing a
distributed service over wireless devices.
The project has also addressed software and hardware impediments faced
by projects with wireless service requirements.
1.2. Significance
?? Improved connectivity
One of the most important benefits of this project is that in the future people
will not need to be connected to a desktop computer to reach the Internet.
Mobile devices and different ways of sending valuable information to other
parties are emerging every day. The JMS technology is one of them.
?? Increase in mCommerce applications
The growth and use of mobile devices for communication is increasing at a
very high rate. Companies are looking for better ways of reaching their
customers and this technology is one of the most important ones.
?? Personalised user profiles
Internet users are tired of looking for information on the web. They only
want to get alerted when events according to their profile are happening
5
around the world. Wireless JMS middleware is a very good technology to
achieve this purpose.
?? Increased number of distributed applications
JMS-based communication is a potential solution in any distributed
computing scenario in which it is needed to pass data, either synchronously
or asynchronously, among distributed software components. A component
can subscribe to specific topics, or connect to specific queues, and then act
accordingly when qualifying messages arrive. JMS servers are now in
charge of storing and sending the messages, not the components or
applications.
?? Increase in e-commerce and e-business applications
JMS is an important tool for both e -commerce and e-business applications.
Any enterprise computing strategy that calls for middleware solutions
functioning as a glue and/or communication pathways among legacy
applications is a potential candidate for JMS-based distributed software
components. It is straightforward to develop distributed components that
interface with legacy applications (e.g. Enterprise JavaBeans components).
These legacy-software -managing EJB components can transmit legacy-
related data via JMS middleware.
1.3. Research questions
?? What support tools and technologies are currently available to develop
Wireless JMS middleware? Are good toolkits, libraries of design
templates and useful examples available?
?? What design patterns are applicable?
?? What architectures are applicable?
6
1.4. Outcomes
?? An application that illustrates how JMS technology can be applied.
The application has implemented a JMS service using the most commonly
used publish/subscribe model. This model allows many publishers to send
messages to a topic and many subscribers to consume the messages.
The subscribers are software components receiving messages from the
JMS server when messages become available and sending them to mobile
devices. A mobile component has been implemented to send messages to
a server using JMS as a middleware.
?? Applicable design patterns
?? Applicable software architectures
?? Key issues, advantages and disadvantages of JMS technology.
Guidelines on hardware and software requirements.
7
LITERATURE REVIEW
WIRELESS TECHNOLOGIES
8
Chapter 2
MESSAGING SERVICES
2.1. Distributed systems architecture
In the early years enterprise applications have been implemented utilizing
the two-tier architecture, with a thin client and a server that performs all the
operations. This type of environment has been easy to deploy at first, but
difficult to modify once the application had grown.
Developers have seen that breaking apart the different layers in three -tier
architecture can help them to separate the presentation (the view) from the
business logic (the processing). The three-tier architecture has been
adopted because of [19]:
??Improved scalability, availability and ease of integration
??Easier system maintenance
Three main layers have been identified in the three-tier architecture (Figure
2.1):
?? Layer 1: Presentation Logic
?? Layer 2: Business Logic
?? Layer 3: Database Management
Presentation logic is in charge of serving pages to the clients (in a website
application), business logic is only performing the processing, and database
management is accessing the database, managing connections pools, etc
[20]. The advantage of three-tier architecture is that one layer can be
changed without changing the rest of the system.
In addition, layers can be divided into multiple layers, forming the N-Tier
architecture. Tiers can be conceptually separated, or physically located on
different servers and even in different geographical locations. Presentation
9
Figure 2.1 N-tier architecture
http://ww.sun.com.
logic and processing is distributed among logical and physical “tiers”. For
instance, if new space is added to the database, the code implementing the
presentation and business logic will not have to change to adapt this new
feature. The layered approach is suitable for more scalable enterprise
applications. In addition, N-Tier architecture implies the availability of highly
skilled developers that can manage concepts like multi-threads, database
connections pools and so on. Nowadays, developers are in charge not only
of the applications development, but the security, performance, system
breakdowns, etc.
Several businesses have adopted the three -tier architecture to get more
benefits and to easily adapt to the inevitable changes. Companies like
Microsoft, Sun, Bea Systems, IBM, have provided frameworks – a standard
API for developing distributed applications. These frameworks have been
designed to allow the developer to concentrate only on the business logic,
letting the persistence, security, concurrency, network protocols, etc., be
managed by the application server. Sun Microsystems’ Java 2 Platform
Enterprise Edition (J2EE) is one of these frameworks [1].
J2EE defines a standard to simplify the development of N-tier enterprise
applications. It is a collection of specifications that describe required APIs
and policies, controlled by the Java Community Process (JCP) [6].
10
Whenever a new specification is released, different vendors compete for the
implementation of the specification. Companies then can select an
implementation that better suites their requirements.
2.2. Messaging services
Messaging has been widely used today to support business-to-business
(B2B) and business-to-consumer (B2C) transactions, often occurring over
the Internet.
In the early years messaging between companies and applications has
been implemented using the XML-RPC (Remote Procedure Call)
mechanism, promoting the notion of exchanging XML over the HTTP
protocol. The application of RPC for largely distributed systems is a highly
limited mechanism, particularly when those systems connect multiple
businesses across the Internet [2].
Implementing a full messaging service using RPC is a very difficult task.
Most RPCs use a synchronous, request-reply (also called call/wait)
protocol, which involves blocking of the client until the server fulfills its
request. Many problems arise and a variety of tasks exist which are almost
impossible to handle using synchronous RPC. How can you ensure that the
message sent is received and acknowledged? What if the network
connection is down? The application will have to keep running its processes
until the message reaches its destination. RPC does not provide assistance
for any of these problems.
2.2.1. Introduction to JMS
Java Messaging Service is one of the core technologies incorporated in the
Java 2 Enterprise Edition (J2EE) architecture (Figure 2.2). Sun
Microsystems published the JMS specification in 1999, which defined a
series of programming interfaces to the Java Messaging Middleware. This
technology alleviates the problems of the old RPC model.
11
Widely used J2EE technologies include:
??JNDI – Java Naming and Directory Interface – for accessing shared
directory resources
??Servlets and JavaServer Pages – for extending web applications on the
server
??Enterprise JavaBeans – for building complex multi-tier enterprise
applications
??JTA, the Java Transaction API – providing the transactional interfaces
needed between distributed resources and a transaction manager
??JDBC and JCA, J2EE Connector Architecture – providing a standard
way of accessing Enterprise Information Systems – including
applications and databases.
JMS defines how clients access the facilities of an enterprise-messaging
product. Enterprise messaging is recognized as an essential tool for
building enterprise applications and e-commerce systems, and JMS
provides a common way for Java programs to create, send, receive, and
read an enterprise messaging system's messages [3]. The technology helps
to develop peer-to-peer communications between software components,
having a middleware between components, as shown in Figure 2.3.
Figure 2.2 Java 2 Enterprise Edition architecture.
http://www.sun.com
12
JMS is also an alternative for transmitting business-to-business XML-based
messages. Messages can be classified as events, requests or replies and
can contain formatted data with specific business meanings.
Figure 2.3 Messaging as a middleware between components.
http://softwired- inc.com
2.2.2. Message -Oriented Middleware
JMS utilizes message-oriented middleware (MOM). “… MOM a client/server
infrastructure that increases the interoperability, portability and flexibility of
and an application by allowing the application to be distributed over multiple
heterogeneous platforms..” [26] (Figure 2.4). A traditional form of
middleware requires a direct (also known as synchronous) connection
between applications [4]. Message -oriente d middleware works without that
direct connection. Every message is stored in a queue until another
application looks for that data, either using a FIFO (First In, First Out)
mechanism or on a priority basis.
Figure 2.4 Message-oriented Middleware
MOM
Client 1 Client 2 Client N
Message Message Message
Messaging Server
Messages
13
MOM increases the flexibility of an architecture, enabling applications to
exchange messages with other programs without knowing what platform the
other application resides on within the network.
Some of the advantages of MOM are:
?? MOM allows the communicating applications to have completely
separate lifetimes. A user can send messages without been
connected to a network. Once the user connects, the MOM is in
charge of firing off all messages stored in the queue, ensuring that all
messages reach their destination only once.
?? A sender does not need to be aware of who or how many receivers
are subscribing to a specific topic.
?? The same MOM can be used for multiple applications. For example, if
the message is an XML document, only the receiver will know what to
do with it. The MOM does not understand the messages; it just
forwards them.
??MOMs allow messages to be prioritized.
??MOMs guarantee messages are delivered exactly once.
Applications developed using MOM have an additional layer. This is an
advantage because new applications do not have to deal with
communication issues, as MOM is in charge of it. This helps developers to
focus only on the business logic.
2.2.3 Messaging models
Messaging systems are classified into different models that determine which
client receives a message [5]:
?? Point-to-point model
?? Publish/subscribe model
14
Point-to-point model
The simplest messaging model exists when one application produces a
message and another application consumes it. Multiple senders and
only one receiver is ano ther case, shown in Figure 2.5. The destination
in this model is called a queue.
The point-to-point domain is analogous to a typical E-mail in-box. The
message sender delivers a message to a specified queue, which is
accessed at some later time by a message recipient.
Figure 2.5 Queue Based (Point-to-Point) Model
Publish/subscribe model
Within this model, an application registers as a publisher of messages
for some destination, called topic, while one or more other applications
subscribe to messages on that topic (Figure 2.6). Multiple publishers
may send messages to a topic, and all subscribers to that topic receive
all the messages sent to that topic. Relationships can be many to many
or one to many.
Figure 2.6 Publish/subscribe Model
Sender
Sender
Sender
Messaging Server
Queue Message
Message
Message
Receiver Message
Message Publisher
Messaging Server Publisher
Topic Message
Message
Message
Subscriber
Publisher Subscriber
Subscriber
15
With publish -and-subscribe, you create message topics to which clients
can subscribe. For example, a trading application that allows an investor
to track selected stocks provides the functionality: the investor chooses
a stock to monitor by subscribing to it; the message broker then adds
that investor to a list of recipients it will notify him of price changes.
The publish/subscribe model has a significant advantage: If a new
receiver wants to subscribe to a particular topic, it only subscribes to the
messaging server. The sender knows nothing about it.
When a subscribing client requests a durable subscription, the
Messaging Server will store all messages sent for the subscriber when
the subscriber is inactive. Once the message is sent, the receiver can
consume it either synchronously or asynchronously.
JMS provides an application-programming interface (API) to create,
send, receive and read messages. It supports a standard Java-based
interface to MOM’s message services, and can be used in the
development of heterogeneous applications. Using this API, the
components created in the application do not have to deal with
messaging issues (short-time network failure, low bandwidth, receiver
offline, etc).
The characteristics of JMS are as follows:
?? Connection factories are used in JMS to create connections to a
specific JMS provider.
?? Publish/Subscribe messaging and Point-to-Point messaging
domains are implemented and defined by separate interfaces so that
a provider does not have to support both.
16
Chapter 3
WIRELESS TECHNOLOGIES
3.1. JMS systems
A JMS system is typically composed of the following components:
??JMS providers
JMS providers are software vendors who implement the interfaces
defined in the JMS specification, and who provide features like load
balancing, clustering, persistence services, etc.
??JMS clients
Programs or components written in Java that extend the JMS
architecture using the services provided by the JMS provider.
??Administered objects
Administered objects are pre-configured JMS objects created by the
JMS administrator. They are available for standard JNDI (Java Naming
and Directory Interface) lookup.
Java Naming and Directory Service (JNDI) is a Java technology API for
publishing, managing, and accessing public references to distributed
functionality. An application, for example, can:
?? Instantiate an object that provides remote database services. ?? Register this object under a public symbol via JNDI. Advertise
that object's services to remote clients.
JNDI provides network-oriented-look-up services for distributed objects.
It works with other J2EE technologies to organise and locate
components in a distributed environment.
There are two types of administered objects:
??ConnectionFactory: Used to create a connection to the
messaging system.
17
??Destination: Used by the JMS client to specify the destination of
messages being sent or the source of messages being received.
?? Non-JMS clients
Non-JMS clients are programs that use a messaging product’s native
client API instead of the JMS API. Legacy programs, for example, will
often be part of a JMS application.
The JMS specification defines a set of interfaces that are widely used in the
point-to-point and publish/subscribe models. The interfaces are:
?? ConnectionFactory: An administered object that creates a connection.
?? Connection: An active connection to a provider. ?? Destination: An administered object that hides information about
the message destination.
?? Session: A single thread for sending and receiving messages.
?? MessageProducer: Used for sending messages. ?? MessageConsumer: Used for receiving messages.
Table 3.1 illustrates the specific interfaces related to the point-to-point and
publish/subscribe domains.
The basis for sending and receiving information is a connection . A JMS
vendor typically implements at least a QueueConnection or a
TopicConnection, depending on the domain (see table 3.1). These
connections supply a Session, which is used for sending and receiving
information.
A typical JMS program goes through the following steps to begin producing
and consuming messages:
1. Lookup a ConnectionFactory through JNDI.
2. Lookup one or more destinations through JNDI.
18
High-level interface Point-to-point domain Publish/subscribe
domain ConnectionFactory QueueConnectionFactory TopicConnectionFactory Connection QueueConnection TopicConnection Destination Queue Topic Session QueueSession TopicSession MessageProducer QueueSender TopicPublisher
MessageConsumer QueueReceiver, QueueBrowser
TopicSubscriber
Table 3.1 Point-to-point and Publish/subscribe interfaces
3. Use the ConnectionFactory to create a Connection.
4. Use the Connection to create one or more Sessions.
5. Use a Session and a Destination to create the required
MessageProducer and MessageConsumer.
6. Start the Connection.
Messaging middleware products vary in their implementation. The two most
common implementations are the bus architecture and Hub-and-spoke
architecture.
3.1.1. Bus architectures
In a bus architecture, each client contains the functiona lity found in a
messaging service, such as security, persistence, transaction, etc. Every
client is connected to the bus and it is in charge of checking that the
message is delivered to its destination. Figure 3.1 illustrates this
architecture [21].
One of the major disadvantages of this architecture is that every client is
checking the status of the message sent. These tasks should be
accomplished by a centralized process for improved efficiency.
Figure 3.1. Bus Architecture
Client Client Client
Message Bus
19
3.1.2. Hub-and-Spoke architecture Most of the JMS vendors implement the hub-and-spoke architecture. In a
hub-and-spoke architecture, applications are connected to a central
process, also known as a message server. It is in charge of communicating
with the clients, routing the messages, and guaranteeing the delivery of the
message. Figure 3.2 illustrates the hub-and-spoke architecture [21].
Figure 3.2. Hub-and-Spoke architecture
The advantages of using the hub -and-spoke architecture are:
?? Smaller software components may be required for clients’ applications
to establish connections. All the processing logic is contained in the
message server.
?? Senders and receivers do not have to know each other, which
improves scalability.
??Reduced number of network connections.
3.2. Messages
JMS messages are categorized depending on the type of content that the
messages can have in their body. Each type is defined by a message
interface. Figure 3.3 shows a JMS message structure [22].
A message is divided into three parts:
?? Header: defines various standard fields for routing, expiration,
identification, etc. Table 3.2 shows some header fields defined by
JMS.
Client Client
Client Client
Message Server
20
Figure 3.3. Structure of a JMS Message
?? Properties: properties extend the functionality of header fields. They
provide facilities for adding optional header fields to a message. Table
3.3 shows some of the JMS properties.
?? Body: contains the content to be delivered to a receiving application.
Header Name Description
JMSMessageID Uniquely identifies each message.
JMSDestination Destination to which the message is sent.
JMSPriority
Priority of the message. 0 is the lowest priority, 9 is the highest priority.
JMSReplyTo Used to indicate where a reply should be sent.
JMSType Used to indicate the message type.
JMSDeliveryMode
Contains the value PERSISTENT or NON_PERSISTENT for a particular message. Persistent messages are delivered once and only once. Non-persistent messages are delivered “at most once”.
Table 3.2. Header Fields
Header
Properties
Body
Message
21
Properties Description
JMSXUserID Identity of the user sending the message.
JMSXRcvTimeStamp The time JMS delivers the message to the consumer.
JMSXDeliveryCount
Number of times the delivery of the message has been attempted.
Table 3.3. Standard properties
JMS supports five types of message bodies. The simplest of these is a
TextMessage , which holds a single Java String value. A BytesMessage
holds a stream of uninterpreted bytes and a StreamMessage holds a stream
of Java primitive types. BytesMessage and StreamMessage are written and
read using methods similar to those of the java.io.DataOutputStream and
java.io.DataInputStream classes. A MapMessage holds name/value pairs
similar to a Hash table. The values can be read randomly by specifying the
name, or they can be returned in an Enumeration. An ObjectMessage holds
any serializable Java object. Figure 3.4 illustrates the JMS message types.
Every message type inherits from the Message class.
The JMS specification gives no support for XML messages. Given the rapid
growth and widespread use of XML, it’s likely that several vendors will offer
direct XML support. The authors of JMS included the TextMessage type,
presuming that String messages will be used extensively.
Figure 3.4. JMS messages types
The JMS provides a mechanism, called a message selector, for a JMS
program to filter and categorise the messages it receives. Message
selectors are strings that are evaluated using JMS properties and standard
headers.
As a JMS server rece ives messages from clients, the server applies a
consumer's selector to the data in the message header and evaluates which
Message
MapMessage ObjectMessage StreamMessage TextMessage BytesMessage
22
client(s) should receive the message. Messages that do not meet the
selection criteria are not delivered to the consumer. A message selector
uses SQL92 condition syntax. For example:
JMSType = ‘car’ AND color = ‘blue’ AND weight > 1000
The JMSType is in the header field. Color and Weight are declared in the
properties field.
3.3. Java 2 Micro Edition (J2ME)
Most Internet technologies are designed for desktop and large computers
running on reliable networks with relatively high bandwidth. Hand-held
wireless devices, on the other hand, have a more constrained computing
environment. They have less memory, less powerful CPUs, different input
devices, and smaller displays. Further, wireless networks have less
bandwidth and more latency compared to wired computer networks.
“… J2ME technology specifically addresses the vast consumer space,
which covers the range of extremely tiny commod ities such as smart cards
or a pager all the way up to the set-top box, an appliance almost as
powerful as a computer. Like the other editions, the J2ME platform
maintains the qualities that Java technology has become famous for:
?? Built-in consistency across products in terms of running anywhere,
any time, over any device
?? Portability of the code
?? Leveraging of the same Java programming language
?? Safe network delivery
?? Applications written with J2ME technology are upwardly scalable to
work with the J2SE and J2EE platforms [7].
Specifically designed for mobile devices, J2ME (Java 2 Platform, Micro
Edition) is compatible with all popular operating systems. This means that a
range of applications can be implemented across different networks and
handsets.
23
J2ME introduces two concepts to support a wide range of devices with
limited memory: The configuration and the profile.
Configurations consist of the Connected Device Configuration (CDC) and
the Connected Limited Device Configuration (CLDC) [23].
The CDC configuration runs the well-known Java Virtual Machine (JVM). It
is normally used for devices such as set-top box, Internet screen phone,
etc.
The CLDC configuration is intended for devices with limited hardware
capabilities, such as mobile phones, low-end personal digital assistants
(PDAs), and pagers. Table 3.4 illustrates the characteristics of each
configuration.
The profile defines the application and the type of devices supported by a
particular application. Profiles are built on top of configurations. Two
profiles have been defined for J2ME and are built on CLDC: Kjava and
Mobile Information Device Profile (MIDP).
Connected Device Configuration Connected Limited Device Configuration
512 kilobytes (minimum) memory for Java
runtime
128 kilobytes memory for Java runtime
256 kilobytes (minimum) for runtime memory
allocation
32 kilobytes memory for runtime memory
allocation
Network connectivity, possibly persistent
(always on) storage, high bandwidth
Limited user interface
Limited power -- typically battery
Network connectivity -- typically wireless
Table 3.4 General characteristics for each configuration.
MIDP is a version of the Java platform based on CLDC that is aimed at
small footprint devices, principally cell phones and two -way pagers. It is
also suitable for running on PDAs, and an implementation is available for
24
PalmOS Version 3.5 and higher. MIDP hardware and software
requirements are described in appendix A.
3.4. MIDlet
MIDP applications are called MIDlets. A MIDlet is a Java application
designed to run on a mobile device [23].
Each MIDlet goes through several phases as part of its lifecycle, and is
always in one of the following three states:
??Paused
After the constructor has been called, but prior to being started by the
applica tion manager. A MIDlet may alternate between the Paused and
Active states any number of times during its lifecycle. Transitions occur
when the application manager pauses/reactivates the MIDlet or when the
MIDlet makes a specific request to be paused/ reactivated.
??Active
The MIDlet is running on an emulator or physical device.
??Destroyed
The MIDlet has released any resources it acquired, and has been
shutdown by the application manager.
Applications written for the Mobile Information Device Profile (MIDP) are
rarely stand -alone applications. Normally, there's some part of the
application that involves calling server-side code for processing. In MIDP
1.0, the only way to portably invoke server-side code is by making HTTP
requests to a servlet running in an e xternal Web server.
25
Chapter 4
JMS WIRELESS INFRASTRUCTURE
4.1. Problem Definition
The two main technologies that have been used to implement a wireless
JMS infrastructure are JMS and Java 2 Micro Edition (J2ME).
The research has focused on an integration of these two technologies. The
expected result is an application running on a mobile device, connected to
the JMS server and publishing messages to different subscribers. A
consumer (a component written in Java) running on a desktop machine is
also implemented, connected to the JMS server and retrieving the
messages asynchronously. No direct relationship between the producer of
the message and the consumer exists.
An evaluation of different architectures is conducted, developing another
component to consume messages and send them to a mobile using the
well-known Short Message Service (SMS).
4.2. Existing vendors, solutions and applications
?? WebLogic 6.0 from BEA Systems
WebLogic Server is a platform for developing and deploying multi-tier
distributed enterprise applications. WebLogic Server centralizes
application services such as Web server functionality, business
components, and access to backend enterprise systems. It uses
technologies such as caching and connection pooling to improve
resource usage and application performance. It also provides
enterprise -level security and powerful administration facilities [9].
?? FioranoMQ 5 from Fiorano Software
FioranoMQ is a high-performance, fully JMS compliant messaging
middleware platform. In addition to supporting all the documented
Publish/Subscribe and PTP (Point-to-Point) functionality in the JMS
26
API, FioranoMQ adds a highly configurable security system,
scalability, web integration, and XML interoperability [10].
?? MQSeries JMS from IBM
MQSeries for Java Message Se rvice(JMS) (MQ JMS) is a set of Java
classes, that implement Sun's Java Message Service (JMS) interfaces
to enable JMS programs to access MQSeries systems. Both the point-
to-point and publish-and-subscribe models of JMS are supported [11].
?? SonicMQ 4.0 from Progress Software
SonicMQ from Progress Software is a 100% Java-based messaging
service that supports both point-to-point and publish/subscribe
messaging paradigms. SonicMQ is one of the first full implementations
of the JMS specification. The product not only complies with the latest
version of JMS but goes beyond the minimum set of features called
out in the JMS Specification [12].
SonicMQ supports the XML standard data format. Progress has
added other enhancements to the product to ensure high
performance, reliability, flexibility, and ease of use.
?? JMQ 1.1 (Java Message Queue) from Sun Microsystems
The Java Message Queue is an implementation of the Java Message
Service specification. It provides utilities for remotely administering the
router and provides facilities for debugging, monitoring, administering
users, etc [13].
?? OpenJMS from Exolab.org
OpenJMS is an implementation of the Java Message Service
specification, developed by the Exolab group [8]. OpenJMS runs as a
standalone application, facilitating the installation and configuration of
the system [8].
The OpenJMS implementation has been selected for the project for the
following reasons:
27
?? No extra configuration is required because it is a standalone
application
?? The feedback and support provided by the Exolab community is
notorious, comparing with other vendors
?? Integration with Tomcat is easily achieved
?? An administration GUI tool and XML-based configuration files are
provided
4.3. Development Environment
The following technologies have been selected to support the project:
4.3.1. Tomcat
Tomcat is an open source implementation of Java Servlets and JavaServer
Pages, which conforms to the Servlet 2.3 and JSP 1.2 specifications. It’s a
container that stores the .jsp files extensions and java .class files, allowing a
web application to execute web pages dynamically [14].
The version used for this project is 4.0.1. The Tomcat container can be
configured using the server.xml configuration file.
Tomcat is started using the startup.bat file located under the bin directory.
Once it is executed, a new window in the web browser should be started to
check whether the tomcat home page is accessible or not. The following
location must be typed to check that the service is running:
http://localhost:8080/index.html
If the Tomcat welcome page is displayed, the container has been
successfully installed and configured 1. The Opera browser has been used
together with Tomcat.
1 Several problems have been experienced when using Internet Explorer version 6.0.
28
4.3.2. MySQL
MySQL is an SQL database and it is freely available at
http://www.mysql.com. The version used during this project is 3.23.49.
The installation process was straightforward. Once the .zip file has been
downloaded from the Internet, the following steps were followed:
?? Unzip the file to a directory folder, in this case mysql.
?? A daemon must be started before using the database. This is achieved
by typing mysqld –standalone. Multiple databases can be run on the
same machine.
4.3.3. OPENJMS
OpenJMS is an open source implementation of Sun Microsystem’s Java
Message Service specification. Once downloaded, the OpenJMS is located
under
c:\openjms\openjms-0.7.2
This directory is referred as OPENJMS_HOME
4.3.3.1. OpenJMS System Requirements
Operating system Windows 98/NT/2000, Linux, Mac OSX
Java Virtual Machine (JVM) JDK 1.2 or later
Table 4.1 OpenJMS system requirements
4.3.3.2. Environment Variables
OPENJMS_HOME Path of the OpenJMS installation directory
Table 4.2 OpenJMS environment variables
29
OpenJMS uses a database called JDBM to store the persistent messages
whenever a consumer is not active.
4.3.3.3. Starting the Server
The OpenJMS server can be started using the following command
c:\OPENJMS_HOME\bin startjms.bat –config ../config/rmi_jms.xml
The following information should appear on the screen if the server is
started with no errors:
OpenJMS 0.7.2 (build 10) Exolab Inc. (C) 1999-2002. All rights reserved. www.openjms.org 10:50:34.341 INFO [main] - Instantiated the RmiRegistryService service on port 1099 10:50:34.351 INFO [main] - Embedded RMI Registry running on port 1099 10:50:34.351 INFO [main] - Creating the RMI-based JMS Server 10:50:34.932 INFO [main] - Registered the service JndiServer with the registry. 10:50:34.932 INFO [main] - Started service [RmiRegistryService] 10:50:34.932 INFO [main] - Started service [ThreadPoolManager] 10:50:34.932 INFO [main] - Started service [EventManagerThread] 10:50:34.932 INFO [main] - Removed expired messages. 10:50:34.942 INFO [main] - Started service [DatabaseService] 10:50:34.942 INFO [main] - Started service [Scheduler] 10:50:34.942 INFO [main] - Started service [LeaseManagerReaper] 10:50:34.952 INFO [main] - Started service [GCCollectionService] 10:50:35.283 INFO [main] - Started service [MessageManager] 10:50:35.293 INFO [main] - JMS Server is bound to //localhost:1099/OpenJMSServer 10:50:35.333 INFO [main] - JMS Admin Server is bound to //localhost:1099/JmsAdminServer
The DOS windows with the server status running must be kept open, to
maintain the OpenJMS server running. If the server window is closed
abruptly and the JDBM database for persistent storage is used, the server
will not start again, raising an error:
18:04:22.010 INFO [main] - Creating JNDI Server org.exolab.jms.jndi.ipc.IpcJndiServer 18:04:22.020 INFO [main] - Started IPC JNDI Server on port 3035 18:04:22.070 INFO [main] - Opening database: openjms.db org.exolab.jms.server.FailedToCreateServerException: JmsServer constructor failure javax.jms.JMSException: Cannot create persistency layer: Cannot acquire lock to the database openjms at org.exolab.jms.server.JmsServer.<init>(JmsServer.java:261)
30
The solution to this problem is to delete the database .lock file located
under:
c:\OPENJMS_HOME\bin.
4.3.3.4. Server instantiation
An investigation of the commands required to compile and execute
components was conducted. The JMS specification leaves freedom to the
vendors to implement features the way they think it is appropriate, and
discovering how OpenJMS dealt with them was very important.
For example, the OpenJMS distribution provides an Admin GUI Tool (Figure
4.1) to facilitate the management of destinations and consumers. The tool
can be accessed using the following command
c:\OPENJMS_HOME\bin admin.bat –config ../config/rmi_jms.xml
Figure 4.1 OpenJMS GUI Tool
31
The tool allows the system administrator to:
?? Create and delete queues and topics
?? Add and remove durable consumers for a topic
?? Deregister active consumer
?? Monitor number of messages for a queue
?? Monitor number of messages per topic consumer
?? Start and stop the OpenJMS server
?? Purge persistent messages
OpenJMS includes examples of consumers and publishers that are
executed using the follow steps:
1. The examples are located under the directory
c:\OPENJMS_HOME\src\examples\openjms\examples\client\console\
This is the standard location where the .java files should be located.
2. Once the java files have been created or modified, the following path
contains the batch file to compile them:
c:\OPENJMS_HOME\
3. OpenJMS uses a batch file to compile the java files, and it is executed
using the command
build examples
4. Running the examples
C:\OPENJMS_HOME\bin\examples.bat client.console.<filename>
32
Example
The following example uses a SimpleConsumer.java file to send
messages using OpenJMS. Most of the applications running on the
same machine require two DOS windows open, one for the consumer
and the other for the publisher. The following command is executed to
start the consumer listening to messages sent to the OpenJMS server:
C:\OPENJMS_HOME\bin runconsumer –topic topic1 –count 10
In the second window, a publisher is executed to send 10 messages to
a topic topic1.
C:\OPENJMS_HOME\bin runpublisher –topic topic1 –count 10
The consumer will start receiving messages. The following window is
displayed:
Figure 4.2 OpenJMS example
4.3.4. J2ME Wireless Toolkit
The J2ME Wireless Toolkit supports the development of Java applications
that run on devices such as cellular phones, two-way pagers, and palmtops.
33
The J2ME Wireless Toolkit supports a number of ways to develop MIDP
applications. The application development can be performed running the
tools from the command line, or by relying on development environments
that automate a large part of this process. The KToolBar, included with the
J2ME Wireless Toolkit and shown below, is a minimal development
environment with a GUI for compiling, packaging, and executing MIDP
applications.
4.3.5. Simplewire Software Development Kit
The Simplewire SMS Software Development Kit is a Java implementation
used to send SMS messages to mobile devices. It can be used in all Java
Runtime Environments including Windows, Linux, Solaris, etc. The Java
SDK connects an application to, and works in conjunction with, the
Simplewire Wireless Messaging Network. This network sends the SMS
message to the mobile device [15].
34
DESIGN AND IMPLEMENTATION
MyNews Application
35
Chapter 5
MyNews DESIGN
MyNews has been designed and implemented to explore the current
Wireless Java Messaging Service (JMS) middleware technology and to
identify key issues when implementing a distributed service over wireless
devices. Alternative solutions have been evaluated and considered during
the design to address shortcomings of the Wireless JMS middleware
technology. The application has implemented a JMS service using the most
commonly used publish/subscribe model. This model allows many
publishers to send messages to a topic and many subscribers to consume
the messages.
The application offers different topics, such as:
?? Object Oriented analysis
?? Java Message Service
?? Sports
?? Java 2 Micro Edition (J2ME)
?? Travel air fare
MyNews is an application developed using JMS as a middleware between
mobile devices and enterprise applications. A user subscribes to topics
available in MyNews and receives information whenever a topic is updated,
either using e -mail or Short Message Service (SMS).
The subscribers are software components receiving messages from the
JMS server when messages become available, and sending them to mobile
devices 2.
Design patterns have been identified and used during the design and
implementation of MyNews application . Alternative system architectures
have also been considered.
2 A mobile component has been implemented to send messages to a server using JMS as a middleware.
36
5.1. Design Patterns
One of the ways of reducing the difficulty of designing wireless JMS
applications is to employ design patterns. A design pattern can be defined
as a general solution to a frequently occurring architecture/design problem
in a context [25].
Design patterns are useful because they:
?? Help solve “real world” problems
?? Show more than one solution
?? Reuse wisdom and knowledge of experienced developers
5.1.1. Observer (Publish/Subscribe) Design Pattern
The Observer pattern defines a one -to-many dependency between a
subject object (topic) and any number of observer objects (subscribers) so
that when the subject object changes state, all its observer objects are
notified and updated automatically [25].
The observer design pattern can be used when a change to one object
requires changing others, but there is no information about how many
objects need to be changed.
This design pattern has been used when developing the wireless JMS
infrastructure: a publisher can post a new message under a particular topic
and all the observers (subscribers to that topic) are notified when a new
message is available. The publishers notify the observers without knowing
who they are, therefore keeping their relationship decoupled.
5.1.2. Request Reply Design Pattern
The request reply pattern is similar to the to Remote Procedure Call (RPC).
A sender sends a message and waits until it gets an acknowledgment back.
In this case the communication is synchronous; the sender does not
37
perform any action until the client acknowledges or discards the message
[25].
It is not very appropriate to use this design pattern on the mobile side
because the screen phone must always be responsive to the user. The
mobile user must be able to perform operations in the device without being
blocked waiting for an acknowledgement.
5.1.3. Fire and Forget Design Pattern
The fire and forget design pattern differs from the request replay pattern in
that a component does not need to wait for acknowledgement before
proceeding to execute other operations. In this case the communication is
asynchronous and the client receives no acknowledgement.
In high performance JMS servers, this design pattern is clearly the most
efficient. All the message processing is delegated to the server and the
components publishing the messages are kept very light.
This design pattern has not been used during this project, as the publishing
of a message requires a single operation.
5.2. System Architecture
Figure 5.1 shows the system architecture developed during the design of
MyNews application. The architecture is composed of different parts:
?? The JMS server is embedded into Tomcat. Tomcat resolves the
request and a servlet communicates with the JMS server
?? A Java component has been implemented to consume messages
from the JMS server and sending them using Short Message
Service (SMS)
?? A Java component is implemented to retrieve messages from the
JMS server and displaying them on a windows console
38
Figure 5.1 System architecture
JMS Server
Java Component Http Tomcat
SMS
MySQL (project)
MySQL (OpenJMS)
Java Component
JDBC JDBC
Web Interface
39
?? A database called project has been created to store the subscriber
information.
?? A database called openjms has been created and it is used to store
the persistent messages.
?? A mobile application has been developed, allowing a user to publish
messages to a topic.
?? A web interface has been implemented to allow a user to publish
messages to a topic.
5.3. Architecture Evaluation
When a JMS server is used as a basis of a distributed system, the
components using this service delegate the work of sending messages to
the Message Oriented Middleware. Therefore, a server must be available at
all times, and all possible publishers and consumers of messages that could
potentially interact at any time in the future must connect to the same logical
server [17]. This infrastructure is applicable when few subscribers and
publishers are intera cting with the JMS server.
A more scalable infrastructure should be implemented in cases when a high
level of reliability and throughput is needed. A single JMS server cannot
fulfill all these requirements. It is also important to ensure that whenever the
JMS server crashes, the service will still be running with the minimum of
delay. Combining multiple computers can be used to create the external
appearance of one highly capable central server. This is called clustering.
The main reasons for using a cluster instead of a single server are:
?? Increase capacity
When multiple computers are used as a single logical JMS server,
spreading all the traffic between these machines can increase the
capacity and load balancing in terms of messages per second,
simultaneous connections and active subscriptions.
40
?? High availability
Using clustering for JMS applications decreases the possibility of a
failure of the system. If one of the servers crashes, the mirror (a
replicated computer in the cluster with the same information) can
take over the job of the first one without disrupting the normal
operations of the system. A publisher or a consumer should not
notice any change because everything is operating as a single
logical unit.
5.3.1. Clustering in the Publish/Subscribe domain
Clustering can be implemented in any of the JMS domains (the
publish/subscribe and point-to-point domain). Only clustering in the
publish/subscribe domain has been addressed during the research
undertaken because its wide usage.
In the Publish/Subscribe domain, a copy of every message in a topic is sent
to every consumer that is interested in that topic.
Clustering in the Publish/Subscribe domain is achieved at the connection
level, because connections are a limited resource and should be
administered efficiently. One of the advantages of clustering is that a
consumer or subscriber connects to the server that has the least traffic
(Figure 5.2).
Figure 5.2 Clustering in Publish/Subscribe domain
Message
JMS 1 JMS 2 JMS N
Subscriber 1..n
Subscriber 1..n
Subscriber 1..n
Node 1
Node 2
Node N
Publisher
Message
41
Figure 5.2 shows that every message can be replicated to each cluster
node and each node can forward the message to each subscriber that it
knows.
A problem arises when durable subscribers are maintained in the JMS
server (messages for durable subscribers are stored in a persistent
database until subscribers become active and consume them). Full
replication and Topic home are approaches that have been identified to
address the management of durable subscribers.
Full Replication
In clustering with full replication, the message is sent to every computer in
the cluster. Redundancy is a big advantage, because it ensures that the
message is stored safely when at least one single computer is running.
Figure 5.3 shows this architecture.
Figure 5.3 Full replication clustering
Disadvantages of this architecture are:
?? Poor storage scalability
If one of the computers in the cluster has less storage capacity than
the others, the overall capacity of the cluster is limited to the
M1
M1
M1
42
capacity of this computer, since the message is replicated to every
node in the cluster. Adding nodes to the cluster does not increase
the total storage capacity.
?? Traffic between machines
Replicating messages between machines generates a lot of traffic
and increases the bandwidth consumption. Propagating each
message acknowledgment to every computer generates a high
amount of traffic as well.
Topic Home
This approach differs from full replication in that each message is replicated
to every machine but only the machine that is the topic home stores the
message (Figure 5.4).
Figures 5.4. Topic home clustering
M
M1
Topic Home
Topic Home Connect to home
Publisher
43
The advantage of this approach is that everything is coordinated from a
central point, which is more difficult to achieve with full replication. On the
other hand, there is still a lot of bandwidth consumed between machines.
44
Chapter 6
MyNews IMPLEMENTATION and TESTING
6.1. Implemented components
The derived MyNews system architecture has been implemented using the
Observer Pattern described in Chapter 4 (The applica tion is located under
http://localhost:8080/project/jsp/form.jsp ). The implementation of MyNews application
incorporated the development of:
1. The MySQL database has been used for two purposes. A database
called project has been created, containing a table called user. This
table is used to store the information when a consumer subscribes to
a topic. Table 6.1 shows the table structure.
Field Type
Name Char(30)
Lastname Char(30)
Email Char(30)
Mobile Char(20)
Username Char(30)
Password Char(30)
Emailyesno Char(1)
Table 6.1. Description of table User
The mobile number is used to send SMS messages to the user.
Additional information is used to check the authenticity of the
connected consumer and to send notifications via e-mail. Only SMS
messages have been implemented.
45
A JavaServer Page (JSP) file and DBServlet.java servlet have been
designed and implemented to populate the user table. Figure 6.1
shows a snapshot of the created input form.
Figure 6.1User registration.
http://localhost:8080/project/jsp/form.jsp
The Form.jsp file uses a javaBean to validate the data input in the
form. If the data is correct (No duplicate username, valid mobile
number, etc.) a servlet called DBServlet.java is invoked. The Servlet
connects to the database and inserts the information into the user’s
table [24].
MySQL has also been used as a persistent storage.
46
A research from different resources suggested that MySQL database
was stable and the performance was acceptable [25].
OpenJMS comes with different configuration files for persistent
storage. The server can be configured with Oracle, MySQL,
Hypersonic SQL, etc.
Configuration of OpenJMS with MySQL has been achieved with the
following steps:
1. The rmi_jms.xml configuration file located under the
OPENJMS_HOME\config directory must be modified and the
following lines added:
<DatabaseConfiguration>
<RdbmsDatabaseConfiguration
driver="org.gjt.mm.mysql.Driver"
url="jdbc:mysql://localhost/openjms"
user=""
password=""
retries="5"
timeout ="2000" />
</DatabaseConfiguration>
2. The url specifies that a database named openjms must be
created to store the message information (message body,
destination, priority, time to live, etc.). OpenJMS comes with
scripts for different databases located under the
OPENJMS_HOME\config directory. The create_mysql.sql file
has been used to create the tables.
2. The user accesses the OpenJMS application by entering the URL in
the web browser. Tomcat resolves the URL and redirects it to the
corresponding servlet (DBServlet.java), which executes and returns a
response back to the user. Tomcat has been used to serve both
dynamic and static web pages therefore functioning as a typical web
server in addition to a servlet and a JSP container.
47
The sequence of events is illustrated in Figure 6.2.
48
Browser Tomcat Container
SimplePublisher.html ServletSimplePublisher.class JND
I OpenJMS Server
Get SimplePublisher.html Retrieve
Enter topic name
Enter message
Enter airfare value
Enter continent
Enter oneway/return
Submit form Invoke
Connect
Get connection factory
Get connection
Create session
Create topic publisher
Publish Messages
Close Connection
Generate response
Figure 6.2 JMS sequence diagramhttp://www.exolab.org
49
3. A MIDLet (component running on a mobile device) has been
developed using the J2ME wireless toolkit. The J2ME provides a
class to connect to external applications (databases, application
servers, etc.). The component sends an HTTP request to a servlet
stored in the Tomcat container and the servlet connects to the JMS
server.
The component allows a user to publish a message to a specific topic.
The topic must exist in the JMS server so the message can be
published.
The developed MIDLet component creates a Java
ByteArrayOutputStream to send the message, and the request is sent
to the servlet. The servlet decodes the stream and transforms it to a
string, which is published to a topic in the JMS server.
4. A web page allowing to publish messages has been developed
(Figure 6.4). A publisher can use this web interface to send
messages to topics in the JMS server. A drop down menu has been
provided to allow the publisher to select the topic from the available
topics.
Figure 6.4 JMS publishing web interface
50
5. A Java component consuming messages and sending them using
Short Message Service (SMS) has been developed. This component
performs the following tasks:
?? The component receives parameters such as the topic name and
the user name. A message selector is an optional parameter that
can also be specified. Message selector is explained in section 6.3.
The component connects to the JMS server and retrieves all the
messages for a particular user and topic a name.
?? A connection to the project database has been realized using Java
Database Connectivity (JDBC). A connection is needed to retrieve
the mobile number, using the user name as a filter for the select
statement.
?? Once all the information is retrieved from the database, the
Simplewire software development kit (SDK) is used to send the
message to the mobile device. The message takes an average of
20 seconds to be received on the mobile.
6. A Java component consuming messages and displaying them on
the windows console has been implemented.
6.2. Testing of the wireless JMS infrastructure
The implementation and testing of the wireless JMS infrastructure showed
the following results:
?? A test has been conducted to analyse the performance of the system
when publishing 30.000 persistent messages to a topic in the JMS
server. Persistent messages are stored in a database until a consumer
becomes active 3.
3 The OpenJMS implementation used during this project has a bug that does not allow a consumer to subscribe to multiple topics
51
The results showed that it takes approximately 15 minutes to publish the
messages to the JMS server. The following reasons have been identified
for the slow publishing of the messages.
1. Java is known for being slow in comparison with other languages
such as C++. The Java Virtual Machine needs a high amount of
resources to administer processes and free memory (using the
garbage collector).
2. JMS servers that handle high amount of traffic are usually equipped
with enough memory and hard disk capacity. Unfortunately, the
computer used for running the tests had only 128 Megabytes of
RAM and only 10 Megabytes of free disk space, which was not
enough. The operating system needed enough free disk space to
perform swapping operations.
3. An overhead has been identified when publishing persistent
messages to the JMS server. Every message must be stored in a
database.
OpenJMS comes with a persistent storage call JDBM. The research
conducted indicated that JDBM is a provisional storage to be used
only for installation and testing of the OpenJMS server, but it should
not be used for commercial purposes when high amount of
messages are published and consumed in the JMS server. Other
persistent storages should be used instead of JDBM [8].
?? The infrastructure has been migrated to a laptop with 320 Megabytes of
RAM, 30 Gigabytes hard drive, and Pentium III processor. This
machine has proven to be a better platform for running a JMS server,
providing more RAM memory as well as hard disk for swapping. The
Java Virtual Machine is still the same.
The results showed that publishing the same 30.000 messages took
approximately 6 minutes.
52
?? The Short Message Service (SMS) has limitations. Only a message
with a maximum of 160 characters can be sent to a mobile device using
this service, and applications using this service might require delivery of
long messages.
?? The applications running on mobile devices (MIDLets) have to be
‘compressed’ to fit the very limited memory of the devices. Designing
and implementing comp lex applications on mobile devices is a problem.
6.3. Additional Implementation: Message Selector
An additional component has been implemented to allow filtering of
messages in the JMS server, using message selectors.
Message selectors are strings that are used by JMS clients for filtering the
messages delivered to them. They use the SQL-92 syntax and are
evaluated using JMS properties and standard headers and [18]. Message
selectors are explain in detail in Appendix B.
The topic airfare has been used to specify a message selector. A person
using the web interface can publish a message to this topic specifying the
following properties:
?? Travel: a user can choose whether the airfare ticket is one-way or
return.
?? Destination: this property represents the airfare destination.
?? Value: ticket value.
Once the sender publishes the message, these properties are mapped with
the values specified.
An additional component has been implemented to consume messages
from the JMS server. This example illustrates the syntax of the selector:
53
Examples.bat client.console.MyConsumer –name Andres –topic airfair –selector “value < 2000 AND Destination = ‘America’ AND travel =
‘return’”
In this case a component called MyConsumer is executed with a selector
specifying that the OpenJMS server should only deliver messages that
fulfills the criteria specified in the selector. The mapping of value -properties
and the comparison is performed on the JMS server side, leaving the
component to perform a minimum operation.
54
Chapter 7
CONCLUSIONS
MyNews has been designed and implemented to explore the current
Wireless Java Messaging Service (JMS) middleware technology and to
identify key issues when implementing a distributed service over wireless
devices. Advantages of using a messaging system for communication
instead of making direct connections have been identified.
The Java Message Service (JMS) provides a standard messaging service
for Enterprise applications. JMS acts as a middleware for routing messages
among application components and processes in a distributed application.
JMS queues messages and can deliver them asynchronously: messaging
need not take place in real time (messages can be sent and consumed at
different times).
Messaging systems also provide reliability. JMS can optionally save a
message to a persistent storage, although there is a trade -off between
reliability and performance. The messaging system runs faster if messages
are not persistent and memory is available for swapping, but the application
must tolerate lost messages in the event of a server crash. Messaging
systems also enable clients to disconnect and reconnect to the server
without losing information. JMS can be configured to save messages while
the client is disconnected and deliver them once the client has reconnected.
Unlike method calls on a single object, JMS allows sending a single
message to many recipients.
Available toolkits and useful examples have been identified during the
development of MyNews. MySQL, JDBM, OpenJMS, Tomcat and Java 2
Micro Edition Toolkit are open source technologies freely available for
downloading. These technologies have been configured to implement a
basic wireless JMS infrastructure.
55
Additional toolkits and libraries have been used during the project. The
Simplewire Software Development Kit (SDK) provides an easy way to send
SMS messages using Java.
Guidelines on hardware and software requirements have been identified.
Running a JMS server on a machine requires enough disk space available
to perform swapping operations, particularly when high amount of traffic in
the JMS server is required.
Alternative solutions, design patterns and architectures have been
evaluated and considered during the design of MyNews to address
shortcomings of the Wireless JMS middleware technology. The application
has implemented a JMS service using the most commonly used
publish/subscribe model. This model allows many publishers to send
messages to a topic and many subscribers to consume the messages.
The observer, request reply, and fire-and-forget design patterns have been
identified and evaluated during the implementation of MyNews application.
The observer design pattern has been utilised as it defines a one-to-many
dependency between a subject object (topic) and any number of observe r
objects (subscribers). For instance, subscribers should be notified when
new messages are published to a topic.
JMS provides a powerful messaging facility with support for transactions,
persistence, durable subscribers, and message selection and sorting. While
these are important features of JMS, they do affect the messaging system's
performance. Selecting the correct acknowledgment mode, a reliable
persistent storage (Oracle, MySQL, etc), or using non-persistent messages
where appropriate can greatly increase the throughput of a JMS application.
Alternative system architectures have been considered when designing
wireless JMS infrastructures. Clustering has been identified to increase the
capacity of a system and to decrease the possibility of a failure of the
system.
Clustering in the Publish/Subscribe domain has been achieved at the
connection level, because connections are a limited resource and should be
56
administered efficiently. Advantages and disadvantages of Topic home and
full replication approaches have been identified when durable subscribers
are maintained in the JMS server.
In full replication, the message is sent to every computer in the cluster.
Redundancy is the biggest advantage, as the message is replicated.
In the topic home approach, each message is replicated to every machine
but the machine that is the topic home stores the message. This approach
gives the advantages of a central coordination point, which is more difficult
to achieve with full replication.
JMS message selectors are a convenient and powerful means to filter
messages from a queue or topic, but care must be taken to ensure that
selection does not deter overall system performance.
Every JMS message sent to a destination must be compared against the
consumers' message selectors. Message selectors that only consider
message header fields are the fastest. A selector that uses the message
properties is slower, and if a selector examines the message body, it is
even slower.
JMS supports both synchronous and asynchronous message consumers. It
is recommended that, where possible, asynchronous message consumers
be used. Asynchronous message consumers provide better resource usage
because threads are not blocked waiting for messages.
Applications running on mobile devices (MIDLets) have to be ‘compressed’
to fit the very limited memory of the devices. Designing and implementing
complex applications on mobile devices is still a problem.
Future work
Enterprise messaging systems, often known as message-oriented
middleware (MOM), provide a mechanism for integrating applications in a
loosely coupled, flexible manner. They provide asynchronous delivery of
data between applications on a store and forward basis; that is, the
57
applications do not communicate directly with each other, but instead
communicate with the MOM, which acts as an intermediary.
Future work will involve using the existing implementation of MyNews to
integrate it with other technologies, namely Enterprise JavaBeans.
The EJB specification 2.0 defines an architectu re for the development and
deployment of transactional, distributed object applications-based, server-
side software components. Organisations can build their own components
or purchase components from third-party vendors.
The message-driven bean is an EJB type introduced in the release 2.0 of
the specification. This bean type was introduced to specifically address the
prior lack or integration with JMS that EJB 1.1 presented. The message -
driven bean type provides a mechanism implemented through the EJB
container, for dealing with asynchronous message delivery to an EJB.
The idea of integrating JMS with EJB message -driven bean is illustrated in
Figure 7.1
Figure 7.1 Integration Java Message Service and Enterprise JavaBeans
The components developed to consume messages during this project will
be replaced with the message-driven beans. Having an enterprise bean
instead of a java component decreases the complexity of developing
enterprise applications. The EJB container will handle the security,
transactions and persistence of business objects and the beans will only
deal with business logic. The new infrastructure will be evaluated and
compared with the existing implementation.
Publisher
JMS Server
Destination
EJB Container
Message-driven Bean
58
REFERENCES
[1] SUN (1999). Java 2 Platform, Enterprise Edition (J2 EE). Retrieved
February 1, 2002, from the World Wide Web:
http://java.sun.com/j2ee/overview.html
[2] Software Engineering Institute. (2000, September 22). Remote
Procedure Call. Retrieved January 13, 2002, from the World Wide Web:
http://www.sei.com.au
[3] Sun Microsystems. (1999, December 17) Java Message Service API.
Retrieved January 15, 2002, from the World Wide Web:
http://java.sun.com/products/jms/tutorial/
[4] Hawik, K (1999). Distributed and high -performance computing . Retrieved
February 13, 2002, from the World Wide Web:
http://www.dhpc.adelaide.edu.au
[5] Gopalan, S.R. Java Message Service By Gopolan Suresh Raj. Web Cornucopia (Sep 24,2001). Retrieved January 15, 2002, from the World Wide Web: http://www.execpc.com/~gopalan/jms/jms.html
[6] JCP (2001). Java Community Process. Retrieved February 2,2002, from
the World Wide Web:
http://jcp.org
[7] SUN (1999, March 30). Java 2 Platform, Micro Edition (J2ME). Retrieved
February 3, 2002, from the World Wide Web:
http://java.sun.com/j2me/?frontpage-javaplatform
[8] Exolab group (1999). OpenJMS. Retrieved January 30, 2002, from the
World Wide Web:
http://www.exolab.org
59
[9] BEA systems (2002). BEA WebLogic Server. Retrieved February 2002,
from the World Wide Web:
http://www.bea.com/products/weblogic/server/index.shtml
[10] Fiorano. (2001) FioranoMQ Server. Retrieved March 5, 2002, from the
World Wide Web:
http://www.fiorano.com/
[11] MQSeries JMS (2002). MQSeries. Retrieved January 3, 2002, from the
World Wide Web:
http://www-3.ibm.com/software/ts/mqseries/api/mqjava.html
[12] SoniMQ 4.0 (2002). SoniMQ. Retrieved January 22, 2002, from the
World Wide Web:
http://www.sonicsoftware.com/releases/2002/012202.htm
[13] JMQ 1.1 (2002). Java Message Queue 1.1. Retrieved May 2002, from
the World Wide Web:
http://wwws.sun.com/software/Developer-products/iplanet/jmq.html
[14] Jakarta Project (2002). Tomcat. Retrieved Februay 5, 2002, from the
World Wide Web:
http://jakarta.apache.org/tomcat/index.html
[15] Simplewire (2002). Simplewire Software Development Kit, Retrieved
January 5, 2002, from the World Wide Web:
http://www.simplewire.com
[16] SUN. (2001, July 30) Implementing design patterns using the Java
Message Service (JMS) API. Retrieved April 2002 from the World Wide
Web:
http://java.sun.com/javaone/javaone2001/pdfs/2254.pdf
[17] Javaworld (2001). J2EE clustering. Retrieved February 2002, from the
World Wide Web:
http://www.javaworld.com/javaworld/jw-02-2001/jw-0223-extremescale.html
60
[18] Giotta P, Grant S.,Kovacs M., Maffeis S., Morrison S., R. Suresh, K.
Moidoo. Professional JMS Programming. Wrox publishing.
[19] Distributed technologies (1998). 3 and n-Tier Architectures. Retrieved
April 13 2002 from the World Wide Web:
http://www.corba.ch/e/3tier.html
[20] TopXML.com (2002). Client-Side Presentation Logic. Retrieved
January 12 2002, from the World Wide Web:
http://www.topxml.com/java/articles/clientside/default.asp
[21] InformationWeek (May 28, 2001). Integration powered. Retrieved
March 15, 2002, from the World Wide Web:
http://www.informationweek.com/839/integration.htm
[22] Sun (2002). JMS Specification. Retrieved January 4, 2002, from the
World Wide Web:
http://java.sun.com/products/jms/docs.html
[23] Midlet.org (2002). Midlets. Retrieved February 3, 2002, from the World
Wide Web:
http://www.midlet.org
[24] Hall, M. Core servlets and JavaServer pages. Prentice Hall publishing.
2001.
[25] Gamma, E. Helm, R. Johnson, R. Vlissides, J (1995). Design Patterns.
Elements of Reusable Object-Oriented Software. Addison Wesley
publishing.
[25] MySQL (2002). MySQL. Retrieved January 4, 2002, from the World
Wide Web:
http://www.mysql.com
[26] Software Engineering Institute. (2000, September 22). Message-
Oriented Middleware. Retrieved May 2, 2002 , from the World Wide Web:
http://www.sei.com.au
61
Appendix A
MIDP REQUIREMENTS MIDP Hardware requirements
MIDP is intended for small devices with limited memory, CPU, and display
capabilities. The minimum hardware requirements are described in the
following sections.
Memory
The MIDP specification requires at least 128 KB of RAM available to store
the MIDP implementation itself, over and above whatever is needed by
CLDC. In addition to this, there must be at least 32 KB available for the
Java heap. In practice, a 32 KB heap is very limiting. As well as the RAM
requirement, MIDP devices must also supply at least 8 KB of nonvolatile
memory to be used as persistent storage so that MIDlets (see next section)
can save information in such a way that it is not lost when the device is
switched off. The content of this storage is not guaranteed to be preserved
over battery changes, however, and there is a general expectation that the
device also provides some way (such as the PDA "hot sync" mechanism) to
back up its content to a more permanent location.
Display
MIDP devices are characterized by small displays. The specification
requires that the screen should be at least 96 pixels wide and 54 pixels high
and that each pixel be (approximately) square. The screen must support at
least two colors, and many cell phones are capable of no more than this.
PDAs typically have screens with 160 pixels in each direction and support
as many as 65,536 different colors.
Input Device
There are several different types of input device that might be found on a
MIDP platform. The more sophisticated devices, like the RIM wireless
62
handheld, have a complete alphanumeric keyboard. Similarly, PalmOS-
based handhelds allow the user to "write" on a special area of the screen
using a form of shorthand known as Graffiti. They also provide a simulated
onscreen keyboard for users who prefer a more traditional approach.
The minimum assumption made by the MIDP specification is that the device
has the equivalent of a keypad that allows the user to type the numbers 0
through 9, together with the equivalent of arrow keys and a select button.
Connectivity
Mobile information devices have some kind of network access, whether it's
the built-in wireless connection in a cell phone or pager, or a separate
modem attached to a PDA. MIDP does not assume that devices are
permanently attached to a network or that the network directly supports
TCP/IP. It does, however, require that the device vendor provide at least
support for HTTP 1.1 protocol, either directly or over an Internet protocol
stack (as would be the case for a Palm handheld connected to a modem) or
by bridging a wireless connection to the Internet via a WAP gateway. This
provision allows developers to write network-aware MIDlets that work
equally well (other than performance differences due to differing network
bandwidth) across all supported platforms.
MIDP Software Requirements
Networking
On some platforms, such as PalmOS, a socket-level API is available, over
which the mandatory MIDP HTTP support can be implemented. In the case
of devices that do not offer such a convenient interface, including those that
do not have direct connectivity to an IP -based network, the vendor is
required to provide means for HTTP to be bridged from the device's own
network to the Internet.
63
Persistent Storage The platform must provide some form of persistent storage that does not
lose its state when the device is switched off (that is, when it is in its
minimum power mo de, but not necessarily when it has no power at all).
MIDP provides record-level access to this storage and therefore requires
that the host software supply some kind of programming interface to its
persistent storage mechanism.
64
Appendix B
MESSAGE SELECTOR Message selectors are strings that are used by JMS clients for filtering the
messages delivered to them. They use the SQL-92 syntax and are
evaluated using JMS properties and standard headers and [18].
Application defined properties must obey the following rules:
?? Property values can be boolean, byte, short, int, long, float, double, and
string. The following name prefixes are reserved: JMSX, JMS_.
?? Message selectors cannot reference message body values.
?? A message selector matches a message when the selector evaluates to
true when the message's header field and property values are
substituted for their corresponding identifiers in the selector.
?? The order of evaluation of a message selector is from left to right within
the precedence level. Parenthesis can be used to change this order. A
selector can contain:
Operators
Operators are based on the SQL-92 SELECT statement syntax (Table
B.1). Element Syntax and Specifications
Logical NOT, AND, OR
Comparison =, >, >=, <, <=, <>
Arithmetic Unary + or –
* /
addition + or substraction -
Arithmetic range between two expressions Expr1 BETWEEN expr2 AND expr 3 Expr1 NOT BETWEEN expr4 AND expr5
Table B.1 Selector operators
65
Literals
Element Syntax and Specifications String literals Zero or more characters enclosed in single quote
Exact numeric literals Numeric long integer values, signed and unsigned
Approximate numeric literals Numeric double values in scientific notation of
numeric double values
Boolean literals True or false
Table B.2. Literal selectors
Identifiers
An identifier is an unlimited length sequence of Java letters and Java
digits, the first of which must be a Java letter. A letter is any character
for which the method Character.isJavaLetter returns true. This includes
'_' and '$'. A letter or digit is any character for which the method
Character.isJavaLetterOrDigit returns true. The following rules applie to
identifiers.
??Identifiers cannot be the names NULL, TRUE, or FALSE.
??Identifiers cannot be NOT, AND, OR, BETWEEN, LIKE, IN, and IS.
??Identifiers are either header field references or property references.
??Identifiers are case sensitive.
??Message header field references are restricted to JMSDeliveryMode,
JMSPriority, JMSMessageID, JMSTimestamp, JMSCorrelationID
and JMSType. JMSMessageID, JMSTimestamp, JMSCorrelationID
and JMSType values may be null and if so are treated as a NULL
value.
??Any name beginning with 'JMSX' is a JMS defined property name.
??Any name beginning with 'JMS_' is a provider-specific property name.
66
??Any name that does not begin with 'JMS' is an application -specific
property name. If a property is referenced that does not exist in a
message its value is NULL. If it does exist, its value is the
corresponding property value.
Expressions
A selector is a conditional expression; a selector that evaluates to true
matches the condition; a selector that evaluates to false or unknown
does not match the condition.
??Standard bracketing () for ordering expression evaluation is
supported.
??Logical operators in precedence order: NOT, AND, OR.
??Comparison operators: =, >, >=, <, <=, <> (not equal).
??Only like type values can be compared. One exception to this rule is
that it is valid to compare exact numeric values and approximate
numeric values (the type conversion required is defined by the rules
of Java numeric promotion). If the comparison of non -like types is
attempted, the selector is always false.
??String and Boolean comparison is restricted to = and <>. Two strings
are equal if and only if they contain the same sequence of
characters.
??If any of the expressions of a BETWEEN operator are NULL the value
of the expression is false.
??If any of the expressions of a NOT BETWEEN operator are NULL the
value of the expression is true.
??SQL treats a NULL value as an unknown value.
67
??Comparison or arithmetic with an unknown value always yields an
unknown value.
??The IS NULL and IS NOT NULL operators convert an unknown value
into the respective TRUE and FALSE values.
6.3.1. Examples
Expression Equivalent to Age BETWEEN 15 and 19 age < 15 OR age > 19
Country IN (' UK', 'US', 'France') is true for
'UK' and false for 'Peru'
(Country = ' UK') OR (Country = ' US') OR (Country = ' France')
Table B.3. Selector examples
The following message selector selects messages with a message type of
car and color of blue and weight greater than 2500 lbs:
"JMSType = 'car' AND color = 'blue' AND weight > 2500"
