In the corporate world, people have calendars, contacts, and e-mail. For reasonably obvious reasons, these people want their calendars, contacts, and e-mail to be uniform both on their workstations at work and on any other device they connect to the corporate network (a cell phone, for example) - this way, no matter where they are, they’ll know where they’re supposed to go, how to talk to the person they’re supposed to meet, and communicate with everybody involved.

Sounds reasonable, right?

Let’s talk about the logistics of making this happen. You’re going to need to store these appointments, contacts, and e-mails somewhere. We’ll call this a server. You’re then going to need to get the data from the server on devices that you actually control. We’ll call these clients. Now, ideally, getting information from the server is going to be as simple as having the client talk to the server and say, “Hey, I need this information.” If the client changes any information, it will push it to the server, which will then update its information, and that will be that. If we’re feeling really fancy, upon the update of its information, the server will then check to see what clients have checked in with it recently and try to tell them that the information has changed. In short, all communication will be between the server and the client.

This sounds reasonably simple. In a corporate network, it most certainly is - all of the workstations have a straight shot to the server. Once you need to connect machines to the server that are located outside of the corporate server, things get a little more complicated… but only a little. There are a couple of tried and true ways to handle this, as well. You can either use a VPN (i.e. have the client log into the corporate network in its entirety from the remote location before accessing the corporate network) or you can use a set of pre-defined protocols that provide differing access rights to various resources from a public interface (i.e. SMTP, POP, IMAP, etc.). The first approach is somewhat akin to astral planing into your office. The second approach is somewhat akin to calling the office on the phone and asking for your messages. Unfortunately, there’s one small hitch: Until relatively recently, though there have been plenty of standards that deal with e-mail, there haven’t been any that deal with calendar appointments and contacts. That’s slowly changing (iCal, for example), but we still have a long ways to go on that front. So, more often than not, you either have to use a VPN or use some clever chicanery (RPC over HTTP) to get the job done. The drawback, of course, is that, with a VPN, unless your sysadmin is both very good and very cautious, you have access to everything remotely that you would have access to in the office, which may or may not be a smart idea.

Let’s throw smart phones into the mix.

In an ideal world, smart phones should…

1. Only have access to what they can use.
2. Behave similarly to a normal client.

For example, you probably don’t want to give a smart phone access to that expensive accounting package that you have access to in the office - it couldn’t run that program even if you wanted it to. More importantly, you probably don’t want it to even have access to those files - their size alone may brick your phone. This pretty effectively rules out a VPN; there’s just too much that can go wrong. However, we still want it to behave similarly as any other client would, meaning that we want it to talk directly with the server - we just want to have the phone and the server tell each other just enough to get the mail, appointments, and contacts across.

Makes sense so far, right?

Well, a little company called Research in Motion created a device called the Blackberry that “solved” this problem. How, you ask? Easy:

First, you install a piece of software on the server that contains all of these appointments. The software then listens in on what the server is doing and, whenever there is a change, sends out that change to some servers owned by RIM. RIM, upon receipt of those changes, sends them to the smart phone’s provider. The provider then sends these changes to the phone. The process of getting information back on to the server is the inverse of what was just described - cell provider, RIM, RIM software, mail server.

Clear as mud, right?

By comparison, let’s try the Microsoft way:

Your phone has a piece of software that talks to the server directly using a set of well defined protocols (HTTP, mostly - the same stuff you’re using to read this blog right now). When information changes on the server, the server sends out a notification to anyone that it knows has logged in recently. The phone and the server talk directly to each other.

Guess which way works a little better? Guess which way is cheaper due to not having to pay a third party (RIM) to shuttle your information back and forth through its networks? Guess which way doesn’t go down across an entire continent every so often?

Exactly.

Yet, there I was today, installing a Blackberry Professional Software server, trying to get Blackberry devices to sync with it, only to find out that the Blackberries couldn’t sync with RIM because they had not been properly provisioned. Apparently, in Blackberry World, you have to tell your provider that you don’t just want to talk to RIM, you want to let RIM shuttle messages back and forth to your main server… even though, as far as the provider is concerned, everything should be coming through the same channel anyways. Oh yes. Don’t even get me started on the weird and arcane Active Directory jujitsu they made me go through when I called their support line, nor the hour and a half wait I endured on hold.

If anybody out there is listening, could somebody please explain to me why RIM is still in business? Also, could somebody please explain to me why nobody stopped them from picking such a potentially disastrous acronym? I shudder to think how employees there explain how they got a job at RIM (a RIM job, perhaps?).

Trackback URI | Comments RSS