本文章是由機器翻譯。

要放置

提供使用 SyncML 的行動裝置

Ramon Arjona

內容

OMA 是什麼?
同步處理的 SyncML: XML
SyncML 項目
SyncBody) 項目
但是,等 !還有更多 !
將 SyncML 工作

在 4 月) 2008 的問題MSDN Magazine有關,Mike Calligaro 所撰寫的路上的芳鄰到] 資料行提供 Windows Mobile 裝置使用的 XML 檔案與 DMProcessConfigXML API. Mike 所使用的 XML 檔案根據提供 (OMA CP) 先前稱為無線應用程式通訊協定 (WAP) 的裝置管理,標準開啟 Mobile 聯盟 」 (OMA) 用戶端而定。

OMA-CP 管理少數的裝置運作正常且其資料行中 Mike 建議一次發送到多個裝置的佈建資訊的方式。但是如果您需要提供上千裝置的系統化方式一段長時間嗎?且如果您需要知道哪些軟體和登錄設定已設定的裝置上您正在嘗試管理?

這種大型、 協調佈建工作則是網域的 OMA 裝置管理 (OMA DM)。OMA-DM 通訊協定根據方言,以呼叫 SyncML 的 XML 的並且它可以用來提供和管理的企業案例中的裝置。本專欄將討論 OMA-DM 通訊協定中使用一個 SyncML 文件的結構。我會說明特定的使用方式案例包括從遠端清除的裝置,在 Windows Mobile 平台上。我也將示範如何設定瀏覽器我的最愛從 Mike 的資料行 XML 使用與 OMA-DM 在裝置上。

OMA 是什麼?

OMA一個業界的群組會包含 200 個以上的行動運算子 」、 「 行動裝置製造商和 「 軟體廠商 (包括 Microsoft)。OMA 的正確 2002 來建立單一的群組來管理行動裝置標準,已將其出現在市場,包括 WAP、 裝置管理和 SyncML burgeoning 數中。這個群組的多樣性已建立重複的工作,讓有關的業界夥伴一起了和單一傘群組下一起帶來所有這些重要開發案。

OMA 標準更容易以使用行動裝置和藉由建立 nonproprietary 可以通訊技術之間的網路。SyncML] 和 [OMA-DM 都是這個開啟的通訊協定家族的兩個層面。像所有的通訊協定它們受特定數量的轉譯,以及每個廠商沒有提供它自己的加值副檔名。但使用它們更容易且更簡單,比嘗試交涉專屬的廠商特定格式。

同步處理的 SyncML: XML

SyncML,是用於 OMA 所定義的大部分通訊協定為基礎的 XML 架構標記。SyncML 文件稱為訊息。訊息,必須是語式正確 (Well-Formed) 的 XML,但不是一定是有效的 XML。也就是說,它必須有相符的開啟及關閉所有的項目標記,必須有引號所有屬性 (Attribute) 並的語式 XML 時,呼叫本身的任何文件不可或缺的基本定義,否則符合。

雖然有 SyncML 文件類型定義 (DTD) 沒有對它進行驗證的寄件者或收件者的需求。其中一個的原因是驗證會需要額外的記憶體及處理器時間和行動裝置通常很短的兩個這些資源)。訊息,依次,包含執行特定的 OMA 通訊協定的 [粗] 工作的 [指令] 項目。

SyncML] 和 [OMA-DM 都是獨立的傳輸。有針對 HTTP 和 Exchange (OBEX) 的物件定義的傳輸繫結,而且它會定義其他繫結的]。這讓 SyncML 和 OMA-DM 用於提供裝置透過無線的方式。SyncML 和 OMA-DM 與搭配使用相容的裝置管理伺服器,您可以發送設定到裝置而不使用記憶體卡沒有 tethering 的裝置,而不要求使用者如造訪網站的互動。

一或多個訊息包含,就概念上來說,在 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 項目,表示此訊息符合 SyncML 表示通訊協定,1.2 版 OMA 所定義。VerProto 項目表示類似: 您正在尋找處理 OMA-DM 通訊協定的版本 1.2 的訊息。版本號碼相同,但兩件事是不同。SyncML 用於不同的 OMA 通訊協定,包括裝置管理通訊協定 」 (我在本專欄中討論) 和在資料同步處理 (,SyncML 原本設計通訊協定)。

在的 SessionID 項目,表示您要尋找在哪個 SyncML 工作階段。值此 ID 的可以是,最多,4 位元組長度。

