For the past few years the JavaMail API has been used to implement notification services in J2EE applications. E-mails 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 about. Each of these channels has a separate API that must be used to communicate with it, so a considerable amount of time is needed by developers to code these APIs into their applications. In addition, once developers have finished building the communication mechanisms, they will also need a way to determine where to contact an end user at what time (should an e-mail be sent to the user's PC, should an SMS page be sent to the user's cell phone, or both?).

In this article, I describe how a Notification Server solves the problems associated with sending out notifications in a multichannel environment. It abstracts communication code out of J2EE applications and lets end users manage the devices with which they would like to be contacted. Application developers will need to learn only how to communicate with the Notification Server, freeing up their time to work on more important tasks.

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 or her application. Since e-mail was the only delivery channel available to an end user, the Java code needed to implement notifications was fairly straightforward. Listing 1 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 in order to send an event to the end user ­ the e-mail server to send the e-mail, the sender address, the receiver e-mail address, and the presentation format of the e-mail 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 the aforementioned pieces of information needed to send an e-mail, he or she also needs to manage the information for all the communication channels. The developer will also need to learn the different Java APIs needed to communicate with these channels (e.g., an SMS Java API, an instant messaging Java API). As you can surmise, application developers 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.

Body
When sending notifications to different channels, device-specific considerations must be kept in mind. A simple "transcoding" solution, such as cramming an HTML-based e-mail into a two-line display on a cell phone, would not work well. Instead, a more useful approach would be to select content for a particular channel. Let's take the case of sending a news alert to a user. Table 1 lists what the optimal content for each channel might be.

As J2EE developers have learned, separating business logic from presentation has many advantages. As a result, the Model-View-Controller (MVC) design pattern has been widely adopted by the development community to build 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 is important since the majority of Java developers are not experts in multichannel content.

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

Now that I have explained how you would separate event content from presentation, you need a way to store all the various communication channels an end user would use. In addition, end users would also want a way to modify when they would be contacted on each specific channel. Instead of maintaining this information in your application, why not have end users do this? 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 e-mail address? what is my SMS number? what is my instant messaging name? etc.), as well as the times they want to be notified on each channel (e-mail from 9 to 5, SMS from 5 to 10, voice notifications from 10 to 12). Figure 1 illustrates a possible front end for a user profile data entry.

Figure 1

Now that we've defined all the functionality a Notification Server should provide, let's look at it from an architectural perspective (see Figure 2). Both users and applications can connect to the Notification Server to send notifications out, which the server would format using XSLT stylesheets and forward to the various delivery servers (only two are mentioned in this diagram: an SMS Gateway and a SMTP Server). Users would also have the ability to set up 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.

Figure 2

As you can see, it's easy to add new delivery mechanisms without making many fundamental changes. To add fax notifications, all you'd have to do is establish connectivity between the Notification Server and the fax delivery mechanism (a fax server), and then add an XSL stylesheet to perform a transformation of the alert data into a format suitable for a fax machine.

Now that we have a high-level view of what the Notification Server looks like, let's look at how it would be implemented in Java. Figure 3 shows part of a high-level class diagram of the core of the Notification Server. Table 2 provides descriptions of some of the classes.

Figure 3

Referring back to Listing 1, let's see how Notification Servers can simplify an application developer's coding tasks. Instead of using the JavaMail API, we'll 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 shown in Listing 1.

Event event = new Event(new PortalID("jdoe"),
"Order Status",
"Your order is complete");
EventToolkit etoolkit = EventToolkit.getInstance()
.createEvent(event);

Figure 4 shows what's 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.

Figure 4

Summary
End users employ a number of channels to obtain information ­ e-mail, 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.

Author Bio
Sunil Makhijani is a senior software engineer at Cysive, Inc., where he works in sales support for the Cymbio Interaction Server. He's also a contributing author to the BEA WebLogic Server Bible published by Hungry Minds Publishing. smakhijani@cysive.com

	


Listing 1

// Set your mail server properties here
Properties props=new Properties();
props.put("mail.host","mailserver.somewhere.com");


// Get a JavaMail session using the mail server
Session session = 
Session.getDefaultInstance(props, null);


// Create the message
Message message = new MimeMessage(session);


// Fill the message
message.setSubject("Claim Assigned");
message.setFrom(
new InternetAddress("from@someone.com"));
message.addRecipient(Message.RecipientType.TO,
new InternetAddress("jdoe@someone.com"));


String content = "<H1> Please inspect the car and
submit incident report 024199 <H1>";


message.setContent( content,"text/html");


  // Send the message
Transport.send(msg);



Listing 2

<event>
  <recipient domain="cysive.com">jdoe</recipient>
  <message>Claim Assigned to you</message>
  <reference name="RedDot Insurance Inc."/>
  <description>Claim Assigned</description>


  <detail>
    <name>todayDate</name>
    <value>05/24/2002</value>
  </detail>


  <detail>
    <name>Reason</name>
    <value>Please determine repair costs</value>
  </detail>
     
   <detail>
     <name>Claim #</name>
     <value>024199</value>
   </detail>
</event>


Listing 3

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" >
<xsl:output method="text" version="1.0"
encoding="UTF-8" indent="yes"/>
  <xsl:template match="/">
    <xsl:for-each select="event">
      <xsl:value-of select="message"/>
    </xsl:for-each>
  </xsl:template>
</xsl:stylesheet>