![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
For me, one of the most exciting things about XML has always been the possibility of liberating information from the programs that process it. Almost every computer user has had the experience of his data being inaccessible to someone else because they don't share the same word processor application, or being unable to access their own data four or five years later because the application it used is so outdated. Even if you're one of the lucky ones who hasn't experienced these problems, you probably have experienced the inconvenience of being tied to a particular software suite because all your data is "owned" by that suite's proprietary file format.
The arrival of XML, along with the acknowledgement of the usefulness of open standards, has begun to liberate data from the confines of single applications. Today's software developers are aware that data tends to move around between people and organizations. The support for XML in the upcoming Microsoft Office 11 is a testament to the realization that data can no longer be tied to just one application.
So, with the good news that data is starting to move around better between applications, I'm excited to see that it's becoming much easier to transfer data between devices. There's already solid agreement on standards for certain common data items like calendars and contact lists, but an unfortunate lack of convenient ways to transmit such data. This is where SyncML comes into the equation. SyncML, an XML-based protocol for synchronizing data, is enjoying a surge in popularity in the latest batch of mobile devices.
Even with current synchronization technology, it's hard to keep contacts and schedules synchronized across my Palm Pilot, desktop PC, laptop, and mobile phone. So hard, in fact, that I've given up trying -- much to my frustration. I'm desperately tired of trying to remember to carry my PDA around with me as well as my cell phone just to have my contact lists available. SyncML seems like a great opportunity to solve this problem, and as it will work over Wireless Application Protocol (WAP), I can synchronize with a remote server wherever I am.
Unfortunately there don't really seem to be any consumer-facing SyncML products, and only a small amount of supporting open source code available. So I set out to see what was involved in implementing SyncML, with the intentions of integrating my cell phone and my personal information management software, then releasing the code. These next few installments of this column will follow my efforts, focusing particularly on where XML technologies enter into the picture.
The name "SyncML" is somewhat misleading. While it is indeed an XML-based markup language, it's not just a data format. It's really a protocol that provides the structure for agents to synchronize data with each other, by defining the permissible exchanges and determining how they are to be interpreted.
In his article "SyncML intensive" (see Resources), Chandandeep Pabla provides an introduction to some of the basic SyncML concepts. I will introduce concepts as they come up during this exploration, but I recommend that you read Chandandeep's article to become familiar with the broad concepts of SyncML.
The SyncML 1.1 specifications can be found in the "Technology" section of the SyncML Web site as a large collection of PDFs and DTDs (see Resources). The "SyncML Sync Protocol" (PDF) document is the best place to start to get the best picture of what SyncML's capabilities are. There are three XML languages you need to be familiar with:
- SyncML: Defines the exchanges involved in synchronization.
- SyncML Meta Information (MetInf): Defines various metadata items used in SyncML, such as dates, IDs, and sizes.
- SyncML Device Information (DevInf): Enables the devices being synchnronized to be described (for instance, which content types are supported, how much memory is available, and so on).
The SyncML specifications also define a fourth technology aimed at device management and designed to enable the remote performance of administration tasks upon a device. It is beyond the scope of these articles to examine this protocol. Those interested in this protocol should start with the "SyncML Device Management Protocol" document on the SyncML site.
Like SOAP 1.2, SyncML only defines the exchanges in the protocol. It does not tie itself to one particular transport. In fact, bindings to multiple transports are defined by the specifications to HTTP, the Wireless Session Protocol (a kind of souped-up HTTP), and Object Exchange (OBEX). OBEX is the protocol used by devices such as Palm Pilot PDAs to send and receive data by "beaming," and is quite similar to a binary version of HTTP itself.
Even though many standards are touted as "open" these days, that doesn't always mean they're free of patented technology. It's a good idea to look into who made a standard and on what terms it is available before jumping into implementation.
A consortium of companies, largely those interested in mobile telecommunications, developed SyncML. Although involvement in the specifications' development is restricted to consortium members, the specifications themselves are publicly available. The boilerplate language on the specifications reserves the right for royalties for implementation to be levied by the spec's creators, but according to a statement from Douglas Heintzman, Chair of SyncML, such demands are likely not to be made:
"We want to recoup the investment we have made in SyncML. We believe the way to do it (and the reason we started this work in the first place) is to get lots and lots of people to adopt it. We know the best way to do that is to deliver good, quality, functionally rich technology that addresses a real problem for free. This is our guiding principle, despite what may be inferred from the vocabulary in the licensing."
Though those with access to corporate lawyers might want to investigate further, this information seems to give enough encouragement to press on with implementation.
Receiving our first SyncML message
Now that the scene is set, it's time to start looking at SyncML in the wild. Though reading specifications is always enlightening, there are times when it's more instructive to play first and ask questions later. I set up a Web server, pointed my mobile phone (an Ericsson R520m) at it, and took a look at what came in. The server logs showed an HTTP post. I wrote a simple CGI script to dump out the contents of the post, which is shown in Figure 1.
Figure 1. Output of a SyncML message.
The first thing you might notice is that it isn't in XML. Because mobile devices have limited memory and processing capacity, their manufacturers created an XML-like binary meta language called Wireless Binary XML (WBXML). The basic idea behind WBXML is that by taking advantage of foreknowledge of the DTDs, you can minimize the tags to one byte. The tradeoff, as you can see, is it loses some of its readability.
I was surprised to find out that many XML developers had not come across the WBXML specification before. This is all the more peculiar as there are often questions in developer forums asking about binary encodings for XML. WBXML is most commonly deployed as the encoding for WML pages, as delivered to the WAP browsers on mobile phones.
In fact, the SyncML specifications deal with both XML and WBXML encodings of the protocol. SyncML is intended for use over any device, but to support mobile phone class devices, a SyncML server must be able to send and receive WBXML in addition to XML. In the ZIP archive that accompanies this article, I've included the WBXML file from Figure 1 and its translation in XML (see Resources). The XML translation was produced using code I wrote to convert SyncML WBXML to XML, details of which will follow in the next installment of this column.
The XML translation is a lot more instructive and contains the following elements:
- A device description of the R520m phone
- A notification of the state of the calendar since the last synchronization
- A notification of the state of the phonebook since the last synchronization
The goal of this exploration is to create a basic SyncML server component that can be deployed either on a Web server or on an OBEX server (for instance, on a Bluetooth-enabled computer). We've already learned that in addition to implementing the semantics of the SyncML language, we'll need to be able to handle WBXML as well as XML. The Resources section contains details of some open source projects related to this area. SyncML is just starting to attract attention in the open source world and is certainly worth pursuing for your own development. There are other packages worth investigating, too.
The next column will take a look at WBXML and examine its similarities and differences with normal XML. It will also cover WBXML's basic requirements on a SyncML server.
| Name | Size | Download method |
|---|---|---|
| x-synchml.zip | HTTP |
Information about download methods
- Download this ZIP file, which includes the WBXML file discussed in Figure 1 and its translation in XML.
- Meet with other developers involved with SyncML at Sync Congress.
- Read Aashish Patil's article "Sync traps", which explains the vital role synchronization plays in pervasive computing.
- Find out about the open source project sync4j, which is developing a J2EE-based SyncML server.
- Find a C-based WBXML parser, WBXML Library, which has recently been released as an open source project.
- Read all of Edd Dumbill's previous XML Watch columns.
- Find more XML resources on the developerWorks XML zone.
-
Rational Application Developer for WebSphere Software helps Java™ developers rapidly design, develop, assemble, test, profile and deploy high quality Java/J2EE, Portal, Web, Web services and SOA applications.
- Find out how you can become an IBM Certified Developer in XML and related technologies.
Edd Dumbill is managing editor of XML.com and the editor and publisher of the XML developer news site XMLhack. He is co-author of O'Reilly's Programming Web Services with XML-RPC, and co-founder and adviser to the Pharmalicensing life sciences intellectual property exchange. Edd was also program chair of the XML Europe 2002 conference. You can contact Edd at edd@xml.com.
