次の方法で共有

  • [アーティクル]

February 2009

Volume 24 Number 02

いろいろな場所へ - SyncML を使用したモバイル デバイスのプロビジョニング

Ramon Arjona | February 2009

目次

OMA について
SyncML: 同期の XML
SyncML 要素
SyncBody 要素
その他の情報
SyncML を使用する

MSDN Magazine の 2008 年 4 月号の「いろいろな場所へ」コラムで、Mike Calligaro は XML ファイルと DMProcessConfigXML API を使用した Windows Mobile デバイスのプロビジョニングについて説明しました。Mike が使用した XML ファイルは、デバイス管理のための Open Mobile Alliance (OMA) Client Provisioning (OMA-CP) 標準に基づいています (以前はワイヤレス アプリケーション プロトコル (WAP) と呼ばれていました)。

OMA-CP は、複数のデバイスの管理において問題なく動作します。Mike のコラムでは、プロビジョニング情報を複数のデバイスに一度に提供する方法が提案されていました。しかし、何千というデバイスに対して長期間にわたる体系的なプロビジョニングが必要な場合はどうでしょうか。また、管理対象デバイスに既に構成されているソフトウェアおよびレジストリ設定を知る必要がある場合はどうでしょうか。

このような連携された大規模なプロビジョニング作業は、OMA Device Management (OMA-DM) の領域です。OMA-DM プロトコルは、SyncML と呼ばれる XML 言語に基づいています。エンタープライズ シナリオで OMA-DM を使用して、モバイル デバイスのプロビジョニングと管理を行うことができます。このコラムでは、OMA-DM プロトコルで使用される SyncML ドキュメントの構造について説明します。デバイスのリモート ワイプなど、Windows Mobile プラットフォームの具体的な利用シナリオも紹介します。さらに、OMA-DM と共に Mike のコラムにある XML を使用して、お気に入りのブラウザをデバイスに設定する方法も示します。

OMA について

OMA とは、200 を超える携帯電話会社、モバイル デバイス製造元、およびソフトウェア ベンダー (Microsoft を含む) で構成される業界グループです。OMA は 2002 年に、市場に登場して急速に拡大しつつあったモバイル デバイス標準 (WAP、Device Management、SyncML など) を管理する単一のグループとして設立されました。グループの多様性によって作業が重複していたため、関連する業界パートナーが集合して、これらの重要なイニシアティブをすべて単一の組織にまとめることが目的でした。

OMA 標準を使用することにより、テクノロジ間のやり取りの一般的な方法を作成して、モバイル デバイスおよびネットワークをより簡単に使用できるようになりました。SyncML および OMA-DM は、このオープン プロトコル ファミリの 2 つの要素です。すべてのプロトコル同様、これらには一定の解釈があり、各ベンダーは固有の付加価値を付けた拡張機能を自由に提供できます。ベンダーごとに異なる形式でネゴシエートするよりも、各ベンダーから提供される拡張機能を利用する方がより簡単で単純です。

SyncML: 同期の XML

SyncML は、XML ベースのマークアップであり、OMA で定義されるほとんどのプロトコルの基本として使用されます。SyncML ドキュメントはメッセージと呼ばれます。メッセージは、有効な XML でなくてもかまいませんが、適正に作成された XML である必要があります。つまり、すべての要素で開始タグと終了タグが一致し、各属性が引用符で囲まれているなど、XML と名の付くドキュメントに不可欠な適性化の基本的な定義に準拠している必要があります。

SyncML 文書型定義 (DTD) はありますが、送信側または受信側でこの定義を検証する必要はありません。その理由の 1 つは、モバイル デバイスで検証に必要なリソース (追加のメモリおよびプロセッサ時間) を十分に確保できない場合が多いことです。メッセージには、特定の OMA プロトコルの複雑な作業を扱うコマンド要素が含まれます。

SyncML および OMA-DM はトランスポートに依存しません。HTTP および Object Exchange (OBEX) 用に定義されたトランスポート バインドがあり、他のバインドを定義することもできます。このため、SyncML および OMA-DM はデバイスのプロビジョニングに適したプロトコルです。要件を満たしたデバイス管理サーバーで SyncML および OMA-DM を使用する場合は、メモリ カードを使う必要もなく、デバイスをつなぐこともなく、Web サイトへのアクセスなどエンド ユーザーによる操作も要求されません。

