Unterwegs

Konfigurieren mobiler Geräte mit SyncML

Ramon Arjona

Inhalt

Was ist OMA?
SyncML: XML für die Synchronisierung
SyncML-Elemente
Das SyncBody-Element
Weitere Befehlselemente
Einsetzen von SyncML

In der Ausgabe des MSDN Magazins vom April 2008 enthielt die Rubrik „Unterwegs“ einen Artikel von Mike Calligaro zum Konfigurieren eines Windows Mobile-Geräts mithilfe von XML-Dateien und der DMProcessConfigXML-API. Die von Mike Calligaro verwendeten XML-Dateien basierten auf dem OMA-CP-Standard (Open Mobile Alliance Client Provisioning) für die Geräteverwaltung, der früher als Wireless Application-Protokoll (WAP) bezeichnet wurde.

OMA-CP funktioniert für die Verwaltung einiger weniger Geräte einwandfrei, und in seinem Artikel empfiehlt Mike Calligaro mehrere Methoden, mit denen Konfigurationsinformationen an mehrere Geräte gleichzeitig übertragen werden können. Wie sieht es aber aus, wenn Sie Tausende von Geräten systematisch über einen langen Zeitraum konfigurieren müssen? Was ist, wenn Sie wissen müssen, welche Software- und Registrierungseinstellungen bereits auf den Geräten festgelegt sind, die Sie zu verwalten versuchen?

Diese Art der groß angelegten, koordinierten Konfiguration ist die Domäne von OMA-DM (OMA Device Management, OMA-Geräteverwaltung). Das OMA-DM-Protokoll basiert auf einem XML-Dialekt namens „SyncML“ und kann zur Konfiguration und Verwaltung von Geräten in einem Unternehmensszenario verwendet werden. In diesem Artikel wird die Struktur eines im OMA-DM-Protokoll verwendeten SyncML-Dokuments erläutert. Dabei werden spezifische Verwendungsszenarios für die Windows Mobile-Plattform behandelt, einschließlich der Remotezurücksetzung des Geräts. Zudem wird Ihnen gezeigt, wie Sie auf dem Gerät einen Browserfavoriten festlegen können, indem Sie das XML aus dem Artikel von Mike Calligaro in Verbindung mit OMA-DM verwenden.

Was ist OMA?

OMA ist ein Branchenverband, dem mehr als 200 Mobilfunkanbieter, Mobilgerätehersteller und Softwarehersteller (einschließlich Microsoft) angehören. Er wurde im Jahr 2002 gegründet, um einen einzigen Verband für die Verwaltung der wachsenden Anzahl von Standards für mobile Geräte, die auf dem Markt eingeführt wurden – einschließlich WAP, Geräteverwaltung und SyncML – zu schaffen. Die damalige Vielzahl der Verbände führte zu einer Vervielfachung der Arbeit, sodass die betroffenen Branchenpartner zusammenkamen und alle diese wichtigen Initiativen unter einer einzigen Dachorganisation zusammenfassten.

Die OMA-Standards tragen durch die Schaffung einer anbieterunabhängigen Methode für die Kommunikation zwischen Technologien zur Vereinfachung der Arbeit mit mobilen Geräten und Netzwerken bei. SyncML und OMA-DM sind zwei Aspekte dieser Familie offener Protokolle. Wie alle Protokolle unterliegen sie einem gewissen Interpretationsspielraum, und jedem Anbieter steht es frei, eigene wertsteigernde Erweiterungen bereitzustellen. Die Arbeit mit ihnen ist aber einfacher und unkomplizierter als der Versuch, ein proprietäres, anbieterspezifisches Format auszuhandeln.

SyncML: XML für die Synchronisierung

SyncML ist eine XML-basierte Markupsprache, die als Grundlage für die meisten von OMA definierten Protokolle verwendet wird. Ein SyncML-Dokument wird als Nachricht bezeichnet. Die Nachricht muss wohlgeformtes XML, aber nicht unbedingt gültiges XML sein. Das bedeutet, dass sie übereinstimmende Anfangs- und Endtags für alle Elemente aufweisen muss, dass alle Attribute in Anführungszeichen gesetzt werden müssen und dass die Nachricht auch anderweitig der grundlegenden Definition der Wohlgeformtheit entsprechen muss, die für jedes Dokument, das als XML bezeichnet wird, von wesentlicher Bedeutung ist.

