給予翻譯建議
 
其他人的建议:

progress indicator
無其他建議。
MSDN Magazine > 首頁 > 所有期刊 > 2009 > MSDN Magazine 二月 2009 >  提供 WINDOWS WITH SYNCML 的行動裝置
檢視內容: 並排檢視檢視內容: 並排檢視
社群成員可以對此機器翻譯的內容進行編輯。我們鼓勵您按一下與下面句子相關聯的「編輯」連結來改善翻譯。
Going Places
Mobile Device Provisioning With SyncML
Ramon Arjona
In the April 2008 issue of MSDN Magazine , Mike Calligaro wrote a Going Places column about provisioning a Windows Mobile device using XML files and the DMProcessConfigXML API . The XML files Mike used were based on the Open Mobile Alliance (OMA) Client Provisioning (OMA-CP) standard for device management, formerly known as Wireless Application Protocol (WAP).
OMA-CP works fine for managing a few devices, and in his column Mike has suggestions for ways to push provisioning information to multiple devices at once. But what if you need to provision thousands of devices in a systematic way over a long period of time? And what if you need to know what software and registry settings are already set on the devices you're trying to manage?
This sort of large, coordinated provisioning effort is the domain of OMA Device Management (OMA-DM). The OMA-DM protocol is based on a dialect of XML called SyncML, and it can be used to provision and manage devices in an enterprise scenario. This column will discuss the structure of a SyncML document used in the OMA-DM protocol. I will cover specific usage scenarios for the Windows Mobile platform, including remotely wiping the device. I will also demonstrate how you can set a browser favorite on the device using the XML from Mike's column in conjunction with OMA-DM.

What Is OMA?
OMA is an industry group comprising more than 200 mobile operators, mobile device manufacturers, and software vendors (including Microsoft). OMA was formed in 2002 to create a single group to manage the burgeoning number of mobile device standards that were appearing in the marketplace, including WAP, Device Management, and SyncML. This multiplicity of groups was creating duplication of work, so the concerned industry partners got together and brought all of these important initiatives together under a single umbrella group.
OMA standards help make it easier to work with mobile devices and networks by creating a nonproprietary way to communicate between technologies. SyncML and OMA-DM are two aspects of this open protocol family. Like all protocols, they are subject to a certain amount of interpretation, and every vendor is free to supply its own value-added extensions. But working with them is easier and more straightforward than trying to negotiate a proprietary, vendor-specific format.

SyncML: XML for Synchronization
SyncML is an XML-based markup that is used as the basis for most protocols defined by OMA. A SyncML document is called a message. The message must be well-formed XML but not necessarily valid XML. That is, it must have matching open and close tags for all elements, must have quotes around all attributes, and otherwise conform to the basic definition of well-formedness that is essential to any document calling itself XML.
While there is a SyncML document type definition (DTD), there is no requirement that the sender or receiver validate against it. One of the reasons for this is that validation requires extra memory and processor time, and mobile devices tend to be short on both of these resources. The message, in turn, contains command elements that do the heavy lifting of specific OMA protocols.
SyncML and OMA-DM are transport independent. There are transport bindings defined for HTTP and Object Exchange (OBEX), and it would be possible for other bindings to be defined. This makes SyncML and OMA-DM useful for provisioning devices over the air. Using SyncML and OMA-DM with a compliant device-management server, you can push configurations to a device without using a memory card, without tethering the device, and without asking the end user for interaction, such as visiting a Web site.
One or more messages is contained, conceptually, in a SyncML package. The SyncML package encompasses all of the messages sent between a sender and a receiver.

SyncML Elements
A SyncML document consists of a root SyncML element, a header defined by the SyncHdr element, and a body defined by the SyncBody element. The root of a SyncML document is always a SyncML element, which looks like this:
<SyncML xmlns='SYNCML:SYNCML1.1'>
...
</SyncML>
The SyncML element contains the SyncHdr and SyncBody child elements. A SyncHdr element looks like the markup in Figure 1. This short header tells you everything that a receiver would need to know to process the message.
<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>
The VerDTD element indicates that this message conforms to version 1.2 of the SyncML Representation Protocol, as defined by OMA. The VerProto element indicates something similar: that you're looking at a message that deals with version 1.2 of the OMA-DM protocol. The version numbers are the same, but the two things are different. SyncML is used for different OMA protocols, including a device management protocol (which I am discussing in this column) and a data synchronization protocol (for which SyncML was originally designed).
The SessionID element indicates at which SyncML session you're looking. The value of this ID can be, at most, 4 bytes long.
The MsgID is an ID that is unique within the session. It's used to keep track of the conversation between sender and receiver. When the receiver replies with results, the results refer to the message being responded to by including the MsgID in a MsgRef element.
The Target element says who the receiver of the message is meant to be. The Source element says who the sender of the message is meant to be. These elements both contain a LocURI element that contains the string uniquely identifying the sender or receiver. The LocURI of the Target and Source must be a URL, a URI, or a URN. Since a management server will usually already have a unique DNS name, it is common to see the fully qualified domain name of the management server in the LocURI when the sender or receiver is a management server.
Note that neither the Target nor the Source element is directly related to addressing or routing the message. These tasks are left to the device-management application and the supporting transport protocols.
Mobile devices are frequently referred to by a URN that refers to a GUID—as defined by RFC 4122—that refers uniquely to the specific device being addressed. It is up to the application to map this GUID back to an address that can be reached over the network. Since the GUID is not an immediately intuitive way to tell to which specific device you are talking, the application has added a LocName element to the Source element, which holds the name of the device that originated the SyncML message.
Finally, the Cred element contains information that identifies the originator. It contains a pair of Meta elements that inform the recipient this message uses the MD5 authentication scheme that is defined in the SyncML standard, and that the security token is base-64 encoded. The Data element that is the sibling of the Meta elements contains the authentication token that can be used by the recipient to confirm the sender's identity.