在工作階段內是唯一的 ID,MsgID。它用來追蹤的寄件者與接收者之間的交談。當收件者的回覆與結果時,結果參考藉由在 MsgRef 項目中包含 [MsgID 的回應訊息。

目標 (Target) 項目,表示訊息的接收者要是誰。來源項目可說要在郵件的寄件者是誰。這兩個這些項目包含了包含唯一識別寄件者或收件者的字串為 LocURI 項目。目標和來源的 [LocURI 必須 URL 」、 「 資料的 URI 或 「 URN。因為管理伺服器將通常已經有一個唯一的 DNS 名稱,通常會看到 [LocURI 的管理伺服器完整格式的網域名稱,當寄件者或收件者管理伺服器。

請注意目標或來源項目都是直接定址或相關路由傳送郵件。裝置管理應用程式和支援的傳輸通訊協定,會保留這些工作。

行動裝置經常參考,表示 GUID 的 URN — 如 RFC 4122 所定義) 的唯一參考特定裝置的處理。它是由應用程式將此 GUID 對應回可連絡到在網路上的位址。因為 GUID 不是告訴您說話的特定裝置的立即直覺方式,應用程式就已經將 LocName 項目新增至來源項目保存產生 SyncML 訊息的裝置的名稱。

最後,cred 項目會包含識別原始寄件者的資訊。它包含一組通知收件者,此訊息會使用 MD5 驗證配置,定義於 「 SyncML 」 標準,並且安全性語彙基元所 Base-64 編碼的中繼項目。資料項目中繼元素的同層級,將包含您,驗證語彙基元,收件者可以用來確認寄件者的身分。

SyncBody) 項目

SyncBody 項目如 [圖 2 ] 所示。請注意這裡,目標項目就像在的 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。

請注意我指向這個概念 」 樹狀目錄中。這是因為在 SyncML] 和 [OMA-DM 的規格不執行強制行動裝置或在裝置上管理伺服器的方式此資訊實際上保存至支援存放區的任何實作詳細資料。SyncML,想要位址資料,如同它在是一個的樹狀目錄,但您無法將它儲存在關聯式資料庫、 裝置或伺服器登錄在一系列的一般的檔案的動態記憶體或其他方式。規格是完全無從驗證機制,用來實際保存此資料。

根節點下的是三個重要的子節點: DevInfo,DevDetail,及廠商。的 DevInfo 節點包含的資訊裝置製造商語言設定裝置的 UI 和裝置 ID。DevDetail 節點包含了其他廠商獨立的裝置,包括其硬體版本和裝置所支援的 URI 的最大長度資訊。大多數其他有趣的裝置詳細儲存在 [供應商] 節點下。規格,所實作器必須 Park OMA-DM 通訊協定,在 [供應商] 節點下,其副,而且將這會是,您將會花大部分的時間佈建,或管理 Windows 行動裝置時。

遠端清除

執行命令 一定會告訴裝置如果要執行的動作,但是有限的裝置可以命令 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,並散發至裝置透過 OMA-DM 下載。CAB 檔案的內容會再取得傳送到相同 RemoteWipe CSP 會 OMA-DM 所叫用,而且結果會相同。

稍早所示 SyncBody 項目可以包含一個加入項目。在 [新增項目會告訴接收端將節點的系列加入裝置的資訊樹狀結構。Microsoft 的東西呼叫隱含的 OMA-DM 支援實作加入,表示如果的 [新增] 命令參照的節點不存在於裝置上的一個 LocURI,所有從根節點至分葉會插入至裝置的資訊樹狀目錄。這個的副檔名沒有節點,必須要被加入至其中一個裝置樹狀結構,在時間會迅速消耗頻寬,處理器時間,和 — 最終 — 使用者的耐心。

此新增,命令新增項目至下載節點有 [URL] content.contoso.com/download/SetBrowserFavorite.cab 在裝置上的軟體管理的。最後,這個 URL 將不會傳送裝置上的組態服務提供者 (CSP) — 恰巧呼叫 CSP 下載),將會嘗試擷取這個 URL 所指定的內容。

[加入] 命令後面的 [執行] 命令。[執行] 命令會告訴裝置,請執行的動作。在這種情況下,它告訴裝置,請下載並安裝套件的識別碼) SetBrowserFavorite.cab。

[執行] 命令後面會告訴接收者,這應該可以預期這個工作階段的最後一個 SyncML 訊息將最後一個項目。在最後的項目不接收者會預期會有更多的 SyncML 郵件来遵循。

如果您可以將它複製到透過 ActiveSync 裝置,以安裝到裝置上的 CAB 檔案,即可通常是安裝到裝置使用 OMA-DM CAB 檔案。使用裝置所信任的憑證,必須簽署 CAB 檔案。如果檔案不具有效憑證簽署,CAB 檔案的安裝將會失敗。這與您在透過 ActiveSync 安裝的不帶正負號的 CAB 檔案時,會看到的行為不同。當您在透過 ActiveSync 安裝的不帶正負號的檔案時,裝置可能提示您以確認您要安裝未簽署封包假設裝置上的原則設定為允許這個目的。

