しかし、同社のプッシュメッセージングへの先駆的かつ長期にわたる取り組みは、通知テクノロジーが見た目以上に複雑になり得ることを示し、Apple が予定していた PNS の出荷期限を数か月延期した。
プッシュメッセージングの推進
プッシュメッセージングとは、サーバー上でキューイングされて受信を待つのではなく、即座に送信される情報を指します。従来の電子メールでは、配信は常にプッシュ方式です。メールを送信すると、送信メール用のSMTPサービスを使用して、即座にサーバーにプッシュされます。クライアントはSMTPメールサーバーの場所を認識しているため、常にメールをプッシュ送信できます。
一方、受信側のPOP3またはIMAPメールサーバーは通常、メールクライアントの位置を追跡しません。つまり、クライアントシステムが手動でメールを確認するまで、新着メールはサーバー上に残ります。このポーリングプロセス（Appleは「フェッチ」と呼びます）は、多くの場合、数分間隔などのスケジュールに従って実行されるように設定されています。モバイルデバイスでは、サーバー上の新着メールを迅速にポーリングする必要があるため、ネットワーク接続が頻繁に発生し、その結果、新着メールがないことが判明することがよくあります。
プッシュ メッセージングの本来の目的は、モバイル デバイスのバッテリーを節約するために、サーバーがデバイスの位置を追跡し、サーバーが必要な場合にのみ更新を即時にプッシュできるようにすることで、モバイル デバイスが最新の状態を維持するために無駄にデータをポーリングする必要がないようにすることです。
プッシュメッセージングにおけるRIM対Microsoft
サーバーに電子メールクライアントの位置を追跡させるという贅沢な機能には、大きな代償が伴った。RIM の非常に利益率の高い BlackBerry 帝国は、ハードウェアの販売ではなく、BlackBerry Enterprise Server (BES) ソフトウェアのライセンスに関するサービス収入で築かれたものだった。BES は、モバイル デバイスを追跡し、企業の電子メール システムから新着メッセージが届くとそれを中継するために使用される。
MicrosoftのExchange ActiveSync（EAS）ソフトウェア（同社の無関係なデスクトップ同期ツールと名称のみが共通）は、プッシュメッセージングを容易にするアドオン型モバイルデバイストラッカーとして、RIMのBESと同様の機能を備えています。また、両システムともIT管理者が追跡対象デバイスを管理し、ユーザーがインストールできるソフトウェアを制限したり、紛失・盗難されたデバイスをリモートで消去したりすることも可能です。
Apple は、競合する独自のプッシュ システムを導入するのではなく、iPhone 2.0 用に Microsoft の EAS のライセンスを取得しました。この決定により、すでに EAS インフラストラクチャを所有している、または少なくとも Exchange Server を使用していて、追加コストなしで iPhone で使用できるように EAS を簡単に設定できる多くの企業が、すぐに iPhone を使用できるようになりました。
AppleがMobileMeで反撃
同時に、Appleは.Mac向けの独自のプッシュメッセージングシステムも完成させ、iPhone 2.0アップデートでEASと併せて提供しました。この新しいクラウドプッシュサービスと既存の.Macサービスが統合され、MobileMeが誕生しました。これにより、ホームユーザーはExchange Serverアカウントを必要とせずにiPhoneでプッシュメッセージングを利用できるようになりました。MicrosoftがまもなくWindows Mobileユーザー向けに正式発表するMy Phone（旧称SkyBox）とは対照的に、MobileMeはユーザーの既存のメールアカウントと連絡先をサポートし、デスクトップアプリとのデータ同期に加え、ウェブホスティングや動画アップロード機能も提供します。
iPhone が MobileMe でプッシュ メッセージングを実行するように設定されている場合、iPhone は Apple のクラウド サーバーに登録されます。クラウド サーバーはネットワーク上の iPhone の位置を追跡するため、デバイスによる継続的なポーリングなしに、サーバー上で新しい電子メール、連絡先、カレンダー、ブラウザーのブックマークが変更された瞬間に、それらを無線で配信できます。
MobileMeは、サービスに登録されているデスクトップクライアントコンピュータにアップデートをプッシュすることもできます。Mac OS Xでは、ユーザーがプッシュメッセージを有効にすると、システムがAppleのクラウドサーバーに位置情報を登録し、アップデートがSync Servicesにプッシュされます。Sync Servicesは、アドレスブック、iCal、Safari、その他システムに登録されているアプリにアップデートを配信します。Windowsでは、iTunesがコントロールパネルのインターフェースを介して連絡先、イベント、ブックマークの同期を行い、設定されたWindowsアプリに新しいデータを送信します。
メールプッシュメッセージでは、受信メールのIMAP-IDLEサービスが、クライアントがサーバーに新着メッセージ通知を受け入れることを通知する機能をサポートしているため、メッセージが同期サービス（カレンダーや連絡先の更新など）を通過する必要がありません。つまり、メール全体をクライアントにプッシュするのではなく、サーバーは新着メールがサーバーに到着した時点で通知を送信し、クライアントソフトウェアにすぐにダウンロードするオプションを提供します。これは、システムがモバイル端末で、ユーザーが高速接続が利用可能な場合にのみメッセージ全体をダウンロードしたい場合など、システムが大容量メールのダウンロードを遅らせる可能性があるため、直接プッシュするよりも柔軟性に優れています。
Appleのプッシュ通知サーバー
昨年のWWDCで、AppleはEASサポートとMobileMeに加え、iPhone向けに第3のプッシュメカニズムを提供する計画を発表しました。新しいプッシュ通知サーバ（PNS）は、連絡先の更新やカレンダーメッセージなどのプッシュ通知ではなく、サードパーティの開発者があらゆる種類の通知をiPhoneにプッシュできるようにします。プッシュ通知はアプリケーションアイコンにバッジとして表示され、ユーザーにアプリケーションに新しい情報があることを知らせます。
Apple の長らく失われていたプッシュ通知サービスは、サードパーティのサーバーから自社のサーバーを経由して通知データを集め、ユーザーの iPhone に届けるものでした。
アプリケーションは起動すると、通知サーバーから通知された新しいデータをダウンロード（またはダウンロードを提案）できるようになります。例えば、IMプロバイダーは、自社のIMアプリにバッジを付けるために、新着メッセージの通知をiPhoneにプッシュ送信するかもしれません。ニュース、株価情報、その他の情報をRSSフィードで提供するモバイルアプリにも、開発者がPNS経由で同様にバッジを付けることができます。
PNSの目的の一つは、サードパーティ製のiPhoneアプリが、ワイヤレスでプッシュされる定期的なアップデートを反映できるようにすることでした。アプリはバックグラウンドでアップデートを待機する必要がなく（待機中にメモリとプロセッササイクルを消費する）、アップデートを定期的に受け取ることができました。iPhoneはすべてのプッシュ通知を自ら選別し、アプリのアイコンにバッジを表示することで、ユーザーと開発者の双方がプッシュ通知を最大限効率的に活用できるようにしました。開発者は独自の通知システムを実装する必要はありません。
当初は昨年9月に予定されていたこのサービスにより、iPhone開発者はバッジ、警告音、テキストメッセージの3種類の通知をユーザーのiPhoneにプッシュできるようになる。
しかし、AppleはPNSを昨年9月までにリリースする予定だと発表していました。しかし、その期限は過ぎ、サービスは結局提供されませんでした。AppleはPNS APIを搭載した開発者向けシードをリリースしましたが、「このAPIはまだライブプッシュサーバーに統合されていません」と記載されていました。PNSは予期せぬ問題に直面したようです。しかし、Appleは諦めていません。Apple自身もApp Storeアイコンのバッジ更新をプッシュする通知システムを使用しており、その後、iTunesサーバーに通知内容の確認を依頼するためにアイコンを起動する必要があり、これはPNSの場合と全く同じ動作です。
App Storeアイコンでは、実際のソフトウェアアップデートもその説明も自動的にはスマートフォンにプッシュされません。バッジは、おそらくPNSによって増加するだけです。しかし、このシステムは社内利用でさえまだ完全には機能していません。アプリが利用可能であってもバッジの数が反映されない場合があり、バッジの番号と実際に利用可能なソフトウェアアップデートの数が一致しないこともあります。AppleはiTunesでも同様の不具合を修正しており、iTunesもiPhoneの利用可能なソフトウェアアップデートを追跡していますが、結果は完璧とは言えません。
サードパーティの iPhone 開発者のサーバーから、開発者のアプリケーションを実行している iPhone に通知バッジが送信される様子。
Appleはこれまで、最も有望で収益性の高い製品にリソースを集中させるため、多くの技術を放置してきました。PNSが日の目を見るかどうか疑問に思っている人にとっては朗報です。PNSはAppleにとって非常に重要な製品だからです。Apple TV、iCal、そして開発を正当化する実質的な収益源がないため、趣味の傍観者として長い時間をかけて開発されてきた他のプロジェクトとは異なり、AppleのPNSは、iPhone、MobileMe、iTunes、Snow Leopard Serverなど、すぐに利益を生む優先度の高いプロジェクトに直接関連しています。
2 ページ中 2 ページ目: Snow Leopard プッシュ。インスタント メッセージングは常にプッシュです。
Snow Leopardのメール、iCal、アドレスブックは、Exchange Serverメッセージングの強力なサポートを獲得するだけでなく、Apple独自のSnow Leopard Serverによるオープンプッシュメッセージングをサポートするようにアップデートされます。Apple独自のサーバープッシュ製品は、EASベースではなく、PNSと同様に相互運用可能なオープンスタンダードに基づいています。
AppleのiCal Serverは、Leopard ServerとオープンソースのCalDAVカレンダーサーバプロジェクトの両方でデビューしましたが、Jabber IMサービスのコアから派生したIETFオープンスタンダードであるXMPP publish-subscribeを採用するようにアップデートされました。つまり、Snow LeopardのiCal Server 2は、拡張インスタントメッセージを使用してクライアントにカレンダーの更新情報をプッシュ配信するようになり、本質的にプッシュ型のサービスとなります。IMAP-IDLEと同様に、システムは新しいデータが到着したという軽量な通知のみを送信し、iCalはそれに応じて新しいデータを取得します。
一方、MicrosoftのExchange Serverは、カレンダーイベントやその他のデータを特別な形式のメールとして処理するため、即時更新のためのプッシュ機能を提供するには、追加のインフラストラクチャ（RIMのBESまたはMicrosoftのEAS）が必要になります。また、Microsoftはデスクトップクライアント（MAPI）とモバイルデバイス（EAS）との通信にそれぞれ異なるプロトコルセットをサポートする必要があります。
インスタントメッセージは常にプッシュ型
IMと電子メールの主な違いは、IMが本質的にプッシュ型であるということです。これは、IMサービスがクライアントの位置を常に監視し、双方向に迅速な更新情報を送信できるためです。IMユーザーがログインする必要があるプレゼンス・インジケータ・システムは、一般的な電子メールサーバーよりも多くのインフラストラクチャを必要としました。その結果、IMビジネスは当初、AOL、Yahoo!、MSNなどの独自プロトコルが独占していました。しかし、その後、JabberプロジェクトがオープンソースのIMプロトコルを導入し、それがeXtensible Messaging and Presence Protocol（XMPP）へと発展しました。
AppleはMac OS X TigerでXMPPを採用し始め、iChatはデスクトップ版のJabber（AOL独自のIMプロトコルに加え）をサポートしました。また、iChat ServerはオープンなJabber XMPP仕様に完全準拠しました。これにより、iChatはGoogleのGTalkなど、当時登場した他のJabber IMプロバイダとも連携できるようになりました。
Snow Leopard Server では、iCal Server は Notification Server と連携し、XMPP の publish-subscribe 仕様に基づいたプッシュカレンダー更新を提供します。pubsub とも呼ばれるこのサービスは、「プッシュ RSS フィード」のように動作します。つまり、サーバー上の RSS ファイルをポーリングして新しい更新を検出するのではなく、Notification Server は更新システムにサブスクライブしている（そして更新の受信が認証されている）すべてのクライアントに変更内容だけをプッシュ送信します。ある意味では、Notification Server は安全な Twitter フィードのようなもので、iCal Server がリッスンしている iCal クライアントにツイートを送信して、変更内容を常に把握できるようにします。
セキュリティは、サーバーベースのカレンダーの更新を自分自身、代理人、モバイル デバイスにのみ通知したいユーザーにとって重要です。Apple の PNS にも同様の要件があり、既知の開発者だけがシステムを通じて通知更新を送信できること、そしてユーザーが要求した更新のみが特定の電話に送信されることを保証するために、十分なセキュリティが必要です。昨年の WWDC 参加者は、Apple の PNS を、小さな XML メッセージを単に中継する安全な Web サービスだと説明しました。プッシュ カレンダーや連絡先通知を配信するのと同じ XMPP システムを使用して、通知更新を iPhone に中継するのはなぜでしょうか。Apple がまさにそれを念頭に置いていることかもしれません。Apple は、PNS のリリースを Snow Leopard Server 独自の通知サーバーの完成と結び付けています。