The SyncBody Element
A SyncBody element is shown in Figure 2. Notice that the Target elements here, just like in the SyncHdr, are identified by LocURI. Nearly everything in SyncML is identified by LocURI. The LocURI is built according to a nested tree structure, similar to the nested tree structure of an XML document, but is somewhat less expensive to process than a series of nested XML nodes. The root of the conceptual tree is identified by the " . " character, which must always be specified.
<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>
The tree contains information about the mobile device, including details such as the amount of memory it has or what executables are available to be invoked over OMA-DM. When a LocURI is used to refer to this tree of device information, it must always be a full URI. That is, it must always be specified from the device root down to the specific leaf to be addressed. Partial or relative URIs are not allowed in this part of the OMA-DM specification.
Note that I refer to this as a "conceptual" tree. That is because the SyncML and OMA-DM specifications do not impose any implementation details on the mobile device or on the device management server for how this information is actually persisted to a backing store. SyncML wants to address the data as though it were a tree, but you could store it in a relational database, in the device or server registry, in volatile memory, in a series of flat files, or in some other way. The specification is completely agnostic to the mechanism used to physically persist this data.
Beneath the root node are three important child nodes: DevInfo, DevDetail, and Vendor. The DevInfo node contains information about the device manufacturer, the language set on the device's UI, and the device ID. The DevDetail node contains other vendor-independent information about the device, including its hardware version and the maximum length of URI supported by the device. Most other interesting details about the device are stored under the Vendor node. By specification, implementers must park their extensions to the OMA-DM protocol under the Vendor node, and this is where you will spend much of your time when provisioning or managing Windows Mobile devices.
Remote Wipe
The Exec command always tells the device to do something, but there is a limited set of things the device can be commanded to do by OMA-DM. One other thing that can be triggered on a Windows Mobile device by OMA-DM is a remote wipe. This is similar to the wipe feature offered for Windows Mobile clients by Exchange and is really useful if a device under your control has been lost or stolen. The command to wipe a device with OMA-DM looks like this:
<Exec>
  <CmdID>3</CmdID>
  <Item>
    <Target><LocURI>./Vendor/MSFT/RemoteWipe/doWipe</LocURI></Target>
  </Item>