Obwohl es eine SyncML-Dokumenttypdefinition (DTD) gibt, ist es nicht erforderlich, den Absender oder Empfänger anhand der DTD zu überprüfen. Einer der Gründe hierfür besteht darin, dass die Überprüfung zusätzlichen Speicher und zusätzliche Prozessorzeit erfordert und beide Ressourcen auf mobilen Geräten in der Regel knapp bemessen sind. Die Nachricht enthält wiederum Befehlselemente, die den größten Teil der Arbeit für bestimmte OMA-Protokolle übernehmen.

SyncML und OMA-DM sind transportunabhängig. Für HTTP und Object Exchange (OBEX) sind Transportbindungen definiert, und es wäre möglich, weitere Bindungen zu definieren. Dadurch sind SyncML und OMA-DM nützlich für das drahtlose Konfigurieren von Geräten. Wenn Sie SyncML und OMA-DM in Verbindung mit einem kompatiblen Geräteverwaltungsserver verwenden, können Sie Konfigurationen mittels Push an ein Gerät übertragen, ohne dass Sie eine Speicherkarte verwenden, das Gerät anbinden oder den Endbenutzer zur Interaktion (z. B. zum Besuch einer Website) auffordern müssen.

Vom Konzept her sind in einem SyncML-Paket eine oder mehrere Nachrichten enthalten. Das SyncML-Paket umfasst alle zwischen einem Absender und einem Empfänger gesendeten Nachrichten.

SyncML-Elemente

Ein SyncML-Dokument besteht aus einem SyncML-Stammelement, einem durch das SyncHdr-Element definierten Header und einem durch das SyncBody-Element definierten Text. Der Stamm eines SyncML-Dokuments ist immer ein SyncML-Element, das folgendermaßen aussieht:

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

Das SyncML-Element enthält die untergeordneten SyncHdr- und SyncBody-Elemente. Ein SyncHdr-Element sieht wie das Markup in Abbildung 1 aus. Dieser kurze Header teilt Ihnen alles mit, was ein Empfänger zum Verarbeiten der Nachricht wissen muss.

Abbildung 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>

Das VerDTD-Element gibt an, dass diese Nachricht der Version 1.2 des von OMA definierten SyncML Representation Protocol entspricht. Das VerProto-Element gibt etwas Ähnliches an, nämlich, dass es sich um eine Nachricht handelt, die sich mit der Version 1.2 des OMA-DM-Protokolls befasst. Die Versionsnummern stimmen zwar überein, aber es handelt sich um zwei verschiedene Dinge. SyncML wird für verschiedene OMA-Protokolle verwendet, einschließlich eines Geräteverwaltungsprotokolls (das in diesem Artikel erläutert wird) und eines Datensynchronisierungsprotokolls (wofür SyncML ursprünglich entwickelt wurde).

Das SessionID-Element gibt an, um welche SyncML-Sitzung es sich handelt. Der Wert dieser ID kann maximal 4 Byte lang sein.

MsgID ist eine ID, die innerhalb der Sitzung eindeutig ist. Sie wird verwendet, um den Verlauf der Unterhaltung zwischen Absender und Empfänger zu verfolgen. Wenn der Empfänger mit Ergebnissen antwortet, wird in den Ergebnissen auf die Nachricht verwiesen, auf die geantwortet wird, indem die MsgID in ein MsgRef-Element einbezogen wird.

Das Target-Element gibt an, wer der Empfänger der Nachricht sein soll, und das Source-Element gibt an, wer der Absender der Nachricht sein soll. Diese Elemente enthalten beide ein LocURI-Element, das die Zeichenfolge enthält, die den Absender oder Empfänger eindeutig identifiziert. Der LocURI-Wert von Target und Source muss eine URL, ein URI oder ein URN sein. Da ein Verwaltungsserver in der Regel bereits über einen eindeutigen DNS-Namen verfügt, enthält das LocURI-Element häufig den vollqualifizierten Domänennamen des Verwaltungsservers, wenn der Absender oder Empfänger ein Verwaltungsserver ist.