OMA-DM 通訊協定,在 Windows Mobile 裝置上的不會提示您。它只是失敗,告知您有失敗訊息包含在 [受管理的 [程式集] 小程式的錯誤程式碼並將傳送相關的錯誤程式碼回至裝置管理伺服器。此設計會使有意義,因為 ActiveSync 正在初始化您,或希望其他人您信任,實際手裝置時。OMA-DM 是在遠端的代理程式所啟始在的完全控制項的時間。

第一次,下載 CSP 會擷取內容,從指定的 URL。然後,它會查看封包檔,如果它為不帶正負號就會失敗。若封包檔帶有正負號下載 CSP 會解壓縮的 CAB 檔案,然後適當地路由傳送,檔案的內容。如果封包檔會包含軟體,軟體被安裝到裝置上。如果封包檔包含 OMA-CP 提供 XML — 例如 Mike 在他的資料行所建立的封包檔案 — 然後佈建的 XML 套用至裝置。如果封包檔包含純文字內容,例如影片] 或 [首頁] 畫面然後會將此內容儲存在裝置檔案系統上。

[受管理的 [程式集] 小程式會記錄每一個嘗試,成功或失敗,安裝到 OMA-DM 透過裝置封包檔。完成安裝之後,裝置會傳送 OMA-(DM) 所定義的程式碼傳回至新的 OMA-DM 工作階段中管理伺服器的標準。

但是,等 ! 還有更多 !

Windows Mobile 裝置回應 SyncML 中所指定的命令元素子集。以下是我還沒討論的一些命令項目時。

警示命令,允許寄件者通知收件者。執行個體,從管理伺服器通知至裝置可能會告訴裝置喚醒,並在啟動工作階段。或警示可能包含資訊,應該顯示給使用者透過 UI。

不可部分完成的項目用來必須全部成功或失敗當成一個單位的其他命令。與相關命令的一組和部分的成功就會讓裝置處於不良或未知的狀態時,這點重要的。除非分組的不可部分完成的項目,三個不同會新增命令會成功或失敗各自獨立及管理伺服器產生三個不同的回應訊息。

刪除會是新增的相反。刪除命令會移除裝置樹狀目錄節點。如果節點有子節點時,那些會移除,太。例如內建 DevInfo 節點和其的子系的某些節點無法移除,並且嘗試移除它們會產生一個的錯誤程式碼]。[取代] 指令會取代在指定的節點,在裝置樹狀目錄中。

Get 命令會用來查詢資訊在裝置樹狀目錄,並傳回給寄件者資訊 SyncML 訊息。執行個體,才能在裝置上的目前可用的存放數量下列取得命令會被傳送:

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

取得傳送結果命令以包含在節點的值取得回應要求。

在序列的項目用來以特定順序中的節點。如果您希望將命令處理之後另一個,您必須組織它們在序列的項目。否則不保證執行的順序。

並且最後,狀態項目會包含指定的作業傳回成功或失敗程式碼。200 的狀態,通常表示成功。

將 SyncML 工作

SyncML,開始作為通訊協定無法在裝置管理但是為裝置同步處理。根據 SyncML OMA 同步處理通訊協定的實作用來經常允許同步處理行事曆和連絡人資訊的裝置。同步處理的需求,以及管理的需求,則基底的通訊協定規格 SyncML 位址。這表示基底 SyncML 表示通訊協定包含的 OMA-DM 永遠不會使用的項目] 和 [永遠不會同步處理中使用的其他項目。

SyncML 規格的第一次的讀者發現自己有點混淆因為規格嘗試 divergent 問題的兩個網域的位址。雖然有部份重疊同步處理和管理兩件事是絕對不相同的。會很有用分離的 SyncML 元素中使用的管理在概念上的通訊協定] 表示規格的檢閱時,同步處理中所使用。

您要在有提供您的裝置透過 OMA-DM 管理伺服器。有許多商業產品可用的包括 Microsoft System Center 行動裝置管理員 2008。而且有 noncommercial SyncML 程式庫和實作可用也。彈性允許廠商,以及實作器表示讓裝置和伺服器討論使用 OMA-DM 不會永遠其中一個會想要為直接。但由使用 OMA 標準的不同裝置的整合,問題是十分比困難度讓裝置使用的主導行動裝置的市場之前的 OMA 從前, 無關、 專屬的通訊方法,hodgepodge 的交互操作。

您問題或意見寄至goplaces@Microsoft.com.

Ramon Arjona 資深的測試的負責人正在 Microsoft Windows Mobile 小組。