概念的に、1 つ以上のメッセージが SyncML パッケージに含まれます。SyncML パッケージには、受信側と送信側でやり取りされたメッセージがすべて収められます。

SyncML 要素

SyncML ドキュメントは、ルート SyncML 要素、SyncHdr 要素により定義されたヘッダー、および SyncBody 要素により定義された本文で構成されています。SyncML ドキュメントのルートは、常に、次のような SyncML 要素です。

<SyncML xmlns='SYNCML:SYNCML1.1'>
...
</SyncML>

SyncML 要素には、SyncHdr 子要素と SyncBody 子要素が含まれています。SyncHdr 要素は、図 1 に示すようなマークアップです。この短いヘッダーにより、受信側でメッセージを処理するために認識する必要のある情報がすべて示されています。

図 1 SyncHdr

<SyncHdr>
  <VerDTD>1.2</VerDTD>
  <VerProto>DM/1.2</VerProto>
  <SessionID>1</SessionID>
  <MsgID>1</MsgID>
  <Target>
    <LocURI>https://mgmt.contoso.com/ </LocURI>
  </Target>
  <Source>
    <LocURI>urn:uuid:6D67E196-D082-4c91-A0DD-DEB3D1D58EB5</LocURI>
    <LocName>MyDeviceName</LocName>
  </Source>
  <Cred>
    <Meta>
      <Format xmlns="syncml:metinf">b64</Format>
      <Type xmlns="syncml:metinf">syncml:auth-md5</Type>
    </Meta>
    <Data>ODZlMDNiYmM1MjA1YTI3MDc5MDk2MDcwYTA4OGM2Zjg=</Data>
  </Cred>
</SyncHdr>

VerDTD 要素は、受け取ったメッセージが OMA により定義された SyncML Representation Protocol Version 1.2 に準拠していることを示しています。同様に、VerProto 要素は、受け取ったメッセージが OMA-DM プロトコル Version 1.2 に準拠していることを示しています。バージョン番号は同じですが、この 2 つは異なります。SyncML は、デバイス管理プロトコル (このコラムで後述します) やデータ同期プロトコル (SyncML は本来、このために設計されました) などさまざまな OMA プロトコルで使用されます。

SessionID 要素は、受け取ったメッセージがどの SyncML セッションであるかを示しています。この ID の値の最大長は 4 バイトです。

MsgID は、セッション内の一意の ID です。これは、送信側と受信側の会話を追跡するために使用されます。受信側が結果によって応答する場合、MsgRef 要素に MsgID を含めることにより、この結果を要求した応答先メッセージを参照します。

Target 要素は、メッセージの受信側がだれなのかを示すものです。Source 要素は、メッセージの送信側がだれなのかを示すものです。これら 2 つの要素には両方とも、送信側と受信側を一意に識別するための文字列を含む LocURI 要素が収められています。Target および Source の LocURI は、URL、URI、または URN である必要があります。通常、管理サーバーには既に一意の DNS 名があるので、管理サーバーが送信側または受信側である場合は、LocURI 内に管理サーバーの完全修飾ドメイン名が表示されるのが一般的です。

Target 要素も Source 要素も、メッセージのアドレス指定またはルーティングに直接的に関連していない点に注意してください。これらのタスクは、デバイス管理アプリケーションおよび対応するトランスポート プロトコルによって行われます。

モバイル デバイスは、GUID を参照する URN によって参照されることがよくあります (RFC 4122 により定義されています)。GUID は、アドレス指定される特定のデバイスを一意に参照します。この GUID からネットワークで到達可能なアドレスへのマッピングは、アプリケーションに依存します。GUID は通信先デバイスを特定できる直感的な方法ではないため、アプリケーションによって、SyncML メッセージの発信元デバイスの名前を保持する LocName 要素が Source 要素に追加されました。