Beachten Sie, dass weder das Target-Element noch das Source-Element direkt mit der Adressierung oder dem Routing der Nachricht in Verbindung stehen. Diese Aufgaben werden der Geräteverwaltungsanwendung und den unterstützenden Transportprotokollen überlassen.

Auf mobile Geräte wird häufig durch einen URN verwiesen, der auf eine  – durch RFC 4122 definierte – GUID verweist, die eindeutig auf das spezifische adressierte Gerät verweist. Es ist Aufgabe der Anwendung, diese GUID wieder einer Adresse zuzuordnen, die über das Netzwerk erreicht werden kann. Da sich anhand der GUID nicht sofort intuitiv erkennen lässt, mit welchem spezifischen Gerät Sie kommunizieren, hat die Anwendung dem Source-Element ein LocName-Element hinzugefügt, das den Namen des Geräts enthält, von dem die SyncML-Nachricht stammt.

Das Cred-Element enthält Informationen, die den Urheber identifizieren. Es umfasst zwei Meta-Elemente, die den Empfänger darüber informieren, dass bei dieser Nachricht das im SyncML-Standard definierte MD5-Authentifizierungsschema verwendet wird und dass das Sicherheitstoken Base64-codiert ist. Das Data-Element, ein den Meta-Elementen gleichgeordnetes Element, enthält das Authentifizierungstoken, das vom Empfänger zur Bestätigung der Identität des Absenders verwendet werden kann.

Das SyncBody-Element

In Abbildung 2 wird ein SyncBody-Element gezeigt. Beachten Sie, dass die Target-Elemente hier genau wie in SyncHdr durch LocURI identifiziert werden. Nahezu alle Elemente in SyncML werden durch LocURI identifiziert. LocURI wird entsprechend einer geschachtelten Baumstruktur erstellt, die der geschachtelten Baumstruktur eines XML-Dokuments ähnelt, sich aber etwas kostengünstiger verarbeiten lässt als eine Reihe geschachtelter XML-Knoten. Der Stamm der konzeptionellen Struktur wird durch das Zeichen „ . “ identifiziert, das immer angegeben werden muss.

Abbildung 2 SyncBody-Element

<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>

Die Struktur enthält Informationen zum mobilen Gerät, einschließlich Details wie der Größe des Speichers, über den es verfügt, oder der Information, welche ausführbaren Dateien über OMA-DM aufgerufen werden können. Wenn mithilfe eines LocURI auf diese Struktur von Geräteinformationen verwiesen wird, muss es sich dabei immer um einen vollständigen URI handeln. Das bedeutet, dass er immer vom Gerätestamm bis hinunter zum spezifischen zu adressierenden Blatt angegeben werden muss. Partielle oder relative URIs sind in diesem Teil der OMA-DM-Spezifikation nicht zulässig.

Beachten Sie, dass ich dies als „konzeptionelle“ Struktur bezeichne. Dies beruht darauf, dass die SyncML- und OMA-DM-Spezifikationen für das mobile Gerät oder den Geräteverwaltungsserver keine Implementierungsdetails bezüglich dessen vorschreiben, wie diese Informationen tatsächlich in einem Sicherungsspeicher persistent gespeichert werden. SyncML sieht vor, dass die Daten so adressiert werden, als ob es sich dabei um eine Struktur handelt. Sie könnten sie aber in einer relationalen Datenbank, in der Geräte- oder Serverregistrierung, im flüchtigen Speicher, in einer Reihe von Flatfiles oder auf eine andere Weise speichern. In der Spezifikation wird die Methode, die zur physischen Speicherung dieser Daten verwendet wird, völlig außer Acht gelassen.

