iPhone Push Notification
Server tied to Snow Leopard Server
By Prince McLean
Published: 09:00 AM EST
AppleInsider
Despite licensing the proprietary ActiveSync
Exchange Server protocol from Microsoft for use
with the iPhone, Apple is building its own Push
Notification Server for messaging services in
both the iPhone and Mac OS X Snow Leopard Server
using open, interoperable standards.
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 e-mail,
delivery is always push; sending an e-mail immediately
pushes it to the server using the outgoing e-mail
SMTP service. The client can always push out
e-mail because it knows where the SMTP e-mail server
is supposed to be.
In
contrast, the incoming POP3 or IMAP mail
server doesn't typically track the location
of the e-mail client, meaning that new e-mails
sit on the server until the client system
manually checks for e-mail. 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 e-mails on the server
results in frequent network connections that
usually result in discovering that no new e-mails
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 e-mail 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 e-mail 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 e-mail 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 e-mail, 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.
e-mail push messaging doesn't require messages to
run through Sync Services (like calendar and
contact updates) because the incoming e-mail 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 e-mail to the client, the server sends
a notification of new e-mail 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 e-mail,
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.
Snow Leopard 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 e-mails,
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 e-mail 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 e-mail 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. |