Cellular

Digg This!

Page 2 of 4   « previous page   next page »

4)    Non-SyncML Standard object format definitions
 
    a)    PIM data standards such as vCard, vCalendar, vNote,
            vMessage, and vTodo   
    b)    Custom management objects such as folder objects, file, email

To support the exchange of SyncML messages the client and server must each implement a common transport protocol. In addition, they must agree upon which device will be the initiator of the session in order to set transports to the correct state (accepting an inbound connection or establishing an outbound connection).  A SyncML session is based on the exchange of SyncML messages between the client and server.  The flow of commands between the client and server is divided into multiple stages, called packages.  Each package requires one or more messages to be sent, with the number of messages determined by the amount of information exchanged.  SyncML messages include one or more commands and status on received commands.  A session is complete when both devices have sent all their commands and received status for each.

SyncML messages are transmitted in XML or WBXML, a version of XML allowing for much smaller messages (by compression) and simpler parsing. Due to message size and parsing benefits, most mobile devices only support WBXML encoded messages.

Device Management (DM) & Data Synchronization (DS) Objects

Since this is a client-server scenario, where the server does the “heavy lifting” to manage and maintain the software for the device, the management server must be able to access or “see” the internal data of the device.  The information is organized into separate “objects” which are different depending on whether they are required for device management or data synchronization.

A device management object is comprised of a set of nodes, typically structured in a hierarchical tree, which allows the values and properties of each node to be set and retrieved individually.  A management object can be as small as a single integer or very large and complex.  One of the great benefits of the OMA-DM is that it is agnostic regarding the contents, or values, of the management objects and treats the node values as opaque data.


The OMA-DM specification defines three required management objects, the content of which is distributed across a collection of nodes forming the complete object:
 
    (1)    Device Info — contains information that uniquely identifies the device
    (2)    Device Detail — contains general information about the device
    (3)    Device Management — contains the settings for the DM client
             within the device

In addition, the OMA Client Provisioning object is an XML-based document that specifies the initial provisioning parameters for the device.  This document is designed to be very flexible and can be used to provision an array of services and applications.  It includes configuration parameters for proxy servers, network access points, application parameters, access rules and more.  This extensible document is a popular choice for the provisioning of new and proprietary technologies, and can even be used to provision an initial OMA-DS/DM configuration.

The OMA Data Synchronization protocol is independent of the actual data objects it synchronizes — it can synchronize data in any format.  As long as the client and server share a common format for a given object, its data store can be synchronized.  SyncML provides a mechanism for the device to convey the object formats it supports to the server through the Device Info document, including general information about the device, as well.

Page 2 of 4   « previous page   next page »