|
Technology INDUSTRY STANDARD
Setting a Date for Interoperability
By Joe McKee
Calendaring standards are syncing up for collaboration.
Today's business professionals are likely to schedule every professional event on their digital calendars. And more than ever, they're relying on their company's calendar applications—built by Oracle, Microsoft, IBM, Palm, or other vendors—to block out their hours and days.
But setting up meetings with coworkers or with colleagues in other companies can be a challenge: Unlike e-mail systems, where messages can be sent to any user on any system, calendaring systems are often proprietary, making calendar information difficult,
if not impossible, to share between systems.
"Even within the same corporation, you often see departments running different vendors' calendar applications," says Thierry Bonfante, a senior product manager for Oracle Calendar. "There still isn't a seamless way to get all users to collaborate with one another." For example, within
the same company, an Oracle Collaboration Suite user can't schedule a meeting with a Microsoft Exchange user. Likewise, scheduling across organizations—with partners, suppliers, or customers—is a headache.
Complicating matters further are the many mobile professionals who need to manage their schedules on the go. Says Bonfante, "Mobile workers access their calendaring systems using different devices with various calendaring clients, and companies lack the middleware to
tie these multiple combinations together."
What will allow users within the same organization—some on IBM Lotus Domino, others on Microsoft Exchange, and others on Oracle Collaboration Suite—to schedule seamlessly? What will let Palm, PocketPC, and Nokia phone users synchronize their devices over the internet using a common technology infrastructure?
The answer is standards—or actually, several standards, including iCalendar, SyncML, and Calendar Access Protocol (CAP). These standards, which, respectively, define calendaring objects, enable calendar synchronization and mediation, and let different calendaring applications speak to each other, have a collective goal: to allow vendors' disparate systems and devices to interoperate transparently so that corporations can keep their IT infrastructure flexible.
Calendaring with iCalendar
In 1998, the Internet Engineering Task Force (IETF) built iCalendar, a standard to represent calendar objects that can be exchanged between different vendor applications. Since then, calendar application vendors have worked to make their products standards-based.
"An iCalendar object can contain different components such as vEvents and vToDo, which represent events and tasks. These components are defined by properties. In the case of a vEvent, properties might include start time, end time, title, and so on," says Jean Marc Robillard, a product manager for Oracle Calendar.
Currently, iCalendar objects are exchanged across applications via e-mail. This doesn't provide true collaboration, because e-mail applications see the objects as separate and cannot reply to or accept them. "iCalendar allows the calendar industry to represent, in a standard format, complex calendar data," says Bonfante. "That's step one. Step two is setting up a way to exchange and interact with this data."
The IETF introduced two standards to shift iCalendar data from information exchange to collaboration. These standards, the iCalendar Message-based Interoperability Protocol (iMIP) and the iCalendar Transport-independent Interoperability Protocol (iTIP), together
let users exchange and
interact with iCalendar
objects across systems.
"iMIP is basically the envelope," says Robillard. "iMIP is
a MIME transport binding for iCalendar that allows the exchange of iCalendar data and iTIP methods within e-mail. iTIP extends iCalendar to include methods that allow collaboration, such as responding to a meeting request or requesting someone's free/busy data." The iTIP standard outlines how these publish/request/respond methods ensure the same action is taken on both the sender's and receiver's objects.
The Beauty of SyncML
Calendaring object properties, transport protocols, and object methods make it possible to create and respond to calendaring objects, such as events. But how does your schedule information get and stay updated, on your PC client, your PDA, and your phone? Enter SyncML.
SyncML was developed as a standard protocol to synchronize data between any application, device, or datastore over any network. Built on the XML standard, it homogenizes synchronization across devices and applications, and conveniently synchronizes data over the internet and wireless internet without desktop conduit dependency. The first SyncML-supported data types were calendar and contact data, because their data representation standards were already well defined.
"The beauty of SyncML is that it's completely network agnostic," says Bonfante. "A SyncML client connects to the SyncML server over HTTP, using any technology such as Bluetooth, GSM, GPRS, WiFi, or even a simple cradle connection to the LAN. The SyncML client can be installed on any phone, PDA, or laptop—any kind of device or application, as long as it's connected to the internet." While not limited to mobile applications, SyncML was built with small footprint and bandwidth needs in mind.
SyncML acts as a mediator between datastores, reconciling differences between them. Data is represented in standard format, including iCalendar, vCalendar (iCalendar's less capable predecessor), and vCard, wrapped in standard SyncML markup. When a user initiates a sync using a SyncML client to connect to another datastore, such as a calendar server, the client and server connect over HTTP. The SyncML-based synchronization server pulls the delta, or change, between the calendar server and the SyncML client on the device since the last sync from both datastores, applies rules to reconcile the data, and sends the resolved data to both data-stores. The sync server ensures the data is synchronized on both sides, which may include intelligently reconciling conflicting calendar event entries.
Because SyncML can be used with any datastore, device, or application, SyncML-based synchronization can occur between a desktop and device,
a device and corporate datastore, or two corporate datastores. Although it doesn't provide a real-time mechanism for disparate system coexistence, SyncML can be used as a bridge between datastores.
"SyncML doesn't replace iMIP/iTIP," adds Robillard. "It makes sure your data is current on whatever server you have an account. But if you're in the sales department using Exchange, and I'm in the engineering department using Domino, we're still stuck exchanging iMIP/iTIP attachments." SyncML can be used, however, to make sure both departments' datastores are synchronized—provided each is SyncML-compliant—so that users on system A can see the same information as users on system B.
The Future is CAP
The long-debated CAP, currently an IETF internet draft, may be proposed as a standard within months. CAP changes the nature of calendaring by allowing applications from different vendors to exchange data and take action in a real client/server scenario.
"That's the big promise of CAP," explains Bonfante. "It bypasses the
e-mail transport issue within the organization and gets calendar applications collaborating in real-time through this common protocol. It's trying to accomplish real-time retrieval and operations on standard calendar objects. It won't matter what client and server applications you're using—Oracle, Microsoft, IBM—the calendaring data and actions will reach into the application, interoperate, and just work."
CAP uses iCalendar, but it's really a communications protocol—the equivalent of IMAP4, the e-mail standard, within the calendaring realm. Much of the proposed CAP standard focuses on how client applications interact with the calendar datastore so users can directly access calendar data.
"CAP is about establishing a real-time environment for interoperability within
an organization, as opposed to the current method that's simply sending e-mail
messages back and forth, where transport delays and errors often cause duplicate entries and conflicts," Bonfante says.
When approved, CAP will offer a real-time calendaring framework that's finally network and application agnostic. And that will be an invitation to a calendaring event we all can accept.
Joe McKee (words4hire@hotmail.com) is a freelance reporter covering emerging internet technologies. He has 10 years of experience in software development and WAN design.
|
Oracle Collaboration Suite Supports Standards
By implementing standards for formatting, transporting, and storing calendar data, Oracle Collaboration Suite sets the stage for the synchronization and unification of enterprise data.
Oracle Calendar, within Oracle Collaboration Suite, supports object-oriented calendar events such as iCalendar, vCalendar, and vCard.
Oracle Sync Server offers direct two-way synchronization with Oracle Calendar server over any standard HTTP connection, making the calendar infrastructure available to any SyncML-compliant device or application with internet access. The Oracle Sync Server architecture can also be extended to support server-to-server synchronization, or to provide sync functionality to third-party calendar infrastructures.
Oracle Calendar plans support for the iCalendar Message-based Interoperability Protocol (iMIP) and the iCalendar Transport-independent Interoperability Protocol (iTIP) standards. And when the Calendar Access Protocol (CAP) standard is finalized, look for Oracle Calendar to support it.
Oracle is a full member of the Open Mobile Alliance (OMA), the working group responsible for the development of the SyncML standard. Oracle is also a participant and major contributor to the Internet Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) workgroup, responsible for the creation and development of iCalendar, CAP, iMIP, and iTIP.
|
|
Bookmark
