Menu, toolbar and Icons of SCTS DM
1.1 Menu
1.1.1 Configuration
The Configuration menu can be used to save the changes in the devices, to clear the session pane and to remove all the configured devices.
1.1.2 Settings
The Settings menu can be used to start stop or configure transport servers. It can also be used to view the state of various transport servers. The Settings menu can be used to set the logs path. By default, the logs are saved in the path where SCTS DM is installed. The settings menu is also used to select the type of OBEX service the client has to use to connect to the obex server.
1.1.3 Tools
Currently available tool in the Tools menu is the ‘Credentials calculator’ and WBXML – XML converter.
1.1.4 Help
The Help menu has the guides which help in configuring the tool as a normal client/server or a test client/server. The Help menu can be used to report a bug to the SCTS team, which will prompt the user as to what are the necessary information that has to be sent to the SCTS team.
1.2 Toolbar
The various toolbar items are context sensitive. For example the ‘ + Add Device’ will add a ‘Client Device’ if the focus is on the ‘Client Devices’ object or will Add a ‘Server Device’ if the focus is on the ‘Server Devices’ object.
1.3 Icons
SCTS DM has different icons to represent the various internal objects. The icons corresponding to the different internal objects are shown below.
Device Management tree
DM Accounts
Connection objects
Commands
Server Device:
Client Device:
Session with Errors:
Session without Errors:
Test passed
Test failed
Not Tested
Optional Test
Not supported
Posted in: Mobile-OMA| Tags: OMA SCOMO DM Menu Toolbar Icon SCTS ServerSyncML Introduction
1 SyncML Framework
This specification can be implemented by using the SyncML interface from the SyncML Framework (See Figure 2). Not all the features of the SyncML Interface need to be implemented to comply with this specification.
1.1.1 Figure 2 SyncML Framework
The application “A” depicts a networked service that provides data synchronization service for other applications, in this case application “B”, on some networked device. The service and device are connected over some common network transport, such as HTTP.
In the figure above, the ‘Sync Engine’ functionality is completely placed onto the OMA DS server side even if some OMA DS client implementations can in practice provide some sync engine functionality, too. The ‘Sync Server Agent’ and the ‘Sync Client Agent’ use the protocol defined in this specification and the representation protocol [DSREPU] offered by the SyncML interface (‘SyncML I/F’) to communicate with each other.
2 Device Roles
Figure 3 depicts a synchronization example in which a mobile phone acts as an OMA DS client and a server acts as an OMA DS server. The client sends SyncML message including the data modifications made in the client to the server. The server synchronizes the data (including possible additions, replaces, and deletions) within the SyncML messages with data stored in the server. After that, the server returns its modifications back to the client.
2.1.1 Synchronization Example with Mobile Phone and Server
The example presented the figure above is very simple. However, this example describes the roles of the devices in this specification. That is:
SyncML Client – This is the device that contains a sync client agent and that sends first its modifications to the server. The client MUST also be able to receive responses from the SyncML server. Although the SyncML client has always the role to send its modifications first, in some cases the server can have a role to initiate synchronization. The SyncML client is typically a mobile phone, PC, or PDA device.
SyncML Server – This is the device, which contains a sync server agent and sync engine, and which usually waits that the SyncML client starts synchronization and sends the clients modification to the server. The server is responsible for processing the sync analysis when it has received the client modifications. In addition, it can be able to initiate synchronization if unsolicited commands from the server to the client are supported on the transport protocol level. Typically, the SyncML server is a server device or PC.
3 Sync Types
| Sync Scenario | Description |
| Two-way sync | A normal sync type in which the client and the server exchange information about modified data in these devices. The client sends the modifications first. |
| Slow sync | A form of two-way sync in which all items are compared with each other on a field-by-field basis. In practice, this means that the client sends all its data from a database to the server and the server does the sync analysis (field-by-field) for this data and the data in the server. |
| One-way sync from client only | A sync type in which the client sends its modifications to the server but the server does not send its modifications back to the client. |
| Refresh sync from client only | A sync type in which the client sends all its data from a database to the server (i.e., exports). The server is expected to replace all data in the target database with the data sent by the client. |
| One-way sync from server only | A sync type in which the client gets all modifications from the server but the client does not send its modifications to the server. |
| Refresh sync from server only | A sync type in which the server sends all its data from a database to the client. The client is expected to replace all data in the target database with the data sent by the server. |
| Server Alerted Sync | A sync alert type, which provides the means for a server to alert the client to perform synchronization. When the server alerts the client, it also tells it which type of synchronization to initiate. |
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 release