Prince McLean
However, the company's pioneering, yet protracted leap into push messaging indicates that notification technology can be more complex that it seems, having delayed Apple's intended deadline for shipping PNS by many months.
The push for push messaging
Push messaging relates to information that is sent immediately rather than queuing up on a server, waiting to be picked up. In conventional email, delivery is always push; sending an email immediately pushes it to the server using the outgoing email SMTP service. The client can always push out email because it knows where the SMTP email server is supposed to be.
In contrast, the incoming POP3 or IMAP mail server doesn't typically track the location of the email client, meaning that new emails sit on the server until the client system manually checks for email. This polling process (Apple calls it "fetch") is often set to occur on a schedule, as often as every few minutes. With mobile devices, having to rapidly poll for new emails on the server results in frequent network connections that usually result in discovering that no new emails are available.
The original goal of push messaging was to provide battery savings for mobile devices by having the server track the location of the device so that the server could both push out updates immediately and only when necessary, sparing the mobile device from having to fruitlessly poll for data to stay current.
RIM vs Microsoft in push messaging
The added luxury of having the server track the location of email clients came at a steep price: RIM's highly profitable BlackBerry empire was not built on hardware sales, but rather from service revenues related to licensing its BlackBerry Enterprise Server (BES) software, which is used to track mobile devices and relay them new messages from the corporate email system as they arrive.
Microsoft's Exchange ActiveSync (EAS) software (which has only its name in common with the company's unrelated desktop sync tool) duplicates the role of RIM's BES as an add-on mobile device tracker for facilitating push messaging. Both systems also allow IT administrators to manage the devices they track, limiting the software users can install or remotely wiping a lost or stolen unit, for example.
Apple licensed Microsoft's EAS for iPhone 2.0 rather than introducing its own competing push system, a decision which made the iPhone immediately useable for many businesses who already owned EAS infrastructure, or at least already used Exchange Server and could easily set up EAS for use with the iPhone at no additional cost.
Apple pushes back with MobileMe
At the same time, Apple also completed its own push messaging system for use with .Mac and delivered this alongside EAS in the iPhone 2.0 update. The new cloud push service and the existing .Mac services were fused together to create MobileMe, which allowed home users to enable push messaging on the iPhone without needing an Exchange Server account. In contrast with Microsoft's soon to be officially unveiled My Phone for Windows Mobile users (formerly known as SkyBox), MobileMe supports users' existing email accounts and contacts and also provides data sync with their desktop apps, in addition to web hosting and video uploads.
When an iPhone is set up to perform push messaging with MobileMe, it registers with Apple's cloud servers, which then track its location on the network so that new email, contacts, calendar, and browser bookmarks can be immediately delivered over the air the instant they change on the server, without continuous polling by the device.
MobileMe can also push updates to desktop client computers that register with the service. On Mac OS X, once users enable push messaging, the system registers its location with Apple's cloud servers and updates are pushed to Sync Services, which then distributes the updates to Address Book, iCal, Safari, and any other apps that register with that system. On Windows, iTunes handles the syncing of contacts, events, and bookmarks via a Control Panel interface, and sends new data to the configured Windows apps.
Email push messaging doesn't require messages to run through Sync Services (like calendar and contact updates) because the incoming email IMAP-IDLE service supports the ability for the client to inform the server that it will accept new message notifications. This means that rather than pushing the entire email to the client, the server sends a notification of new email when it arrives at the server, giving the client software the option of downloading it immediately. This is more flexible than a straight push, because the system may want to delay the downloading a large email, particularly if the system is mobile and the user only wants to download full messages when a fast connection is available.
Apple's Push Notification Server
Last year, Apple introduced plans at WWDC to provide a third push mechanism for the iPhone, in addition to EAS support and MobileMe. Rather than pushing updated contacts or calendar messages, the new Push Notification Server (PNS) would allow third party developers to push notifications of any type to the iPhone, which would then badge the application's icon, alerting users that the application had new information waiting for it.
Apple's long-lost Push Notification Service would funnel notification data from third party servers through its own, and then on to users' iPhones.
That application, once started, could then download (or offer to download) whatever new data the notification server had alerted it to. For example, an IM provider might push notifications of new messages to the iPhone in order to badge its specific IM app. A mobile app that presents news, stock events, or some other information via an RSS feed could similarly be badged by the developer via PNS.
PNS was intended in part to allow third party iPhone apps to reflect regular new updates, pushed over the air, without the apps actually needing to stay active in the background listening for updates themselves (and eating up memory and processor cycles while waiting around). Instead, the iPhone would triage all the push notifications itself and badge the apps' icons so users and developers could both benefit from push notifications as efficiently as possible, and without developers needing to implement their own notification system.
Originally due last September, the service would allow iPhone developers to push three kinds of notifications to users' iPhones: badges, alert sounds, and textual messages.
However, Apple indicated that PNS was supposed to ship by last September. That deadline came and went, and the service was never rolled out. Apple released a developer seed with a PNS API, but the company noted that "this API is not yet integrated with a live push server." It appears that PNS ran into unforeseen complications. Apple hasn't given up though; the company itself uses a notification system to push badge updates on the App Store's icon, which then has to be launched to check with the iTunes server of what those notifications actually are, behavior identical to that described for PNS.
With the App Store icon, neither the actual software updates nor even their descriptions are automatically pushed to the phone; its badge is simply incremented by, presumably, PNS. However, the system isn't yet fully operational even for internal use; sometimes apps are available but aren't reflected with a new badge increment, and sometimes the badged number doesn't match the software updates that are actually available. Apple has been working similar kinks out of iTunes, which also tracks available iPhone software updates with less than perfect results.
The progression of a notification badge being sent from a server belonging to a third-party iPhone developer to an iPhone running the developer's application.
Apple has historically allowed a number of technologies to languish as it focuses on the most promising and profitable products to invest its resources in. That's good news for anyone wondering if the company's PNS will ever see the light of day, as the company has so much riding on it. Unlike Apple TV, iCal, and other projects that seem to have taken a long time to develop as back burner hobbies due to the lack of any real revenue stream to justify their development, Apple's PNS is directly related to immediately profitable, high priority projects from the iPhone to MobileMe to iTunes to Snow Leopard Server.
On page 2 of 2: Snow Leopard Push; and Instant messaging is always push.
While Snow Leopard's Mail, iCal, and Address Book are set to gaining high profile support for Exchange Server messaging, they're also being updated to support open push messaging with Apple's own Snow Leopard Server. Rather than being based on EAS, Apple's own server push products are based on interoperable, open standards, the same as PNS.
Apple's iCal Server, which the company debuted both in Leopard Server and as an open source CalDAV calendar server project, is being updated to use XMPP publish-subscribe, an IETF open standard branching from the core of the Jabber IM service. That means Snow Leopard's iCal Server 2 will push calendar updates to clients using extended instant messages, making it an inherently push service. Like IMAP-IDLE, the system only sends a lightweight notification that new data has arrived, leaving iCal to fetch the new data itself in response.
In contrast, Microsoft's Exchange Server handles calendar events and other data as specially formatted emails, requiring additional infrastructure (RIM' BES or Microsoft's EAS) to supply push functionality for immediate updates. That also requires Microsoft to support a separate set of protocols when talking to desktop clients (MAPI) and mobile devices (EAS).
Instant messaging is always push
The main difference between IM and email is that IM is inherently push. That's because the IM service constantly monitors the location of the client, enabling it to send rapid updates in both directions. The presence indicator systems that IM users must log into required more infrastructure than typical email servers did, resulting in an initial domination of the IM business by proprietary protocols from AOL, Yahoo, and MSN. However, the Jabber project has since introduced an open source IM protocol that has expanded to become the eXtensible Messaging and Presence Protocol (XMPP).
Apple began embracing XMPP in Mac OS X Tiger, with iChat gaining Jabber support on the desktop (next to AOL's proprietary IM protocol), and iChat Server being entirely based upon the open Jabber XMPP specification. That allowed iChat to work with other Jabber IM providers that appeared, including Google's GTalk.
In Snow Leopard Sever, iCal Server is paired with a Notification Server to provide push calendar updates using XMPP's publish-subscribe specification. Also known as pubsub, the service works like a "push RSS feed," so rather than polling an RSS file on a server to discover new updates, the Notification Server pushes out just what's changed to all of the clients who have subscribed to the update system (and who have been authenticated to receive updates). In some respects, the Notification Server is like a secured Twitter feed, with iCal server sending tweets to listening iCal clients to keep them abreast of changes.
Security is important to users who only want to notify themselves, their delegates, and their mobile devices of updates on their server-based calendar. Apple's PNS has similar requirements; adequate security is required to make sure that only a known developer is able to send notification updates through the system, and that only updates requested by the user are sent to their specific phone. Last year's WWDC attendees described Apple's PNS as a secured web service that simply relayed tiny XML messages. Why not use the same XMPP system to relay notification updates to the iPhone as will be used to deliver push calendar and contact notifications? That may be exactly what Apple has in mind, tying the release of PNS with the completion of Snow Leopard Server's own Notification Server.
-m.jpg)
Charles Martin
Christine McKee
Wesley Hilliard
Malcolm Owen
Andrew Orr
William Gallagher
Sponsored Content
41 Comments
Er... this sounds like a non-story. Is PNS vaporware or not?
So called "push" notification has always come across as a bit of fiction to me. If my device is sleeping, there is no magical way a remote server can wake my device and force a message upon it. Somewhere underneath the hood, the device is waking up, connecting to the server and accepting messages. The rest is just media hype.
So called "push" notification has always come across as a bit of fiction to me. If my device is sleeping, there is no magical way a remote server can wake my device and force a message upon it. Somewhere underneath the hood, the device is waking up, connecting to the server and accepting messages. The rest is just media hype.
Your device is never really sleeping. Only the display is sleeping. Whenever it changes locations it sends out its new position (cell tower used, IP address etc.) to the mobile operator and to any push notification servers it is linked to (like .me). How do you think you receive SMS or phone calls on your device?
Bottom line is...Is this going to be better in some way than RIM's BES solution? Will it be cheaper? Or will it still be missing some features that companies will claim it's not secure enough or whatever. RIM seems to own the push-email business and after all these years hasn't been challenged at all. I think large corporations still believe the iPhone is just a toy and won't touch it.
So called "push" notification has always come across as a bit of fiction to me. If my device is sleeping, there is no magical way a remote server can wake my device and force a message upon it. Somewhere underneath the hood, the device is waking up, connecting to the server and accepting messages. The rest is just media hype.
You can receive SMS and phone calls while your phone is "sleeping" because your phone is still maintaining your cell connection. Sleeping does not mean the device is off. You can even setup your PC to wake on LAN access. The notification server can work in a similar fashion. A simple process runs in the background while pretty much everything else is dormant.
Apple may have changed their direction with PNS. The original system seems to be a separate system to the phone's default systems to monitor any updates. I think a better method that would reduce processing overhead would be to use your cell provider's control channel that it uses to transmit SMS over. In other words, when the notification server gets an update it sends it out as a specially formatted SMS that the iPhone will recognize as an atypical SMS. this prevents you getting it as a normal text message, but as the badge, vibration and/or popup that is allowed. The use of the provider's control channel means that messages can come even even you can't access data( GPRS/EDGE/UMTS) via the cell carrier. Of course, this would cause problems with iPod Touch users or iPhones who are on WiFi but are in a dead cell area. Just a thought.