Unter dem Stammknoten befinden sich drei wichtige untergeordnete Knoten: DevInfo, DevDetail und Vendor. Der DevInfo-Knoten enthält Informationen zum Gerätehersteller, zur auf der Benutzeroberfläche des Geräts festgelegten Sprache und zur Geräte-ID. Der DevDetail-Knoten enthält weitere anbieterunabhängige Informationen zum Gerät, einschließlich seiner Hardwareversion und der maximalen URI-Länge, die vom Gerät unterstützt wird. Die meisten anderen interessanten Details zum Gerät werden unter dem Vendor-Knoten gespeichert. Gemäß der Spezifikation müssen Implementierer ihre Erweiterungen des OMA-DM-Protokolls unter dem Vendor-Knoten speichern. Dies ist der Bereich, in dem Sie bei der Konfiguration und Verwaltung von Windows Mobile-Geräten viel Zeit verbringen werden.

Remotezurücksetzung

Mit dem Exec-Befehl wird das Gerät immer aufgefordert, eine Aktion durchzuführen, aber es gibt eine begrenzte Anzahl von Aufgaben, zu deren Ausführung das Gerät per OMA-DM angewiesen werden kann. Eine weitere Aktion, die auf einem Windows Mobile-Gerät durch OMA-DM ausgelöst werden kann, ist eine Remotezurücksetzung. Dies ähnelt dem Zurücksetzungsfeature, das Exchange für Windows Mobile-Clients bietet, und ist wirklich nützlich, wenn ein Ihrer Kontrolle unterstehendes Gerät verlorengegangen ist oder gestohlen wurde. Der Befehl zum Zurücksetzen eines Geräts mit OMA-DM sieht folgendermaßen aus:

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

Es ist auch möglich, ein Gerät mit OMA-CP zurückzusetzen. Daher könnten Sie, wenn Sie dies wirklich wollten, eine CAB-Datei erstellen, die Konfigurations-XML enthält, und sie per OMA-DM-Download an das Gerät verteilen. Der Inhalt der CAB-Datei würde dann an den gleichen RemoteWipe-CSP weitergeleitet werden, der von OMA-DM aufgerufen wird, und Sie würden die gleichen Ergebnisse erhalten.

Das oben gezeigte SyncBody-Element enthält ein Add-Element. Das Add-Element weist den Empfänger an, dem Knoten mit den Geräteinformationen einen Knoten oder eine Reihe von Knoten hinzuzufügen. Die Microsoft-Implementierung von OMA-DM unterstützt das so genannte implizite Hinzufügen, was Folgendes bedeutet: Wenn sich ein Add-Befehl auf einen LocURI mit Knoten bezieht, die auf dem Gerät nicht vorhanden sind, werden alle Knoten vom Stamm bis zum Blatt in die Struktur der Geräteinformationen eingefügt. Ohne diese Erweiterung müssten der Gerätestruktur die Knoten nacheinander hinzugefügt werden, wodurch schnell Bandbreite, Prozessorzeit und – schließlich – die Geduld des Benutzers beansprucht werden würden.

Durch diesen Add-Befehl wird dem Download-Knoten für die Softwareverwaltung auf dem Gerät etwas mit der URL „content.contoso.com/download/SetBrowserFavorite.cab“ hinzugefügt. Diese URL wird schließlich an einen Konfigurationsdienstanbieter (Configuration Service Provider, CSP) auf dem Gerät – als Download-CSP bezeichnet – weitergeleitet, der dann versucht, die durch diese URL angegebenen Inhalte abzurufen.

Auf den Add-Befehl folgt ein Exec-Befehl. Durch den Exec-Befehl wird das Gerät angewiesen, eine Aktion durchzuführen. In diesem Fall wird das Gerät dazu aufgefordert, das Paket mit der ID „SetBrowserFavorite.cab“ herunterzuladen und zu installieren.

Auf den Exec-Befehl folgt ein Final-Element, das dem Empfänger mitteilt, dass es sich hierbei um die letzte SyncML-Nachricht handelt, die für diese Sitzung zu erwarten ist. Ohne das Final-Element würde der Empfänger erwarten, dass weitere SyncML-Nachrichten folgen.

