Using Notification Servers in J2EE Applications

Abstract: For the past few years, the JavaMail API has been used to implement notification services in J2EE applications. Emails were an easy way to notify end-users of business events in an application. With the emergence of new notification channels (such as WAP Phones, Instant Messaging applications, and SMS Pagers), sending notifications has become more complicated. Now, applications have to support an ever- changing set of communication channels that end users would like to be notified on. Each of these channels has a separate API that must be used to communicate with it, so a considerable amount of time will be needed by developers to code these API’s into their applications. Additionally, once developers have finished building the communication mechanisms, they will also need a way of determining where to contact an end user at what time (i.e. should an email be sent to the users PC, or should a SMS page be sent to the users cell phone, or both?).

In this article, we will describe how a Notification server will solve the problems associated with sending out notifications in a multi-channel environment. The notification server will abstract communication code out of J2EE applications, and let end-users themselves manage the devices by which they would like to be contacted. Application developers will only need to learn how to communicate with the Notification server, freeing up their time to work on tasks that are more important.

JavaMail has been used for the past few years as a standard way of notifying users of business events in Java applications. To enable business notifications, all a developer had to do was learn the JavaMail API, and build the notification code into his application. Since email was the only delivery channel available to an end user, the Java code needed to implement notifications was fairly straightforward. The following snippet of code is an example of what you might use to send out a business event (an order status message) to an end user.




As you can see, the application developer needs to keep track of a number of pieces of information to send an event to the end user; the email server to send the email, the sender address, the receiver email address, and the presentation format of the email itself. In this example, the message was sent as HTML. The application developer also needs to build extensive exception handling into this piece of code – e.g. should the message be resent if an exception is thrown while sending it? The emergence of new communication channels (e.g. SMS, Instant Messaging, Voice browsers) makes the application developer’s task even more difficult; in addition to managing all of the aforementioned pieces of information needed to send an email, they also need to manage the information for all the communication channels. The developer will also need to learn the different Java API’s needed for communication with these channels (e.g. an SMS Java API, an instant messaging Java API). As you can surmise, the application developer will need a considerable amount of time to integrate new channels into their application. If some of these notification tasks were abstracted into a single service, development time would decrease significantly. When sending notifications to different channels, device specific considerations must be kept in mind. A simple “transcoding” solution would not work well, such as cramming an HTML-based email into a 2-line display on a cell phone. Instead, a more useful approach would be select content for a particular channel. Lets take the case of sending news alert to a user. The following table lists what the optimal content for the device might be:



As J2EE developers have learned, separating business logic from presentation has many advantages. As a result, the MVC (Model-View-Controller) design pattern has been widely adopted by the development community in building J2EE web applications. Similarly, when sending notifications to multiple devices, separating the notification content from the presentation layer is essential. Since each device has its own presentation content (e.g. VoiceXML for voice notifications), separating the presentation layer becomes essential, since the majority of Java developers are not experts in multi-channel content.

By using XML and XSL, you can separate business content into an XML schema, and separate presentation content in XSL stylesheets. The XML schema will store information such as the event target user, event subject, and the event body. The device specific XSL stylesheets will store presentation specific content. Figure 1 illustrates a sample XML schema containing information about a business event. Elements such as message, description, and detail are clearly defined, so that they can be easily formatted. Figure 2 illustrates a sample XSL stylesheet, which will be used to transform the event XML document into a SMS message. Since screen size is at a minimum on most devices that can receive SMS messages, only the message itself is displayed.




Figure 1 - Sample XML Schema



Figure 2 - Sample XSL Stylesheet

Now that we have explained how you would separate event content from presentation, you need a way to store all of the various communication channels an end user would use. Additionally, end users would also like a way to modify when they would like to be contacted on each specific channel. Instead of having maintained this information in your application, why not have end users do this themselves? A Notification server should have a web-based application that end users can use to store profile information about the various channels (i.e. what is my email address, what is my SMS number, what is my Instant Messaging name, etc), as well as the periods they want to be notified on each channel. (I.e. email from 9 to 5, SMS from 5 to 10, Voice Notifications from 10 to 12). Figure 3 illustrates a possible front end for a user profile data entry.