最後に、Cred 要素には送信側を識別する情報が含まれています。この要素には、メッセージで SyncML 標準により定義された MD5 認証スキームが使用されていること、およびセキュリティ トークンが Base64 方式でエンコードされていることを受信側に知らせる、Meta 要素のペアが含まれています。Data 要素は Meta 要素の兄弟であり、送信側の ID を確認するために受信側で使用される認証トークンを含んでいます。

SyncBody 要素

SyncBody 要素を図 2 に示します。この図の Target 要素は、SyncHdr と同じように LocURI によって識別されます。SyncML 内のほとんどすべてが LocURI によって識別されます。LocURI は、入れ子になったツリー構造に基づいて構築されています。XML ドキュメントの入れ子になったツリー構造に似ていますが、一連の入れ子になった XML ノードに比べると処理のコストはいくらか低くなっています。この概念的なツリーのルートは " . " 文字によって識別されます。これは常に指定する必要があります。

図 2 SyncBody 要素

<SyncBody>
  <Add>
    <CmdID>2</CmdID>
    <Item>
      <Target>
        <LocURI>./Vendor/MSFT/SwMgmt/Download/SetBrowserFavorite/PkgID
        </LocURI>
      </Target>
      <Data>pkg id setbrowserfavorite</Data>
    </Item>
    <Item>
      <Target>
        <LocURI>./Vendor/MSFT/SwMgmt/Download/SetBrowserFavorite/PkgURL
        </LocURI>
      </Target>
      <Data>http://content.contoso.com/download/SetBrowserFavorite.cab
      </Data>
    </Item>
  </Add>
  <Exec>
    <CmdID>3</CmdID>
    <Item>
      <Target>
        <LocURI>./Vendor/MSFT/SwMgmt/Download/SetBrowserFavorite/Operations/DownloadInstall        </LocURI>
      </Target>
    </Item>
  </Exec>
<Final/>
    </SyncBody>

このツリーには、モバイル デバイスに関する情報 (保有しているメモリの容量や OMA-DM で起動できる実行可能ファイルなど詳細な情報) が含まれています。このデバイス情報のツリーの参照に LocURI が使用される場合は、完全な URI が必要です。つまり、デバイス ルートからアドレス指定先の特定のリーフまでを指定します。OMA-DM 仕様のこの部分では、部分的な URI または相対 URI は許可されていません。

私はこのツリーを "概念的" と呼びました。なぜでしょうか。SyncML および OMA-DM の仕様では、この情報が実際にどのようにして補助ストアに保存されるかについて、モバイル デバイスまたはデバイス管理サーバーへの実装の詳細が規定されていないからです。SyncML はデータをツリーと見なしてアドレス指定しようとしますが、ユーザーはリレーショナル データベース、デバイスまたはサーバーのレジストリ、揮発性メモリ、一連のフラット ファイルなどの場所にデータを格納することができます。仕様では、データを物理的に保存するメカニズムが規制されていません。

ルート ノードの下には、重要な子ノードが 3 つあります。DevInfo、DevDetail、および Vendor です。DevInfo ノードには、デバイスの製造元に関する情報、デバイスの UI に設定された言語、およびデバイス ID が含まれています。DevDetail ノードには、ハードウェア バージョンやサポートされる URI の最大長など、ベンダーに依存しないその他のデバイス情報が含まれています。Vendor ノードには、その他の興味深いデバイスの詳細が含まれています。仕様によると、実装によって Vendor ノードの下に OMA-DM プロトコルの拡張機能を配置する必要があります。これは、Windows Mobile デバイスのプロビジョニングまたは管理を行うときに、大半の時間を費やすことになる場所です。

リモート ワイプ

Exec コマンドは、常にデバイスに何らかの実行を指示しますが、OMA-DM からデバイスに指示できるのは限定されたセットです。Windows Mobile デバイスで OMA-DM がトリガできる機能に、リモート ワイプがあります。これは、Exchange により Windows Mobile クライアントに提供されるワイプ機能に似ています。管理しているデバイスの紛失や盗難の際には非常に役立ちます。OMA-DM でデバイスをワイプするコマンドは、次のようになります。

<Exec>
  <CmdID>3</CmdID>
  <Item>
    <Target><LocURI>./Vendor/MSFT/RemoteWipe/doWipe</LocURI></Target>
  </Item>