Wenn Sie eine CAB-Datei auf dem Gerät installieren können, indem Sie sie über ActiveSync auf das Gerät kopieren, können Sie diese CAB-Datei in der Regel mithilfe von OMA-DM auf dem Gerät installieren. Die CAB-Datei muss mit einem Zertifikat signiert sein, das für das Gerät vertrauenswürdig ist. Wenn die Datei nicht mit einem gültigen Zertifikat signiert ist, schlägt die Installation der CAB-Datei fehl. Dies weicht vom Verhalten bei der Installation einer nicht signierten CAB-Datei über ActiveSync ab. Wenn Sie eine nicht signierte Datei über ActiveSync installieren, fordert das Gerät Sie möglicherweise auf zu bestätigen, dass Sie die nicht signierte CAB-Datei zu installieren beabsichtigen, sofern die festgelegte Richtlinie auf dem Gerät dies zulässt.

Durch das OMA-DM-Protokoll auf einem Windows Mobile-Gerät erhalten Sie keine derartige Aufforderung. Der Vorgang schlägt einfach fehl, und Sie werden im Applet „Verwaltete Programme“ durch eine Meldung, die einen Fehlercode enthält, über den Fehler benachrichtigt. Zudem wird ein zugehöriger Fehlercode an den Geräteverwaltungsserver zurückgesendet. Dieser Entwurf ist sinnvoll, weil ActiveSync von Ihnen oder hoffentlich von jemandem, dem Sie vertrauen, initiiert wird, während Sie das Gerät in den Händen halten. OMA-DM wird von einem Remoteagent zu einem Zeitpunkt initiiert, der vollständig außerhalb Ihrer Kontrolle liegt.

Zuerst ruft der Download-CSP die Inhalte von der angegebenen URL ab. Dann prüft er die CAB-Datei und schlägt fehl, wenn sie nicht signiert ist. Wenn die CAB-Datei signiert ist, entpackt der Download-CSP die CAB-Datei und leitet den Inhalt der Datei entsprechend weiter. Falls die CAB-Datei Software enthält, wird die Software auf dem Gerät installiert. Wenn die CAB-Datei OMA-CP-Konfigurations-XML enthält (wie die CAB-Datei, die im Artikel von Mike Calligaro erstellt wurde), wird das Konfigurations-XML auf das Gerät angewendet. Falls die CAB-Datei einfache Inhalte wie einen Film oder eine Startseite enthält, werden diese Inhalte im Dateisystem des Geräts gespeichert.

Im Applet „Verwaltete Programme“ werden alle erfolgreichen oder fehlgeschlagenen Versuche, eine CAB-Datei über OMA-DM auf dem Gerät zu installieren, aufgezeichnet. Nach Abschluss der Installation sendet das Gerät einen durch den OMA-DM-Standard definierten Code in einer neuen OMA-DM-Sitzung an den Verwaltungsserver zurück.

Weitere Befehlselemente

Windows Mobile-Geräte reagieren auf einen Teil der in SyncML angegebenen Befehlselemente. Im Folgenden werden einige Befehlselemente beschrieben, auf die bisher noch nicht eingegangen wurde.

Mithilfe des Alert-Befehls kann der Absender den Empfänger benachrichtigen. Durch eine Warnung, die von einem Verwaltungsserver an ein Gerät gesendet wird, kann das Gerät beispielsweise reaktiviert und zum Starten einer Sitzung aufgefordert werden. Eine Warnung könnte auch Informationen enthalten, die dem Endbenutzer über die Benutzeroberfläche angezeigt werden sollen.

Das Atomic-Element wird verwendet, um andere Befehle zu gruppieren, die alle als Einheit erfolgreich ausgeführt werden oder fehlschlagen müssen. Dies ist wichtig, wenn eine Gruppe von Befehlen zusammengehört und ein unvollständiger Erfolg das Gerät in einen unerwünschten oder unbekannten Zustand versetzen würde. Wenn sie nicht in einem Atomic-Element gruppiert wären, würden drei separate Add-Befehle unabhängig voneinander erfolgreich ausgeführt werden oder fehlschlagen und drei separate Antwortnachrichten für den Verwaltungsserver generieren.

