Just as the Web has revolutionized information distribution and retrieval, instant messaging is revolutionizing communication. Instant messaging is a powerful tool that few enterprises or application developers have fully harnessed. Despite its pervasive use by millions all over the world, few businesses have yet to exploit it.

Presently instant messaging in the enterprise is hobbled by competing service providers each with their own proprietary protocol. Most end users are wedded to one of the major providers, such as AOL, Yahoo, MSN, and ICQ, since networks of acquaintances create a formidable inertia to new players. If a business wants to provide services via IM, they have to play with at least the big three providers to reach customers. Complicating matters, existing IM clients are not extensible or easily integrated into business processes. Clients today do not centrally log messages or furnish the ability to expose enterprises or systems as one buddy and dynamically dispatch messages to potential responders based upon availability.

In the increasingly regulated post-Enron and HIPPA business environment where penalties are stiff, logging messages and ensuring confidential information isn't leaked is of utmost importance. This is where JBuddy comes to the rescue. JBuddy provides a uniform API against which developers can easily build their own applications that interoperate with instant messaging but serve their own needs.

JBuddy is an all-Java library that supports AOL Instant Messenger, ICQ, MSN, Yahoo Instant Messenger, and enterprise IM solutions including Lotus Sametime, Jabber, and Zion's own messaging protocol. For those developers required to use a non-Java language, JBuddy even sports a COM wrapper that exposes JBuddy in both COM and .NET using an interop layer. The details of the underlying protocols are cleanly hidden from the application developer and the API is deceivingly elegant and simple. JBuddy supports file transfer as well as the ability to set away messages, retrieve lists of buddies, check buddy availability, and receive system events from service providers. However, to tie into service-specific features, JBuddy provides an additional set of interfaces for each, allowing you to more fully leverage the different features. There are a total of 20 classes in JBuddy residing in two packages: com.zion.jbuddy and com.zion.jbuddy.filetransfer.

To put JBuddy through its paces, a small "BuildBuddy" bot was constructed that would send notifications when a software build was completed and respond to inquiries about the present build number. The notifications could be generated either by Ant tasks or shell scripts. At the start of a build the bot would change its status from "available" to "away" and broadcast a message to all buddies regarding either the success or failure of a build. A set of command-line programs to manage the bot's buddy lists and services were written to facilitate configuration. Since the bot should always be online, it was implemented as a server with clients connecting via RMI. Figure 1 shows the overall structure of the server. The BuildGateway class implements the JBuddy IGateway interface through which IM events are delivered. In the case of this bot, there's only one instance of BuildGateway created and it handles events for all registered services.

The source code for the bot can be downloaded from the JDJ Web site (www.sys-con.com/java/sourcec.cfm). To build and run the application you'll need Ant as well as a license from Zion for JBuddy. Compiling the project is easy, just type "Ant" within the project directory. To run the server you'll need to create a .java_policy file in your home directory with the following content:

grant {
permission java.security.AllPermission;
};

In addition you'll need to edit the java.rmi.server.codebase property in the run_server.sh script to point to im.jar in the project directory. Once these modifications are complete, the server can be started from the command line via "./ run_server.sh", passing the hostname of the machine and optional plug-in configuration file. Table 1 lists the various command-line and Ant tasks. Before you can use either the command-line utilities or Ant tasks in a build process you must connect to a service by using "addService". AddService has the following parameters:

addService <hostname> <client type> <username> <password>

The hostname is the address of the machine on which the RMI server is running. The client type can be AIM, YIM, ICQ, MSN, etc., as found in the JBuddy Javadoc. Presently the bot will print out verbose output so you can see the callbacks in action. If the account you created doesn't already have buddies, you'll need to add them by using the "addBuddy" script. When adding a buddy you must specify the service type as well as the username of the account. Using the Ant tasks requires adding the task definition to your Ant file. The file "example.xml" is a prototype Ant script using the command-line utilities.

While the API is extremely concise, the devil is in the details. Since this is a fairly large application I'll focus on the core functionality as it relates to JBuddy. Although JBuddy does a great job of abstracting away the nastiness of the underlying communication protocols, managing the various clients with their idiosyncrasies is still a formidable challenge.

The most logical place to start is with the creation of a client connection. The "addService" method on the BuildBuddyServer connects to a service provider given the service type (AIM/ YIM, etc.), username, and password. For ease of use, the settings for the service are saved as application preferences using the 1.4.1 Java Preferences API by the BuildBuddyConfiguration class. Connecting to a service is accomplished by passing an instance of IGateway into the factory method on IClientFactory:

IClient client =
IClientFactory.factory
(<gateway>,<service type>,<username><password>);

The service type is a constant from IClient such as AIM, YIM, ICQ, etc. The client created is not yet connected to the service. To connect to the service, the connect method needs to be called; however, it is an asynchronous method and when it returns you should check the return value first as you may not actually be connected to the service yet and hence cannot perform any operations on that client. Wait until the client is ready by checking the isOnline method before performing any operations on that client:

	client.connect();
	while ( !client.isOnline() ) {
Thread.currentThread().sleep(500);
}