</Exec>

OMA-CP でのデバイスのワイプも可能です。プロビジョニング XML を含む CAB ファイルを作成し、OMA-DM ダウンロードを介してデバイスに配布します。CAB ファイルの内容は、同じ RemoteWipe CSP (OMA-DM によって起動される) にルーティングされます。結果は同じです。

先に示した SyncBody 要素には 1 つの Add 要素が含まれています。Add 要素は、受信側に、1 つのノードまたは一連のノードをデバイス情報ツリーに追加するように命じます。OMA-DM の Microsoft による実装では、暗黙的な追加と呼ばれる動作がサポートされます。これにより、Add コマンドがデバイス上にないノードを含む LocURI を参照するときに、ルートからリーフまでのすべてのノードがデバイス情報ツリーに挿入されます。この拡張機能がなかったら、ノードを一度に 1 つずつデバイス ツリーに追加しなければなりません。その場合、帯域幅とプロセッサ時間が急速に消費され、最終的にはユーザーの忍耐も限界を超えてしまうでしょう。

この Add コマンドは、デバイスのソフトウェア管理のために、Download ノードに必要な追加を行い、URL が content.contoso.com/download/SetBrowserFavorite.cab になるようにします。最終的に、この URL はデバイス上の構成サービス プロバイダ (CSP) にルーティングされます (偶然にも Download CSP と呼ばれます)。構成サービス プロバイダは、URL によって指定されたコンテンツをフェッチしようとします。

Add コマンドの後には Exec コマンドが続きます。Exec コマンドは、次の処理を行うようにデバイスに指示します。この場合は、ID が SetBrowserFavorite.cab であるパッケージのダウンロードおよびインストールを行うようにデバイスに指示します。

Exec コマンドの後には Final 要素が続きます。この要素により、このセッションで予定されている最後の SyncML メッセージであることを受信側に示します。Final 要素がない場合、受信側では、さらに SyncML メッセージが続く予定であると認識します。

ActiveSync を介して CAB ファイルをデバイスにコピーすることにより CAB ファイルをインストールできる場合、通常は、OMA-DM を使用してインストールできます。CAB ファイルは、デバイスが信頼する証明書で署名される必要があります。ファイルが有効な証明書で署名されていない場合、CAB ファイルのインストールは失敗します。これは、署名されていない CAB ファイルのインストールを ActiveSync を介して行った場合の動作と異なります。ActiveSync 経由で署名されていない CAB ファイルをデバイスにインストールしようとすると、デバイスのポリシーでは許可されているという前提で、署名されていない CAB をインストールするかどうかを確認するように求められます。

Windows Mobile デバイスの OMA-DM プロトコルからは確認の要求はありません。単に障害が発生し、管理プログラム アプレット内にエラー コードを含んだメッセージにより障害の通知が行われるだけです。関連するエラー コードはデバイス管理サーバーに送られます。この設計は合理的です。デバイスが物理的にユーザーの手元にあり、ActiveSync の初期化はユーザー自身またはユーザーが信頼する他のだれかが行うことになっていることがその理由です。OMA-DM はリモート エージェントにより初期化されるため、ユーザーが自分で制御することは不可能です。

最初に、Download CSP は、指定された URL からコンテンツをフェッチします。続いて、CAB ファイルを調べます。署名されていない場合は失敗します。CAB ファイルが署名されている場合、Download CSP は CAB ファイルをアンパックし、ファイルのコンテンツを適切にルーティングします。CAB にソフトウェアが含まれている場合、そのソフトウェアはデバイスにインストールされます。Mike が彼のコラムで作成した CAB ファイルのように、CAB に OMA-CP プロビジョニング XML が含まれている場合、そのプロビジョニング XML はデバイスに適用されます。CAB ファイルにムービーやホーム ディスプレイなどのプレーン コンテンツが含まれていた場合、このコンテンツはデバイス ファイル システムに格納されます。

マネージ プログラム アプレットは、OMA-DM を介して CAB ファイルをデバイスにインストールする試みが成功または失敗したかを毎回記録します。インストールが完了した後で、デバイスは OMA-DM 標準により定義されたコードを新しい OMA-DM セッションで管理サーバーに送信します。

