Using Notification Servers in J2EE Applications
Contributed by Sunil Makhijani, Senior Software Engineer, Cysive (October 2002)
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
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.
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.
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 email@example.com
More Wireless Features
Does your company have a solution, news, event, or scoop that WDN should know about?
Send details to firstname.lastname@example.org