Easy to Learn Java: Programming Articles, Examples and Tips

Start with Java in a few days with Java Lessons or Lectures


Code Examples

Java Tools

More Java Tools!

Java Forum

All Java Tips


Submit News
Search the site here...
Search the JavaFAQ.nu
1000 Java Tips ebook

1000 Java Tips - Click here for the high resolution copy!1000 Java Tips - Click here for the high resolution copy!

Java Screensaver, take it here

Free "1000 Java Tips" eBook is here! It is huge collection of big and small Java programming articles and tips. Please take your copy here.

Take your copy of free "Java Technology Screensaver"!.

Wireless messaging with JXTA

JavaFAQ Home » Java Mobile Technology Go to all tips in Java Mobile Technology

Bookmark and Share

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.

Integrating J2ME devices into messaging 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.

Architectural requirements for messaging

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 the message.

The Java-based messaging solution

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 middleware.

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 receivers.

Full text here

 Printer Friendly Page  Printer Friendly Page
 Send to a Friend  Send to a Friend

.. Bookmark and Share

Search here again if you need more info!
Custom Search

Home Code Examples Java Forum All Java Tips Books Submit News, Code... Search... Offshore Software Tech Doodling

RSS feed Java FAQ RSS feed Java FAQ News     

    RSS feed Java Forums RSS feed Java Forums

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest 1999-2006 by Java FAQs Daily Tips.

Interactive software released under GNU GPL, Code Credits, Privacy Policy