Figure 3 – Notification profile user interface

Now that we have defined all of the functionality a notification server should provide, lets look at it from an architectural perspective, in Figure 4. Both users and applications can connect to the notification server to send notifications out, which the notification server would format using XSLT stylesheets and forward on to the various delivery servers (only 2 are mentioned in this diagram: an SMS Gateway and a SMTP Server.). Users would also have the ability to setup profile information, and view detailed information on alerts that have been sent to them. Finally, the notification server will persist all of its data to a persistent data store. As you can see, it is easy to add new delivery mechanisms without making many fundamental changes. To add FAX notifications, all one would have to do is establish connectivity between the notification server and the FAX delivery mechanism (a FAX server), and then add a XSL stylesheet to perform a transformation of the alert data into a format suitable for a fax machine.



Figure 4 - Notification Architecture

Now that we have a high level view of what the notification server looks like, lets look at how it would be implemented in Java. Figure 5 shows part of a high-level class diagram of the core of the notification server. Here are some descriptions of some of the classes:



Figure 5 - High-level class diagram

Referring back to the code snippet at the beginning of this article, let’s see how Notification servers can simplify an application developer’s coding tasks. Instead of using the JavaMail API, we will use the API provided with an off-the-shelf Notification Server. The following code snippet would accomplish the same task in less than half the amount of code as listed above.



In the first line of the code snippet, an event is created using an Event object, which takes in the user, event header, and event body as parameters of the Constructor. In the second line, the event is sent to the notification server using the EventToolkit object. Using a notification server, all the application developer must know is the username to which to send the event. The Notification server manages all the other information that the developer needed to know in the JavaMail API code sample (the email server to connect to, the sender and receiver email addresses, and the html presentation formatting). Additionally, this piece of code will enable the developer to send SMS, Voice, and Instant Messaging alerts; the developer does not have to learn any additional API’s.



Figure 6 - Sequence diagram

The Figure 6 shows what is going on behind the scenes of the call. A SAX Parsing Handler (EventHandler) is created to parse in the XML based event. Once parsing is successful, an EventQueueItem (containing the Event) is added to the event queue. The notification server will then send out notifications from the EventQueue, based on the user profile associated with the event.

Summary

Today, end users employ a number of channels to obtain information - email, SMS, Instant Messaging, and Voice notifications to name a few. Although the JavaMail API was useful in the past, notification servers provide the most logical way to send out notifications to a variety of channels. By abstracting communication APIs (such as JavaMail) out of your code, and into the notification server, your development time will be freed up for more important tasks.

About Cysive™

Cysive, Inc. (www.cysive.com) is a provider of Interaction Server software that allows enterprise customers to communicate and interact with customers, partners and employees over multiple communications channels. The Cysive Cymbio Interaction Server is an integrated, web services platform that manages adaptive interaction scenarios. Cysive Cymbio combines web services integration and adaptive business process functionality to deliver multi-channel communications and interaction. Since 1993 Cysive has built mission-critical business systems for Global 2000 firms, including Cisco Systems, AT&T, Chase, Equifax, First Union, Schneider National, and DaimlerChrysler, among many others. Cysive is headquartered in Reston, Va. with additional offices in Atlanta, Chicago, Dallas, Denver, Irvine and Mountain View, Calif., and New York.

About the Author

Sunil Makhijani, Senior Software Engineer, Cysive, Inc. Sunil Makhijani is a senior software engineer at Cysive, Inc. where he works in Sales Support for the Cymbio Interaction Server. Sunil was also a contributing author to the BEA Weblogic Server Bible, recently published by Hungry Minds Publishing. Sunil may be reached at smakhijani@cysive.com

More Wireless Features

---

Does your company have a solution, news, event, or scoop that WDN should know about?
Send details to editors@wirelessdevnet.com