SyncML (Synchronization Markup Language) is the former name for a platform-independent information synchronization standard. The project is currently referred to as Open Mobile Alliance Data Synchronization and Device Management. The purpose of SyncML is to offer an open standard as a replacement for existing data synchronization solutions, which have mostly been somewhat vendor-, application- or operating system specific. SyncML 1.0 specification was released on December 17, 2000,[1] and 1.1 on February 26, 2002.[2]
SyncML works by exchanging commands, which can be requests and responses. As an example:
Alert
Status
Sync
Commands (Alert, Sync, Status, ecc.) are grouped into messages. Each message and each of its commands has an identifier, so that the pair MsgID,CmdID uniquely determine a command. Responses like Status commands include the pair identifying the command they are responding to.
Before commands, messages contain a header specifying various data regarding the transaction. An example message containing the Alert command for begin a refresh synchronization, like in the previous example, is:
<?xml version="1.0"?> <!DOCTYPE SyncML PUBLIC "-//SYNCML//DTD SyncML 1.2//EN" "http://www.openmobilealliance.org/tech/DTD/OMA-TS-SyncML_RepPro_DTD-V1_2.dtd"> <SyncML xmlns="SYNCML:SYNCML1.2"> <SyncHdr> <VerDTD>1.1</VerDTD> <VerProto>SyncML/1.1</VerProto> <SessionID>1</SessionID> <MsgID>1</MsgID> <Target><LocURI>PC Suite</LocURI></Target> <Source><LocURI>IMEI:3405623856456</LocURI></Source> <Meta><MaxMsgSize xmlns="syncml:metinf">8000</MaxMsgSize></Meta> </SyncHdr> <SyncBody> <Alert> <CmdID>1</CmdID> <Data>203</Data> <!-- 203 = mobile signals a refresh from it to computer --> <Item> <Target><LocURI>Events</LocURI></Target> <Source><LocURI>/telecom/cal.vcs</LocURI></Source> <Meta><Anchor xmlns="syncml:metinf"><Last>42</Last><Next>42</Next></Anchor></Meta> </Item> </Alert> <Final/> </SyncBody> </SyncML>
The response from the computer could be an xml document like (comments added for the sake of explanation):
<?xml version="1.0"?> <!DOCTYPE SyncML PUBLIC "-//SYNCML//DTD SyncML 1.2//EN" "http://www.openmobilealliance.org/tech/DTD/OMA-TS-SyncML_RepPro_DTD-V1_2.dtd"> <SyncML> <SyncHdr> <VerDTD>1.1</VerDTD> <VerProto>SyncML/1.1</VerProto> <SessionID>1</SessionID> <MsgID>1</MsgID> <Target><LocURI>IMEI:3405623856456</LocURI></Target> <Source><LocURI>PC Suite</LocURI></Source> </SyncHdr> <SyncBody> <!-- accept the header of the last message from the client --> <Status> <CmdID>1</CmdID> <MsgRef>1</MsgRef> <CmdRef>0</CmdRef> <!-- 0 = header of the message --> <Cmd>SyncHdr</Cmd> <TargetRef>PC Suite</TargetRef> <SourceRef>IMEI:3405623856456</SourceRef> <Data>200</Data> <!-- 200 = ok, accepted --> </Status> <!-- accept the request of the mobile for a sync --> <Status> <CmdID>2</CmdID> <!-- this is command #2 --> <MsgRef>1</MsgRef> <CmdRef>1</CmdRef> <!-- it respond to command msg=1,cmd=1 --> <Cmd>Alert</Cmd> <TargetRef>Events</TargetRef> <SourceRef>/telecom/cal.vcs</SourceRef> <Meta><Anchor xmlns="syncml:metinf"><Next>0</Next><Last>0</Last></Anchor></Meta> <Data>200</Data> <!-- 200 = ok, accepted --> </Status> <Final/> </SyncBody> </SyncML>
The transaction then proceeds with a message from the mobile containing the Sync command, and so on.
This example is a refresh where the mobile sends all its data to the computer and nothing in the other way around. Different codes in the initial Alert command can be used to initiate other kinds of synchronizations. For example, in a "two-way sync", only the changes from the last synchronization are sent to the computer, which does the same.
The Last and Next tags are used to keep track of a possible loss of sync. Last represents the time of the last operation of synchronization, as measured by each device. For example, a mobile may use progressive numbers (1, 2, 3,...) to represent time, while the computer uses strings like 20140112T213401Z. Next is the current time in the same representation. This latter data is stored and then compared with Last in the next synchronization. Any difference indicates a loss of sync. Appropriate actions involving sending all data can be then taken to put the devices back in sync.
Last
Next
1
2
3
20140112T213401Z
Anchors are only used to detect a loss of sync, they do not indicate which data is to be sent. Apart from the loss of sync case, in a normal (non-refresh) sync, each device sends all changes since the last synchronization.
1SAN = Server Alert Notification. This SyncML Push technology is based on definitions by the Open Mobile Alliance and extends the existing SyncML protocol specification by offering a method of server initiated synchronization.
Lokasi Pengunjung: 18.216.156.12