Finding a Corporate IM Server to Call Your OwnBy Channel Insider Staff | Print
Public IM networks may be easy to use, but for a serious and secure enterprise IM system, you need one of your own that can also talk with the public networks.
Like it or lump it, your staffers are using instant messaging. For years, no one has cared about managing IM (instant messaging). But security risks such as the Kelvir worm, which temporarily put Reuters IM out of business; IM-based phishing attacks; and Sarbanes-Oxley Act IM requirementsare making instant-messaging management a priority.
How big is the IM management problem? AOL reports that in the United States alone, there are about 14 million business AIM users. And it's no wonder that many companies have taken to defaulting to using public IM systems such as AIM (AOL Instant Messenger) and YM (Yahoo Messenger).
That's a mistake.
With public IM, you're essentially outsourcing your IM to a third-party system, with which your company has no contract, no guarantee of service and no real control over what they may or may not do with your business IMs.
For that matter, IM carriers such as AOL and Yahoo can, and have, just shut down interoperability with such popular third-party IM clients as Gaim and Trillian.Users prefer these clients since they let them talk to users on multiple IM networks.
When you consider all of the issues—security, management and quality of service—it's clear that you can't continue to rely on the public IM systems. Using public IM may be easy, but it just doesn't make business sense in the long run.
Still, recalling those 14 million business AIM users, you'll also need a system that will enable your users to talk to the greater IM universe and not just to their fellow corporate citizens. Just like e-mail, your workers need to talk not just with each other, but also with their customers and clients.
Private IM Systems, Public IM Networks
Fortunately, AOL has recently made talking to AIM usersmuch easier.
The AOL Enterprise Federation Partner Program now makes it possible for users working with IM clients using SIP/SIMPLE (Session Initiation Protocol/SIP Instant Messaging and Presence Leveraging Extensions), XMPP (Extensible Messaging and Presence Protocol), or AOL's proprietary format to communicate with each other.
This works via a translation gateway approach, AOL's Federation Gateway, in a way that's remindful of the old RFC-822/X.400 e-mail gateways before RFC-822 became the dominant e-mail standard.
"AOL's major IM competitors, Yahoo and MSN, have far less commitment to enterprise support," said David Ferris, president of e-mail research house Ferris Research."Microsoft seems to be de-emphasizing MSN enterprise IM connectivity in favor of connectivity through its LCS [Live Communication Server] 2005, [and] Yahoo shut down its enterprise sales unit."
Providing an IM lingua franca.
Therefore, it is becoming even more important to add AIM or another product with a similar ability to be managed and to act as an IM lingua franca and interlocutor between the public IM network and your corporate IM system.Some IM products already have AIM support, such as Microsoft's LCS 2005. IBM used to do so with its Sametime system, but Big Blue no longer supports AIM intercommunications.
On the other hand, as Ferris pointed out, "Microsoft has had great difficulty getting a usable IM system out to its customers, and that situation might continue, [and] telephony players are discovering the key role of presence. As new VOIP (voice-over-IP) solutions are deployed, presence might bring other IM players to the fore."
"With LCS 2005, different companies with LCS 2005 will be able to federate directly," Ferris said. "But for each pair of links, they'll need to implement and manage the link. Using AOL as the connecting hub should be much more practical."
A wise administrator should look beyond LCS 2005 and consider other enterprise IM solutions, such as those of AOL's new partners or other companies that use protocols compatible with AOL Federation Gateway.
JM is a Java-based server for both group chat and IM. It is based on Jabber's XMPP protocol. As such, out of the box it can be used both internally and to connect with other Jabber users on the Internet.
Since Jive is a partner with both Antepo and Jabber, and AOL has every intention of expanding its Federation Partner Program, it seems likely that JM soon will be AIM-compatible. In any case, its protocol, XMPP, is already AOL Federation Gateway-compatible. This means that your Jive users should be able to use their clients to talk to AIM users.
So, specifically, why would you want to give Jive a try for your enterprise IM?
JM has several factors in its favor. First, it is open-source, so if you have Java programmers on staff, you can easily tweak it to your exact needs. That also enables you, if your show has some savvy developers, to do such things as set up the Jive server to use SSL (Secure Sockets Layer) to safeguard IM communications using the standard Java security SSL implementation (javax.net.ssl.SSLServerSocket).
Then, using for example, Sun JDK (Java Developer Kit) 1.5.x or higher, you can set up the server to use SSL during user authentication and communications. You also can set it to use a self-signed SSL certificate to avoid the costs of a certificate authority-signed certificate.
No need to get your hands dirty.
At the same time, though, you don't have to get your hands dirty with code. Jive Software will cheerfully give you other support options.
If you want more than group and one-on-one IM sessions, Jive also sells commercial XMPP servers such as Jive Live Assistant,a live customer-chat system that includes built-in access to e-mail archives, file systems and third-party knowledge bases so that the help-desk assistant can quickly and easily assist customers when they request aid.
What You Need to Run JM
For basic operations, you probably won't need support or a commercial product. JM is very simple to install, operate and manage with its full, Web-based administration interface. Jive Software is also an active user community,which includes not just expert users but JM developers as well.
Last but not least in the reasons to look toward JM for your corporate IM needs, JM runs on several operating systems and with several back-end databases.
JM runs on both Windows and Linux/Unix systems. However, while you can run JM on client systems such as XP Pro, you'd be much better off running it on a real server platform such as Windows 2000 Server or Server 2003.
JM also comes in two Linux/Unix builds, a Red Hat Package Manager edition for Red Hat/Fedora systems and a compressed archive, .tar.gz, for other *nix operating systems. The one key difference is that the compressed archive does not include a bundled Java runtime. Thus Unix administrators would need to check to make sure JDK 1.5.0 of J2ME (Java 2 Micro Edition) or later was installed. The Windows version also comes with the right JDK.
You can easily check to see if you need to upgrade by typing "java -version" at your command line. If you don't have the right version, you can upgrade it from Sun's Java site.
The program also needs a database server back end if you're going to do more than play with it. While JM comes with an embedded database, it's strictly lightweight.
Fortunately, JM supports JDBC (Java Database Connect), so almost any major database can be used with it. In particular, Jive provides instructions for running JMwith, among others, IBM's DB2, Microsoft's SQL Server, MySQL, and Oracle 9i or 10g.
Putting JM Through Its Paces
In my case, I decided that even though I run several flavors of Linux, I would give the Windows XP 2.1.2 version a try.
With minimal system requirements—recall that you can run it from an XP Pro workstation—I nonetheless decided to put it on a production-level system: a 2GHz Pentium IV white-box server running Server 2003 SP1 (Service Pack 1).
For the database back end, I used SQL Server 2000 running on a similar hardware platform with Windows 2000 Server SP4 installed. I connected JM to the database using Microsoft's own SQL Server 2000 Driver for JDBC SP3.
JM comes with a Web-based setup tool that automatically sets up its tables in the appropriate database.
For user authentication, I used LDAP (Lightweight Directory Access Protocol). Jive provides a straightforward explanationof how to connect JM with your LDAP server.
There are, however, a few things you need to keep in mind. The first is that JM treats LDAP as read-only, so you can't add or edit users via JM. You'll need to use your usual LDAP interface for those purposes.
Some LDAP servers, such as the extremely popular OpenLDAP,do not support server-side sorting of search results. This causes what appear to be out-of-order results when you're looking at a directory of users. Jive recommends setting up client-side sorting to avoid this problem.
Getting adventurous with JM Code
Adventurous developers might want to try working with the JM code and OctetString's open-source JDBC-LDAP Bridge Driverto enable server-side editing or sorting.In the event, I used OpenLDAP, with Jive's suggestion of setting ldap.clientSideSorting to "true" in JM's XML configuration file. I ran OpenLDAP on SLES (SuSE Linux Enterprise Server 9) SP1.
The actual JM installation on Server 2003 was almost mindlessly simple. I spent far more time setting up SQL Server 2000 for JM than I spent on setting up JM itself. All in all, I was up and operational within an hour.
Fine-tuning it, though, took a while. First, while it looked perfectly available within my network, I had trouble getting messages to it from the Internet.
That turned out to be my own problem rather than JM's fault. I used a packet-based firewall between my LAN and my DMZ (demilitarized zone), and then both a packet-based firewall and Network Address Translation between the DMZ and the Internet.
As can happen when you use these kinds of multiple layers of defense, I didn't have my ports opened up properly.
My final solution, since there's no proxy for JM, was to place the JM server in the DMZ. I then opened only ports TCP 389 for OpenLDAP and TCP 1433 for SQL Server. I opened up public ports 5222, for normal XMPP traffic, and 5223, for SSL-encrypted XMPP traffic.
Once that was taken care of, it ran flawlessly. My only concern from a server perspective is an old one I have with the JVM (Java Virtual Machine). Left to its own devices, this version on Server 2003 seems to eat up more heap memory than it should. So, I fed the JVM the -Xms –Xmx arguments, to set the minimum and maximum heap sizes. This in turn enabled me to keep its memory requirements in sharp check.
The Web-based administration was straightforward. I had no trouble running it with both Firefox and Internet Explorer.
I used a variety of IM clients without any trouble. These included Gaim on both Linux and Windows, and Trillian Pro (the free version doesn't support the XMPP/Jabber family). I did, however, have trouble running the KDE Kopete client with JM. But this turns out to be a known problem with Kopete and XMPP in general and not a JM problem at all.
While my server load was light—never more than 20 users online at any given time—I saw no signs that a far higher level would have caused my middleweight JM server any trouble. Since the program is freeware, and simple to install if you leave out the DBMS and LDAP requirements, you can run it yourself in a test environment. I'd be very surprised if you ran into significant performance problems, even on lightweight servers.
In short, if you want an easy-to-use, inexpensive XMPP/Jabber IM server to call your own, JM is an excellent choice. If it does indeed gain AIM compatibility, I would put it on my "must test out" list of enterprise IM servers.
And let me say again, whether you choose JM or not, you really must have an enterprise IM server of your own. It's no longer a luxury or something you can simply fob off on the public IM networks.
Check out eWEEK.com's for more on IM and other collaboration technologies.