In this two-part series, Faheem Khan demonstrates how to use JXTA technology
to integrate thin J2ME clients into enterprise-scale messaging applications.
While working through this series, you will develop a set of classes that enable
you to integrate J2ME clients into JMS applications running on J2EE servers.
This article discusses the basic architecture of a typical messaging application
and introduces two application scenarios in which you would need to integrate
these clients. It also introduces JXTA and explains how to use the JXTA
framework to integrate thin clients into JMS applications.
Short messaging is fast becoming a significant source of income for cellular
network operators. And now, you can use messaging to integrate wireless devices
into enterprise applications. With wireless technologies such as J2ME, you can
combine the convenience of wireless messaging with wireless programming to let
software modules interact with enterprise application servers and exchange
messages. This way, your mobile devices can talk to the database servers,
provide updates of pending tasks, fetch new instructions, report to the boss,
and even perform transactions while on the move.
Consider a courier company that picks up packages from customer doorsteps. It
would be useful if the company could notify its field staff to pick up a package
while they were operating in a certain area. For this to happen, the company
would have to implement wireless messaging and equip its staff with mobile
devices capable of exchanging messages with the company's messaging network.
Access to the required information at the right time is critical in modern
business. Another simple wireless messaging application can be one that allows
your cell phone to log into your enterprise server during a meeting and
instantly get the required information. You might also use your cell phone to
update your company's enterprise server about any information you obtain during
a client visit.
A messaging solution's asynchronous communication mechanism is its most
important feature. It ensures that communicating parties don't have to be
exclusively committed to each other during communication. In other words,
messaging clients don't talk in real time.
Messaging is like sending or receiving letters or e-mails, in contrast to
face-to-face or telephonic conversations, which are inherently synchronous in
nature (they require real-time commitment). Browser-like communication is also
an example of synchronous communication. A browser sends a request to a Web
server and then waits to receive the response, unable to do anything else in the
meantime. And if the server is unavailable at the time of the request,
communication does not occur.
There are two types of messaging clients: senders and receivers. The sender
sends a message, and can then go do some other work. It doesn't have to wait for
the response from the message's receiver. The receiver retrieves the message at
its own convenience.
Messaging clients operate independently of each other. This means that the
messaging framework works even if the sender or the receiver is offline. This
inherent messaging flexibility offers a great advantage to networked
applications that rely on software components sitting across the Internet. Even
if some software components are too busy, offline, or temporarily unavailable,
the messaging framework still works.
There needs to be a certain level of reliability for messaging. For example,
you must make sure that messages don't get lost in transport and are not
duplicated at the receiving end. You must keep the messages stored somewhere
while clients are offline. The sender might also require the receiver to
acknowledge it received the message.
Therefore, there must be some middleware logic that provides these features
to messaging clients. The middleware logic is commonly referred to as
Message-Oriented Middleware (MOM). MOM implementations provide messaging support
to client applications and also perform administrative tasks (such as
maintaining a client list as well as queues for each client). The sender client
sends a message to MOM and the receiver client later contacts MOM to retrieve
JMS is an API that provides a messaging framework to Java applications.
Messaging clients can use the JMS API to communicate with the JMS middleware and
exchange messages with other JMS clients connected to the same JMS network.
Messaging solution providers implement the JMS API in their application
servers (for example, IBM WebSphere®), while application developers rely on the
JMS API to develop client applications. This avoids vendor lock-in. It also
means that every messaging application will comprise of a JMS-specific set of
classes (that are part of the JMS API implementation) and an
application-specific set of classes (that implement all application-specific
messaging logic). The JMS-specific set of client-side classes provides all the
messaging features, such as authoring messages and exchanging them with the JMS
In JMS terminology, the MOM implementation is referred to as the JMS
provider. All clients connect to the JMS provider, as Figure 1 shows. All
messaging between the clients is done through the provider. The provider
provides various administrative and resource management services; for example,
it stores messages from the senders until the receivers fetch their messages.
You can say the provider acts as a broker between the message senders and
6 comments | | Score: 0