iPhone and the Enterprise (or How to Read Beyond a Press Release)
When I was a kid, long distance phone calls were expensive. My mother and I rarely had much money, so on those occasions when we'd make a road trip, we developed a system to convey information on departures and arrivals without paying for them.
The process was simple: after arriving some where on a trip, we'd make a person-to-person call to where ever we'd left to "I. M. Home" or something similar. If the someone at our origination point needed to talk to us, they'd simply claim to be I.M. Home and the conversation would begin. If they only wanted to acknowledge the message, they'd say that I. M. Home wasn't available, and the call would end, free of charge.
In the modern era of caller ID, we can do this even easier. If my mother leaves my house to drive home, a trip taking about 5 hours, and I see a call coming in from her home number about 5 hours later, I usually don't bother to answer. Clearly she's arrived home, and if there was some urgency to the matter, she'll call again. Similarly I often don't bother to leave voice mail messages for my wife. She'll see my number on the caller ID, and doesn't need to waste time dialing into a recording to know that I'd like her to call me back.
I think about these strategies every time I hear someone talk about "push" messaging to mobile devices. "Push" information from one device to another on an IP system requires that each device be connected and be addressable. But staying on the network is exactly the worst thing a mobile device can do, since even digital networks require 5 times the power to stay connected to in a broadcastable mode. 3G devices in stand-by consume about 0.6W, while active connections consume about 3W.
Continued...
That why Apple has stated loudly and repeatedly that iPhone's won't have continuous persistent connections to 3G backbones. They have, instead, devised an elaborate "push notification system" as a gateway service to allow server-initiated communication with mobile devices. Basically, they have built a giant reverse proxy system (or maybe a NAT system, depending on the level of operation) for individual iPhones.
How can such a proxy service work while maintaining the goal of keeping power consumption low? The key is in how the iPhone deals with requests from the proxy service. If the proxy service functions like the way my family does asynchronous communication, it's really just a question of paying attention to the caller ID and then ignoring the phone call. If a call comes in from 098-765-4321, the iPhone operating system knows that it's from the proxy service. It doesn't even have to display the call to the user for answering. It can know that the call means "wake up and connect to the proxy service -- you've got inbound traffic."
If you have low-level access to the operating system, you could do the same thing with a slightly different protocol. What if you couldn't monitor inbound caller ID traffic, but you could see SMS messages? You could encapsulate quite a bit of information in an SMS, even following the character restrictions -- certainly enough to say "hey phone, wake up and connect via HTTP and download this much larger piece of information that can't fit in an SMS." Indeed, this is such a potent strategy that our friends at Research in Motion have patented it!
Note that this is all very different from how MSFT's ActiveSync actually works. According to the Exchange ActiveSync product documentation, ActiveSync operates by maintaining a persistent HTTPS session between the device and the server. Essentially, there's a GET request from the mobile device with a REALLY long timeout that says "anything new?" In order for the server to send the reply, the device must still be listening and must still have the same IP. If there's no new traffic, the device renews the request.
That's why Apple calls it "ActiveStink." It only works in an operating condition of 1) constant background requests with long timeouts, and 2) persistent connection with the network backbone. Essentially, your phone is always making a call and is always running a web browser in the background.
So while it's certainly within Apple's capacity to use Microsoft's exact protocol to handle push mail services, it seems unlikely that they would do this. We won't know for sure until the iPhone 2.0 comes out. It will be very surprising if Apple says "we gave you enterprise connectivity but now your battery life is reduced by 80%"
What about other enterprise features? The iPhone syncs all mail, contacts and calendar events with both Exchange 2003 and Exchange 2007 servers, as well as allowing syncing with the .mac service. How might that be working?
The .mac MobileMe service is an interesting starting point. You can sync your PIM applications from a Mac to Apple's service today. This is accomplished through calDAV -- essentially iCal and vCard transactions processed through webDAV. WebDAV itself is a pretty easy protocol to understand. It uses HTTP as a transport, and expands upon the basic 5 methods for REST services to also include additional methods for commands like COPY, MOVE and PROPFIND. (Domino actually supports webDAV in a very limited fashion with file & image resources as of version 6. You can turn on webDAV support and manage resource files attached to NSF templates on your Domino server.) It's pretty easy to envision an iCal file as a resource on a web server being rescheduled via a MOVE method, right?
Since Apple already has a very effective infrastructure for Mac desktops, it's hard to imagine they'd provide their iPhone service in another way. The Mac cloud services have been very successful with the webDAV approach, and I think most readers here will understand that technology companies are often loathe to throw away sunk development costs.
What, then, for the Exchange server integration? Apple says they've licensed ActiveSync to enable enterprise integration, but what does that mean? We've already seen that ActiveSync's push architecture is the very antithesis of Apple's stated goals with the iPhone, but what about the actual data exchange protocol?
The question turns out to be more complicated than would appear at first blush, because "ActiveSync" turns out to be as loaded a term as "Lotus Notes" is. Is it an API? A protocol? A piece of desktop software? A server package? A brand name?
The answer is: yes. It's all those things. There is a piece of desktop software called ActiveSync that manages syncing your desktop Outlook instance with a mobile device that's connected via a USB cable (or Bluetooth, I think.) There's also ActiveSync for Exchange server, that manages the synchronization over HTTP. Both versions have an API associated with them. Indeed, the Exchange API even refers to services for "replication." And of course, since it's Microsoft, it works a lot differently on different versions.
Exchange 2003 and Exchange 2007 have a few API options in common. Many of the programming options available for 2003 were dropped or deprecated in 2007, in favor of using Exchange Web Services (oh the irony!) Web Services, however, are not available on Exchange 2003.
But guess what API IS available on both 2003 and 2007?
If you guessed webDAV, get yourself a cookie. In fact, MSDN specifically documents the use of webDAV for PIM replication, providing clear detail on how to use webDAV methods over HTTP to sync your mail, calendar and contacts. Of course, webDAV is just a command protocol. There's still a lot of underlying detail on how the DATA is structured inside those PIM resources to take into account. A lot of that is documented extensively on MSFT's website, but I haven't finished reading it all yet. (That part is going to take a while.)
So although we don't have an iPhone 2.0 to look at yet, it seems pretty likely that the similarity of the Exchange 2003/2007 webDAV architecture and the .mac webDAV architecture make it the path of least resistance for Apple to provide hooks to MSFT enterprises. Exchange webDAV has some proprietary extensions (surprise surprise) that Apple may or may not be supporting, if they are supporting the Exchange SUBSCRIBE method, they'll be doing it through their proxy notification system if they want to conserve the device's battery life. The SUBSCRIBE method gets routed through the service, which maintains a proxy session, waiting for a response from the Exchange server, which then gets held upon receipt while the iPhone sees an inbound ACIN that it knows means it should pull from the proxy service.
That's an architecture requiring a license and cooperation from Microsoft that doesn't conflict with the iPhone's basic operating principles. It means that there's probably zero Microsoft code executing on the device, unless Apple convinced MSFT to write the Objective-C code that parses the Exchange XML syntax for calendars and contacts into iCal and vCard.
It's also an architecture that IBM most definitely doesn't have. At all.
The way Traveler handles mobile device sync is based on a substantially different approach using SyncML, which is an open format, with a lot of detail. Actions performed on content operations are bundled as XML wrappers, rather than embedded in the HTTP method headers as they are with webDAV. In short, SyncML works more like a web service than files on a web site. SyncML is certainly broadly supported, with a long list of participant companies in the Open Mobile Alliance. But Apple is conspicuously absent from the list.
Does this mean that IBM picked a bad strategy for mobile devices? I can't really think so. I certainly think they lagged behind, but honestly, if Traveler had shipped three years ago, it still would have been fundamentally incompatible with the way Apple was already managing it's PIM sync. Would Apple have shifted their approach to accommodate IBM? I doubt it. And yet IBM still has a strategy that's suitable for the billion-device cell market that's already out there.
Brent Peters says that the iPhone is a priority and that IBM is doing the heavy-lifting to get compatibility there. I'm sure we don't know how this will work until it's done, but the most likely approach seems adding a webDAV layer to Traveler to make it behave like MobileMe. We already know that Notes/Domino 8.5 works nicely with iCal and vCard.
But I could be completely off base here. It might turn out that all this technology works completely differently from my speculation. We really won't be able to tell until either one of the players tells us, or we can get one of the devices and play with it. (My wife already has an AT&T account, so hopefully she'll appreciate her belated birthday gift on July 10th.) Even then, we might not be able to really see what's happening until Apple's Push service goes live in September.
What I do hope is clear from all this research is that the decisions on what can be supported on the iPhone is really up to Apple. The most that any partner can hope to do is be where Apple wants them to be at decision time. I'm sure there was more to the situation than the fact that MSFT had a webDAV API in the can, while IBM had a SyncML API in the can, and so it was just easier for Apple to work with MSFT. There's no way that's the end of the story.
So I'm definitely looking forward to how this unfolds in the future. I think seeing what the iPhone actually does in July is going to be very revealing.
Comments
As you say, we'll have to wait and see what is actually delivered, but you present a compelling hypothesis.
Critically, one of the major concerns seems to be integration with the iPhones native mail / PIM apps. Even if the notification service allowed for the activation of a third party app, which could then sync up, it would not help native integration.
I'm also not clear what the notification service will actually offer. Will an app actually get woken up? Some reports seem to suggest that the notification will play a sound and add some visual indication to an app's icon, but not actually wake it up.
Ultimately, unless apple and IBM work together we are unlikely to see a compelling Lotus solution on the iPhone. So the question is, does apple care enough to make the effort and does IBM care enough to make it happen?
Posted by Kerr At 05:01:43 AM On 06/19/2008 | - Website - |
I know that IBM would like to get that integration done. The aforementioned vice president was very clear about his own urgency on the matter.
Posted by Nathan T. Freeman At 06:34:28 AM On 06/19/2008 | - Website - |
Posted by Kerr At 08:08:15 AM On 06/19/2008 | - Website - |
As you say, next month will be interesting.
Posted by Ben Poole At 08:13:05 AM On 06/19/2008 | - Website - |
For me the push mail is not very important. The most important is to keep my agenda up-to-date on my mobile device. It's nice to know what tomorrow will look like instantaneously from your mobile gadget.
I thought that I've read somewhere that IBM\Lotus were supposed to release WebCal in Notes/Domino 8. Since it's not in 8.5 Beta1, maybe someone know when it'll be available?
I have the pleasure to use an iPhone and it's really a wonderful device.
Could all the turmoil that has fueled PlanetLotus recently would have occurred if someone at IBM\Lotus took the time to write such a detailed post?
Posted by Pierre Lalonde At 08:27:45 AM On 06/19/2008 | - Website - |
Posted by Chris Whisonant At 11:31:11 AM On 06/19/2008 | - Website - |
Don't forget, it's also a floor wax AND a dessert topping!
{ Link }
Posted by Timothy Briley At 12:07:01 PM On 06/19/2008 | - Website - |
-Devin.
Posted by Devin Olson At 04:44:56 PM On 06/19/2008 | - Website - |
@Nathan: It's somewhat confusing but (Exchange ActiveSync != Exchange WebDAV). They both support syncing but WebDAV was intended to be a more general programmatic interface. And Exchange ActiveSync does compression and uses less bandwidth than WebDAV. Exchange WebDAV has been deprecated. ActiveSync has not.
Exchange WebServices is a newer programmatic interface. Not ironic at all. It's easier to use than WebDAV. WebDAV may be a simple protocol but its difficult to use for certain types of operations (e.g. schedule a meeting, check someone's free/busy status). From what I've read, Apple is including support for EWS in Snow Leopard and is using Exchange ActiveSync on the iPhone.
ActiveSync does *not* require a persistent connection. It's an option. Mobile devices can poll instead. The main advantage to direct push is immediate notifiction rather than relying on a polling cycle.
Regarding battery life, I wonder how Apple handles IMAP on the iPhone. IMAP is session-oriented but how long they keep the connection open?
Tangential topic: the sync protocol used in Workplace between server and client was SyncML.
Posted by Bob Congdon At 05:47:26 PM On 06/19/2008 | - Website - |
So, in that case, what DOES Exchange ActiveSync use to sync? The documentation says it's an HTTP transport, but doesn't specify the innards of the protocol.
Do you know whether Apple is running any Microsoft-authored code on the iPhone 2.0? I would find that surprising, but enlightening.
And yes, if I wasn't clear in the write up, ActiveSync's DirectPush requires a persistent connection. There are modes of operation other than direct push. But push notification is what all the enterprise buzz is about. Anybody can poll mail -- the iPhone already does that every 15 minutes. (Which is how they handle IMAP today.)
If Snow Leopard is using EWS for sync, then Domino will not be left out of the equation for long.
Posted by Nathan T. Freeman At 07:02:44 AM On 06/20/2008 | - Website - |
Posted by Bob Congdon At 11:11:46 AM On 06/20/2008 | - Website - |