Overview of The OMA SyncML Common Specifications
The OMA SyncML Common Specifications Enabler Release includes the following documents:
• SyncML Representation: The XML-based representation protocol which specifies the common XML syntax and semantics used by all SyncML protocols. This defines the superset of the DS and DM representation protocols. (* includes DTD).
• The transport bindings: HTTP, OBEX, WSP. These specify the features REQUIRED for each transport to send and receive DS and DM protocol messages.
• The Meta Information associated with a SyncML command or data item or collection used by either DS or DM (* includes DTD)
• SyncML Server Alerted Notification: The logical structure and format of the notification messages used by all SyncML server alerted notifications, for both DS and DM.
The OMA Data Synchronization Specifications Enabler Release includes the following documents:
• SyncML Representation DataSync Usage: The subset of the Common Specifications SyncML Representation Specification necessary to define the Data Synchronization commands and protocol, with examples and commentary specific to DS.
• DataSyncProtocol: Specifies how SyncML Common messages conforming to the DTD are exchanged in order to allow an OMA DS client and server to exchange additions, deletions, updates and other status information.
• Device Information: Used to exchange device specific information, including hardware, firmware, software levels, available memory, and local databases supported. (* Includes DTD)
• Data Objects: Email, File, Folder: Each object is identified by a unique MIME media type (eg. application/vnd.omads-email). The objects are either represented by or encapsulated in a mark-up language defined by xml. Meta or state data is included in the representation (eg. Read/Unread, Creation Date, Last Modified Date).
Although the SyncML Common specification defines transport bindings that specify how to use a particular transport to exchange messages and responses, the SyncML Common representation, synchronization and device management protocols are transport-independent. Each package in these protocols is completely self-contained, and could in principle be carried by any transport. The initial bindings specified are HTTP, WSP and OBEX, but there is no reason why SyncML Common could not be implemented using email or message queues, to list only two alternatives. Because the SyncML Common messages are self-contained, multiple transports could be used without either the server or client devices having to be aware of the network topology. Thus, a short-range OBEX connection could be used for local connectivity, with the messages being passed on via HTTP to an Internet-hosted synchronization server.
To reduce the data size, a binary coding of SyncML Common based on the WAP Forum's WBXML is defined. Messages may also be passed in clear text if desired. In this and other ways SyncML Common addresses the bandwidth and resource limitations imposed by mobile devices.
SyncML Common is both data type and data store independent. SyncML Common can carry any data type which can be represented as a MIME object. To promote interoperability between different implementations of OMA Data Synchronization, the specification includes the representation formats used for common PIM data.
This document specifies the message flows between data synchronization client and server in order to ensure an inter-operable solution across all devices.
Posted in: Mobile-OMA| Tags: OMA SyncML Specifications Overview DM enabler common releaseFunctional Components and Interfaces in SCOMO
1 SCOMO Server
The SCOMO Server is a logical entity which is dedicated to issue SCOMO Operations to the device or consume the SCOMO Alerts from the device.
2 SCOMO Client
The SCOMO Client is responsible for executing SCOMO Operations. It consumes the Software Component delivered to the device and is expected to relay SCOMO Alerts conveying a success or failure result back to the SCOMO Server .
3 The Device Management Client
The DM Client component makes it possible to initiate software component management in the device from a DM server. The DM Enabler provides support for device discovery and parameter setup by the DM Client component. The SCOMO enabler provides a management object for software components that the DM Client component provides access to, such that the DM server can manipulate it. The DM client interacts with a Software Component Agent in the device that is responsible for conducting the management activities using a delivered software component management object. The DM client employs the Generic Alert [DMPRO] mechanism to communicate the final notification comprising the status of the management activity. ScoMo does not define or specify the Device Management Client
4 Alternate Download Client
The alternate download client is an optional feature that may exist on the device and used for downloading software components to the device when the DMPRO is not being used for such downloads. The alternate download client may support DLOTA or something else. SCOMO does not define or specify the alternate download client
5 The Device Management Server
The SCOMO architecture requires the DM server component to support device discovery, determination of an appropriate software component and delivery of a software component management object to the device over Large Object downloads if the device can support that. It also facilitates receipt of a final notification from the device employing the Generic Alert mechanism. SCOMO does not define or specify the Device Management Server.
6 The Alternate Download Server
The Alternate Download Server is an optional feature of the device management system that makes it possible to download software management objects using the alternate download mechanism, such as DLOTA. The Download Server is not defined or specified within the scope of SCOMO
7 External Management Infrastructure
The Device Management System comprises of a set of external management components over and above the device management server that participate in the overall process of managing devices. The external management infrastructure is used but not defined or specified within the scope of the SCOMO.
Definitions of OMA-SCOMO
| Interface | See [OMA-DICT]. |
| Content Provider | An entity that provides data which forms the basis of a service. |
| Device | See [OMA-DICT] |
| Device Management | Management of the Device configuration and other managed objects of Devices from the point of view of the various Management Authorities. Device Management includes: - Setting initial configuration information in Devices - Subsequent updates of persistent information in Devices - Retrieval of management information from Devices - Processing events and alarms generated by Devices |
| Device Management System | A background system capable to interact with a (set of) Device(s) for the purpose of Device Management. |
| Enterprise | A business with deployment and Management Authority for WLAN Bearers, Local Wired Bearers, computers, Devices, software, and employees. |
| Enterprise Device Management Server | Part of the Device Management System that is under administration of an Enterprise Management Authority. |
| Management Authority | An entity that has the right to perform a specific Device Management function on a Device or manipulate a given data element or parameter. For example, the Network Operator, handset manufacturer, enterprise, or Device owner may be the authority or share authority for managing the Device. One Management Authority may own all Device resources or may share or delegate all or parts of these with/to other Management Authorities |
| Management Object | A data model for information which is a logical part of the interfaces exposed by DM components |
| Software Component Management Object | A management tree object defined for software components which will be used for delivering and managing software components within client device. |
| Software Component Activation | The process which results in services or resources a software component embodies to be made accessible to other entities (including the end-user). |
| Software Component Deactivation | The process which results in services or resources a software component embodies to be made inaccessible to other entities (including the end-user). . |
| Service Provider | An entity that provides and administers a service to a Subscriber and/or User. The Network Operator is often a Service Provider. |
| Software Originator | The entity that creates, directly or through a third party, software and/or data targeted for use in a Device, Platform or Base Station. In the event that the software and/or data is controlled by a Regulatory Agency, the Software Originator is responsible for obtaining any Regulatory Agency license and Label. |
| Subscriber | The individual or organisation that is paying for service. |
| User | The individual who is in possession of and operates the Device. |
| SCOMO Alert | SCOMO specific alerts which convey the result of SCOMO Operations via DM Generic Alert mechanism [DMPRO]. |
| SCOMO Operations | Download, Install, Update, Remove, Activate and Deactivate operations which may be invoked on a Software Component MO as well as inventory queries. |