Delete ist das Gegenteil von Add. Mithilfe des Delete-Befehls wird ein Knoten aus der Gerätestruktur entfernt. Wenn der Knoten über untergeordnete Knoten verfügt, werden diese ebenfalls entfernt. Einige Knoten wie der vordefinierte DevInfo-Knoten und seine untergeordneten Knoten können nicht entfernt werden, und bei dem Versuch, sie zu entfernen, wird ein Fehlercode generiert. Durch den Replace-Befehl wird ein angegebener Knoten in der Gerätestruktur ersetzt.

Der Get-Befehl wird verwendet, um die Gerätestruktur nach Informationen abzufragen und diese Informationen in einer SyncML-Nachricht an den Absender zurückzugeben. Um beispielsweise die Größe des derzeit auf dem Gerät verfügbaren Speichers abzurufen, würde der folgende Get-Befehl gesendet werden:

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

Der Result-Befehl wird als Antwort auf einen Get-Befehl gesendet und enthält den Wert des mit dem Get-Befehl angeforderten Knotens.

Mithilfe des Sequence-Elements werden Knoten in einer bestimmten Reihenfolge gruppiert. Wenn Sie erwarten, dass Befehle nacheinander verarbeitet werden, müssen Sie sie in einem Sequence-Element gruppieren. Andernfalls ist die Ausführungsreihenfolge nicht garantiert.

Das Status-Element enthält den durch einen bestimmten Vorgang zurückgegebenen Erfolgs- oder Fehlercode. Der Status „200“ zeigt im Allgemeinen einen erfolgreichen Vorgang an.

Einsetzen von SyncML

SyncML wurde ursprünglich nicht als Protokoll für die Geräteverwaltung, sondern für die Gerätesynchronisierung entwickelt. Auf SyncML basierende Implementierungen des OMA-Synchronisierungsprotokolls werden häufig verwendet, um Geräten die Synchronisierung von Kalender- und Kontaktinformationen zu ermöglichen. Die Basisprotokollspezifikation für SyncML trägt sowohl den Anforderungen für die Synchronisierung als auch den Anforderungen für die Verwaltung Rechnung. Dies bedeutet, dass das grundlegende SyncML-Repräsentationsprotokoll sowohl Elemente enthält, die in OMA-DM nie verwendet werden, als auch andere Elemente, die nie bei der Synchronisierung verwendet werden.

Beim erstmaligen Lesen der SyncML-Spezifikation kann eine gewisse Verwirrung auftreten, da mit der Spezifikation versucht wird, zwei divergierende Problembereiche zu berücksichtigen. Obwohl es in bestimmtem Umfang eine Überlappung zwischen Synchronisierung und Verwaltung gibt, sind die beiden Bereiche definitiv nicht identisch. Es ist hilfreich, bei der Betrachtung der Repräsentationsprotokollspezifikation die Elemente von SyncML, die bei der Verwaltung verwendet werden, konzeptionell von den bei der Synchronisierung verwendeten Elementen zu trennen.

Sie müssen über einen Verwaltungsserver verfügen, um Ihre Geräte über OMA-DM konfigurieren zu können. Hierfür werden auf dem Markt mehrere Produkte angeboten, einschließlich Microsoft System Center Mobile Device Manager 2008. Darüber hinaus sind auch kostenlose SyncML-Bibliotheken und -Implementierungen verfügbar. Der Anbietern und Implementierern gewährte Grad an Flexibilität bedeutet, dass es nicht immer so einfach ist, die Kommunikation von Geräten und Servern mithilfe von OMA-DM zu erreichen, wie es wünschenswert wäre. Die Schwierigkeiten, die mit der Integration unterschiedlicher Geräte verbunden sind, die OMA-Standards verwenden, sind aber auf jeden Fall dem Problem der Gewährleistung der Interoperabilität von Geräten mithilfe der Vielzahl unverwandter, proprietärer Kommunikationsmethoden, die den mobilen Markt vor der Einführung von OMA beherrschten, vorzuziehen.

Senden Sie Fragen und Kommentare in englischer Sprache an goplaces@microsoft.com.

Ramon Arjona arbeitet als Senior Test Lead im Windows Mobile-Team von Microsoft.