Microsoft has announced the Messaging and Security Feature Pack for Windows Mobile 5.0, which some press and bloggers are calling the "Blackberry killer". I am not thinking on which technology will be prevalent, but I am trying to understand why and how Microsoft is doing this.
The Blackberry is an interesting device. In my view it is an e-mail device, with processing capabilities based on Java. Its forte is the tight integration with a messaging platform. It does however require server software installed in the operator's premises (this is for the Enterprise Edition). This server software, or middleware, is constantly connected to the company's e-mail servers (Microsoft Exchange, Lotus Domino, and Novell GroupWise) through a secure connection.
This server is also constantly aware of the RIM Blackberry's presence, through an always reserved PDP context (Packet Data Protocol). This means that the connection between the server and the Blackberry device is always-present. When a new message arrives on the server, it can be immediately sent down to the device through this connection, giving the impression of an instant e-mail message on the mobile device.
Ok and how the original Microsoft Exchange 2003 AUTD (Always Up-To-Date) works with a Windows Mobile 2003 device? After the configuration on the server side and the first synchronisation (over the air or via USB), the user is asked how frequently the device should be updated. The option "When new items arrive" will be followed by the request of a Device SMS Address.
The device SMS (Short Message Service) address is generally an e-mail like address in the form of [phone number]@[mobileoperator].com that will be routed to the mobile operator's servers, and from there relayed to the SMS recipient as a standard SMS. The Exchange Server will send an e-mail to the Device SMS Address whenever a new item arrives on the Inbox, and this will trigger an Exchange ActiveSync on the device. This is actually a "wake-up" call so the device can initiate the synchronisation, and the user sees the resulting e-mail in the device's Inbox.
The protocol is quite efficient, and no notification will be sent out if a synchronisation is started while an e-mail arrives.
In essence, both solutions have the same result: the e-mail arrives on a mobile device and an icon or sound will notify the user. And frankly, if it takes 5 seconds on a Blackberry, or 10 seconds on a Windows Mobile device, what difference does it make? It is not like someone sits in the office waiting to act on any and all e-mails instantly anyway.
You may ask: it works, so why is this bad? Yes, it works, and I use it constantly with my own Exchange Server 2003 and Windows Mobile Smartphone. It never fails (after applying the correct patches!) and I am satisfied. And mobile operators are happy with data traffic.
But it looks like mobile operators failed to work with Microsoft (or more importantly, with its clients) to create data plans that actually have bundled SMS. You see, users (in this case the sender) pay for each SMS sent, and in some countries users even pay to receive a SMS. You can imagine how large the bill can be at the end of the billing cycle, when the heavy e-mail user finds out that each notification costs $0.20)...
And to make things worse, SMS is not a guaranteed delivery service. For example, Vodafone New Zealand was offering free SMS weekends in June 2005 (when I am writing this entry), and the overload on the network was so heavy that users complained of SMS being delayed for 12 hours or more. It means that in that notification-based solution the mobile devices would not receive the notifications and no synchronisation would happen.
Microsoft worked to create an updated version of this always-on e-mail concept, and implemented it through Microsoft Exchange Server 2003 Service Pack 2 and the Messaging and Security Feature Pack for Windows Mobile 5.0 (read more).
The new features are actually richer than simple e-mail. Administrators will be able to remotely configure the Windows Mobile 5.0 device from a GUI on the Microsoft Exchange Server, creating and enforcing security policies that are updated on a device when it connects to the server. Through these policies it will be possible to force a device to request PIN, limit the number of access attempts and even erase the memory contents if the device is lost (I saw a presentation where this feature was shown as a web page, not a GUI). The new features also include certificate authentication so users do not need to enter corporate password on a mobile device.
For the always-on e-mail, things work in a different way too. In this new version, Microsoft wanted to keep the mobile operators on the side, only needed for the data connection. There is no need for SMS notification anymore, and IT must not worry (more than usual) about security: the synchronisation is performed through a encrypted connection through port 443, which is (probably) already open to support Exchange OWA (Outlook Web Access).
"The device issues an HTTP request to Exchange, which asks Exchange to report any changes that occur in the mailbox of the requesting user within a specified time limit. The URL of this HTTP request is the same as that of other AirSync commands ("/Microsoft-Server-ActiveSync") with some differing query string parameters. The body of the HTTP request allows the client to specify those folders that Exchange should monitor for changes. Typically, these will be the Inbox, Calendar, Contacts, and Tasks folders.
Upon receiving this request, Exchange will monitor the specified folders until either the time limit expires or a change (such as the arrival of a piece of email) occurs in one of those folders, whichever comes first. Exchange will then issue a response to this request that notes in which folders the changes occurred. Of course, this will be empty if the time limit elapsed before any changes occurred.
Upon receiving an empty response, the device simply re-issues the request. This loop of issuing a request for change notifications, receiving an empty response, and re-issuing the request for change notifications is called "the heartbeat."
Upon receiving a non-empty response, the device issues a synchronization request against each folder in the response. When those complete, it re-issues the request for change notifications."
So there you go. It is in essence very different from the Blackberry solution! First, the device will still initiate an ActiveSync on request, but the notification is no longer coming through a SMS, but through a HTTP response, which must be received within a certain time limit.
Second, this implementation will require the synchronisation against each folder, not all of them. There's no checking needed if the folder is not marked as changed.
And you may say, it is not exactly push e-mail. But it looks like the time between notifications send/receive in the SMS solution is no longer a problem. Neither is the non-delivery of SMS a concern, because as long as the device is on, the connection is open.
Network traffic should not impact on cost, because the HTTP handshake is based on a timer, and no traffic is sent or received during the cycle, unless a message arrives, in which case the HTTP response from the server will be "Hello, there's a new message here, and just arrived now, before the next heartbeat".
Just to compare costs, remember that the alternative was a $0.20 per SMS notification to triger the ActiveSync action. This is much more expensive than a HTTP request.
Also, the solution does not require any server software in addition to the Exchange Server 2003, and no involvement from the mobile operator (except for GPRS of course).
I have already seem some purists writing that "this is not really push e-mail", but now that the Exchange team blog explains how it works, I really don't see a problem. I really want to install Exchange Server Service Pack 2 when available and start testing this!