</Exec>
It's possible to wipe a device with OMA-CP, too. So you could, if you really wanted to, create a CAB file with provisioning XML in it and distribute it to the device via OMA-DM download. The CAB file's contents would then get routed to the same RemoteWipe CSP that would be invoked by OMA-DM, and the results would be the same.
The SyncBody element shown earlier contains one Add element. The Add element tells the receiver to add a node or series of nodes to the device-information tree. The Microsoft implementation of OMA-DM supports something called implicit add, which means that if an Add command refers to a LocURI with nodes that are not present on the device, all of the nodes from the root to the leaf are inserted into the device-information tree. Without this extension, nodes would have to be added to the device tree one at a time, which would rapidly consume bandwidth, processor time, and—eventually—the user's patience.
This Add command is adding something to the Download node for software management on the device having the URL content.contoso.com/download/SetBrowserFavorite.cab. Ultimately, this URL will be routed to a configuration service provider (CSP) on the device—coincidentally called the Download CSP—that will try to fetch the content specified by this URL.
The Add command is followed by an Exec command. The Exec command tells the device to go do something. In this case, it's telling the device to go download and install the package with the ID SetBrowserFavorite.cab.
The Exec command is followed by a Final element, which tells the receiver that this is the last SyncML message that should be expected for this session. Without the Final element, the receiver would expect that there would be more SyncML messages to follow.
If you can install a CAB file onto the device by copying it onto the device via ActiveSync, you can usually install that CAB file onto the device using OMA-DM. The CAB file must be signed with a certificate that the device trusts. If the file is not signed with a valid certificate, the installation of the CAB file will fail. This differs from the behavior you'll see when installing an unsigned CAB file over ActiveSync. When you install an unsigned file over ActiveSync the device might prompt you for confirmation of your intention to install the unsigned CAB, assuming policy on the device is set to allow this.
The OMA-DM protocol on a Windows Mobile device does not prompt you. It just fails, notifies you of the failure with a message containing an error code in the Managed Programs applet, and sends a related error code back to the device management server. This design makes sense because ActiveSync is being initiated by you, or hopefully someone you trust, while the device is physically in your hands. OMA-DM is initiated by a remote agent, at a time that is completely out of your control.
First, the Download CSP fetches the content from the specified URL. Then it looks at the CAB file and fails if it is unsigned. If the CAB file is signed, the Download CSP unpacks the CAB file and routes the contents of the file appropriately. If the CAB contains software, the software is installed onto the device. If the CAB contains OMA-CP provisioning XML—such as the CAB file Mike created in his column—then the provisioning XML is applied to the device. If the CAB file contained plain content, such as a movie or a home screen, then this content is stored on the device file system.
The Managed Programs applet records every attempt, successful or failed, to install a CAB file onto the device via OMA-DM. After the installation has completed, the device sends a code defined by the OMA-DM standard back to the management server in a new OMA-DM session.

But, Wait! There's More!
Windows Mobile devices respond to a subset of the command elements specified in SyncML. Following are a few command elements I haven't discussed yet.
The Alert command allows the sender to notify the recipient. For instance, an alert from a management server to a device might tell the device to wake up and start a session. Or an alert could contain information that should be displayed to the end user through the UI.
The Atomic element is used to group other commands that must all succeed or fail as a unit. This is important when a group of commands is related and partial success would leave the device in an undesirable or unknown state. Unless grouped in an Atomic element, three separate Add commands would succeed or fail independent of each other and generate three separate response messages for the management server.
Delete is the opposite of Add. The Delete command removes a node from the device tree. If the node has child nodes, those are removed, too. Some nodes, such as the built-in DevInfo node and its children, can't be removed, and the attempt to remove them generates an error code. The Replace command replaces a given node in the device tree.
The Get command is used to query the device tree for information and returns that information in a SyncML message to the sender. For instance, to get the amount of storage available currently on the device, the following Get command would be sent:
<Get>
  <CmdID>3</CmdID>
  <Item>    
    <Target>
      <LocURI>./Vendor/MSFT/DeviceInformation/TotalStorage</LocURI>
    </Target>
  </Item>
</Get>
The Result command is sent in response to a Get, containing the value of the node the Get requested.
The Sequence element is used to group nodes in a specific order. If you expect to have commands processed one after another, you must group them in a Sequence element. Otherwise the order of execution is not guaranteed.
And finally, the Status element contains the success or failure code returned by a given operation. A Status of 200 generally indicates success.

Putting SyncML to Work
SyncML began as a protocol not for device management but for device synchronization. Implementations of the OMA sync protocol based on SyncML are used frequently to allow devices to synchronize calendar and contact information. The base protocol specification for SyncML addresses the requirements for synchronization as well as the requirements for management. This means the base SyncML representation protocol contains elements that are never used in OMA-DM and other elements that are never used in synchronization.
First-time readers of the SyncML specification may find themselves a bit confused, because the specification is trying to address two divergent problem domains. While there is some overlap between synchronization and management, the two things are definitely not the same. It's helpful to segregate the elements of SyncML that are used in management conceptually from those that are used in synchronization when reviewing the protocol representation specification.
You need to have a management server to provision your devices via OMA-DM. There are several commercial offerings available, including Microsoft System Center Mobile Device Manager 2008. And there are noncommercial SyncML libraries and implementations available as well. The amount of flexibility allowed to vendors and implementers means that making devices and servers talk using OMA-DM is not always as straightforward as one would want. But the difficulties presented by integration of different devices that use OMA standards is immensely preferable to the difficulty of making devices interoperate using the hodgepodge of unrelated, proprietary communication methods that dominated the mobile marketplace before the advent of OMA.

Send your questions and comments to goplaces@microsoft.com .

Ramon Arjona is a Senior Test Lead working on the Windows Mobile team at Microsoft.

要放置
提供使用 SyncML 的行動裝置
Ramon Arjona
在 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 ] 中標記中。 這個簡短的標頭告訴您會需要瞭解處理訊息的接收者的所有項目。
<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 節點。 所識別的概念性樹狀目錄的根目錄,「 」 永遠必須指定的字元。
<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 小組。

Page view tracker