Note: In a robust application the loop should also check for successful authentication to the service provider. If authentication fails, an admin message will be sent to the IGateway instance registered for the client with a text message of some sort that the username/ password is invalid, followed by a subsequent connection lost event to the gateway. The is Online method call would therefore block indefinitely. The message sent by the service is different for each service provider. The BuildBuddy bot doesn't handle this situation and assumes that the account and credentials provided are valid.

During development, it's important to know that IM services, such as AOL AIM, impose several restrictions including message send rates, warning percentages, and limits on the number of times an IM account can log into the service within a specified time interval. If the threshold is exceeded, the account is inactivated for a period of time measured in minutes. This can cause significant problems during development and necessitates several backup accounts. All client objects are saved in a List to facilitate disconnecting from all of the services.

One of the core features of the bot was its ability to change "state" depending on whether a build was in progress. Since this bot maintains a presence on multiple services, it must iterate over the list, changing the state on each client object representing the connection. Interestingly, the capabilities of the various IM services vary dramatically with regard to away messages. Both AOL and Yahoo support custom away messages so that users can specify their own messages, whereas the other services have hard-coded choices or none at all. The status of a client can be set via:

client.setStatus(IBuddy.<type>,message);

The simplicity of this line is somewhat deceiving. The BuildBuddy bot has to set a different away type for each service. IBuddy.AWAY is used for AOL, whereas IBuddy.CUSTOM_AWAY is used for Yahoo and IBuddy.BUSY for MSN. In the case of MSN the away message is ignored. This is an area where perhaps another level of abstraction would be beneficial.

The broadcast method on Build-BuddyServer iterates over all the services and fires an instant message to each buddy. For each service there isn't a canonical list of buddies – it must be constructed by taking the distinct union of all buddy groups. A buddy can belong to more than one group; however, when blasting a message out to all buddies, sending the same message to the same person more than once is obviously not a good idea. Listing 1 constructs the unique buddy list for a given client.

After the unique list of buddies is acquired, a message can be sent out to each by simply calling "sendIM (<buddy>,<message)" where <buddy> is a string. Each call to sendIM should be wrapped in a try/catch block since an IOException will be thrown if the buddy is not online. In the case of AIM, you can't repeatedly blast out instant messages to the same buddy in rapid succession. AIM has a time threshold for message intervals and if this threshold is violated, the client is automatically kicked off for a period of time. While this bot doesn't contain logic for spacing messages, any production system must take this into account or work out terms with AOL to have such restrictions lifted. In testing JBuddy I only ran into this when blasting the same buddy in a loop.

As mentioned previously it's through the IGateway callback interface that IM events are delivered. Whenever the status of a buddy changes, the "incomingBuddy" method will be called. The IBuddy object encapsulates the state information about the buddy. In addition, after the bot has sent a message to a buddy, if that buddy begins to type, a message of type IMessage.Typing is sent back to the bot. This is how regular clients know whether a buddy is typing a reply and thus is used to provide visual feedback. The adminMessage method receives notifications from the service regarding authentication and other service announcements. A call to the connectionLost method has a multitude of causes including the maintenance of a service's servers, loss of network connectivity, or the same IM credentials being used by another client. The BuildBuddy bot assumes that a lost connection stems from a server reboot, hence it attempts to reconnect. Because the connectionLost method is also used to inform the client of an authentication failure, this can be dangerous and additional state would need to be maintained.

One of the most exciting features of the bot that I will leave you to explore is the autoresponse plug-in architecture. You can add plug-ins that will respond to a query posted by a buddy. Each plug-in has an associated regular expression that determines to which messages it responds. Combined with the file transfer support APIs, there are unlimited opportunities.

There are some issues companies should be aware of when building applications on top of proprietary instant messaging protocols. First the various instant messaging providers are sensitive to security on their networks, having been bitten by viruses and "booter bots" (bots on the IM network that cause another user to be disconnected by exploiting a client vulnerability), thus they can and will unexpectedly modify their protocols. While there will undoubtedly be hiccups when protocols suddenly change, reverse engineering the changes is a much tougher challenge worth avoiding.

Zion has indicated that it was working with the different IM providers to forge agreements but no terms had been reached at the time this review was written. However, Zion will provide patches to subscription customers free of charge to correct incompatibilities as soon as they are available. In addition, JBuddy does not yet support retrieving/setting buddy icons. While this is purely a vanity feature, some may want the ability to choose an appropriate icon to represent their presence.

If you don't require public IM for your IM bot application or if you need to keep messages internal to your organization for compliance, etc., JBuddy SDK also supports enterprise IM solutions such as XMPP (Jabber), Lotus Sametime, as well as Zion's IM client as featured on java.com (JBuddy Messenger) and Java IM server (JBuddy Message Server), which will complete any realtime enterprise architecture.

Zion Software, LLC
2842 Main Street
Suite 325
Glatstonbury, CT 06033
E-mail: info@zionsoftware.com
Phone: 860 432-6258
Web: www.zionsoftware.com

Summary
JBuddy is a powerful library for building IM-enabled applications. Within minutes a developer can have IM capabilities built into an existing application. Enterprises looking to provide IM functionality for customers can use JBuddy as a solid foundation to interface existing services.