I received some very good feedback and questions on the first two parts of the Service Oriented Scheduling (SOS) series. In particular, there were questions the relationship between EMIX and WS-Calendar, about the difficulty of creating Calendar artifacts, and about some elements that have been missing from traditional Calendar communications. In this post, I will try to address these.
How do EMIX and iCal relate. Is EMIX an extension of iCal that could be processed by generic iCal tools? Or does it just use the format?
iCalendar is a specification for communications, currently defined by the Internet Engineering Task Force (IETF) in the specification RFC 5545. iCal is particular implementation on Apple systems that exchanges iCalendar information. RFC5545 defines a general pattern for creating schedule components, as well as specific semantics for information within those components. RFC5545 further defines specific components including the VTODO, VJOURNAL, VFREEBUSY, VALARM, and, most familiar to most of us, VEVENT. Each component is defined as a bundle of properties and parameters; each property can have parameters, and each parameter can have properties.
Other RFCs (specifications) published by the IETF define additional components that follow the general patterns and semantic rules established by RFC 5545. VAVAILABILITY and VPOLL are two examples of new components that follow the pattern and semantics of RFC 5545 and so conform to that specification but are part of that specification.
These specifications are so widely used that a number of specialized interactions have been codified. RFC 5546 defines the iCalendar Transport-Independent Interoperability Protocol (iTIP) as well as a mail-based version (IMIP). Many calendar servers support using WebDAV (Distributed Authoring and Versioning) to support scheduling and updating, a specification known as CalDAV (RFC 4791 and RFC 6638). There are many more.
All of these specifications are described, loosely, as iCalendar or iCal.
Each of these communications relied on strings of text that many find quirky to create, quirky to read. Almost every popular calendar system implemented only part of the specifications. To address this confusion, the Calendar and Scheduling Consortium (CalConnect) formed, with wide industry participation, to address issues of interoperability and to further advance these specifications.
In parallel with the formation of WS-Calendar, CalConnect began defining rules for XML serialization of iCalendar objects. The OASIS WS-Calendar Technical Committee prepared normative XML schema (XSD) for iCalendar. XML Schemas can be consumed by many programming tools, removing the drudgery and human errors from creating valid XML artifacts. The two committees worked together closely on this project.
There has been some interoperability testing between these XML artifacts and several “main-line” systems. The open source enterprise calendar “Bedework” is the best source for XML-based exchanges between calendar systems.
Do service interactions require a specific protocol? Must they use XML or can they use JSON or other technologies?
Service Oriented Architecture (SOA) is a style of integration. SOA does not specify any particular protocol or binding. XML over HTTP is the most common, REST and SOAP are the most commonly used implementations of SOA ,but there are others. The CalConnect group is currently defining a standard for JSON serialization of iCalendar objects.
We tried using iCalendar before. We ran up against a wall with granularity. It was too hard to model complex behaviors. Does WS-Calendar address this?
The biggest differences between XML iCalendar and WS-Calendar is that WS-Calendar added some elements for finer grained control and project management type interactions.
Tolerance, precision, and granularity are new semantic elements in WS-Calendar. One can specify whether a response must be at exactly 8:15 am, or can be five minutes early, or up to 10 seconds late, etc. A requester can indicate what precision is required in tracking and reporting time. Granularity combined with vAvailability adds some interesting service advertisement. Consider a service that is available between 9:00 and 10:00 with a granularity of 15 minutes. Such a service can be scheduled only at 4 times: 9:00, 9:15, 9:30, and 9:45.
WS-Calendar also defined temporal relationships. Temporal relations allows the programmer to define schedule sub-routines, known as Sequences. iCalendar already defined relationships as a means to express the two events were related to each other. Temporal relationships describe how to fit events together. B must start right after A. C must start 10 minutes after B ends. D and C must finish at the same time. Events A, B, C, and D together make a Sequence. Each of these events is a valid iCalendar component.
Through a simple algebra of time, if you provide a start time for any of these events, you define the respective start-times for all. WS-Calendar also added a component to advertise and to schedule sequences. A Sequence can be advertised with a single service entry point. Invoking that service includes providing that single start time. The sequence, once defined, can be invoked again and again.
What is the relation between EMIX and WS-Calendar. Does every calendar server understand EMIX?
EMIX is not part of WS-Calendar. iCalendar has included the capability of including a MIME component inside, say, a vEvent. In WS-Calendar, we extended this to include options for an XML payload inside a vComponent.
In energy markets the time and schedule of delivery is very important. EMIX incorporates semantic elements from the WS-Calendar. Some EMIX components are valid iCalendar artifacts. Others are not, but can be transformed into WS-Calendar components or sequences.
When an EMIX element describes time and duration, it does so by reference to and incorporation of the WS-Calendar schema. A parsing routine that understands a duration as expressed in WS-Calendar, will correctly parse a duration as expressed in an EMIX Term.
What industries are likely to adopt EMIX and WS-Calendar first. Is there a codebase out there that includes early adopters? Are any large companies developing products that uses these standards?
CalConnect members tested interactions between existing enterprise calendar systems as these specifications were being developed. As noted above, BedeWork is a good source for implementation. The Paris office of the ARC Informatique has developed a WS-Calendar interface to the building management systems.
WS-Calendar and EMIX are each incorporated into the OASIS Energy Interoperation specification. The OpenADR Alliance is defining interoperable profiles of Energy Interoperation just as the WiFi Alliance defines interoperable profiles of 802.11. OpenADR Alliance members include are an international list of the largest and best known engineering and technology companies as well as some of the largest electric utilities in North America.
OpenADR is being used to implement wide-area distributed scheduling of energy consumption. OpenADR has a limited view of scheduling, based on the times when there is not enough electric power available. Other groups, such as the Transactive Energy Association are exploring more general use of Energy Interoperation.
This series of posts is about using WS-Calendar and a small portion of EMIX for more general purposes.