その他の情報

Windows Mobile デバイスは、SyncML で指定されたコマンド要素のサブセットに応答します。次に、まだ取り上げていないコマンド要素をいくつか示します。

Alert コマンドを使用すると、送信側は受信側に通知を送ることができます。たとえば、管理サーバーからデバイスへのアラートにより、デバイスの起動とセッション開始を指示できます。または、UI を通してエンド ユーザーに示す情報をアラートに含めることもできます。

Atomic 要素は、他の複数のコマンドをグループ化して、全体で成功または失敗となる 1 つの単位を作る場合に使用されます。コマンドのグループが関連付けられ、部分的な成功の結果としてデバイスの状態が望ましくない状態または未知の状態になる場合に、これは重要です。3 つの個別の Add コマンドがある場合、Atomic 要素内でグループ化されていなければ、互いに影響を与えることなく成功または失敗し、管理サーバーに対して 3 つの異なる応答メッセージを生成します。

Delete は Add の反対です。Delete コマンドは、デバイス ツリーからノードを削除します。ノードに子ノードがある場合、子ノードも削除されます。組み込みの DevInfo ノードとその子ノードのように、削除できないノードおよび子ノードもあります。これらを削除しようとすると、エラー コードが生成されます。Replace コマンドは、デバイス ツリー内の特定のノードを置き換えます。

Get コマンドは、デバイス ツリーでクエリを実行して、SyncML メッセージで送信側に返す情報を取得する場合に使用されます。たとえば、デバイスで現在使用可能なストレージの容量を取得するには、次のような Get コマンドを送信します。

<Get>
  <CmdID>3</CmdID>
  <Item>    
    <Target>
      <LocURI>./Vendor/MSFT/DeviceInformation/TotalStorage</LocURI>
    </Target>
  </Item>
</Get>

Result コマンドは、Get で要求したノードの値と共に、Get への応答として送信されます。

Sequence 要素は、特定の順序でノードをグループ化する場合に使用されます。コマンドを順番に処理する場合は、Sequence 要素でグループ化する必要があります。そうでない場合、実行の順序は保証されません。

最後に、Status 要素には、特定の操作により返された成功コードまたは失敗コードが含まれます。Status が 200 の場合、通常は成功を示します。

SyncML を使用する

当初、SyncML はデバイス管理ではなくデバイス同期用のプロトコルでした。SyncML に基づいた OMA 同期プロトコルの実装は、デバイスで予定表と連絡先の情報を同期化する場合によく使用されます。SyncML の基本的なプロトコル仕様は、同期のための要件および管理のための要件に対応しています。つまり、基本的な SyncML 表現のプロトコルには、OMA-DM ではまったく使用されない要素と、同期ではまったく使用されない他の要素が含まれているということです。

SyncML 仕様を初めて読んだときには、多少混乱してしまうかもしれません。この仕様は 2 つの異なる問題領域を扱っているからです。同期と管理には部分的に重なる領域もありますが、同じものではありません。プロトコル表現の仕様を確認するときに、管理で使用される SyncML の要素と同期で使用される要素とを、概念的に分けて考えるとわかりやすいでしょう。

デバイスのプロビジョニングを OMA-DM を介して行う管理サーバーが必要です。Microsoft System Center Mobile Device Manager 2008 などいくつか商用製品が発売されています。また、無償の SyncML ライブラリおよび実装も利用できます。ベンダーおよび実装者に与えられる柔軟性の程度を考えると、OMA-DM を使用してデバイスとサーバーが対話できるようにすることは、必ずしも単純ではないことがわかります。でも、どうでしょう。OMA が登場する前のモバイル市場では互いに関連性のない独自の通信メソッドが混在していました。これらを統合してデバイスの相互運用を行う苦労を考えると、OMA 標準を使用した各種デバイスの統合作業の方がはるかに簡単です。

ご意見やご質問は goplaces@microsoft.com まで英語でお送りください。

Ramon Arjona は、Microsoft の Windows Mobile チームのシニア テスト リーダーです。