With the emerging use of electronic calendars services on the Internet the users are constantly increasing the number of calendar platforms they use and the need to have them synchronized in one place is increasing. In this paper we discuss the evolution of the electronic services for calendars, and give overview of the APIs they use, along with protocols and interfaces to these services. We introduce an idea to create Calendar Service Agent as a software agent in order to exchange, modify and synchronize information about events from different calendar platforms. The solution is explained by protocols and patterns, as well as the structure and architecture, and platforms included.
Nowadays almost every person that uses electronic services also uses calendars offered by different providers. The main purpose is to schedule or share information about meetings, activities or events. Somehow every person becomes conformable using and depending upon usage of this electronic service as reminder and organizational tool.
A lot of services are offered on the market and a typical Internet user starts to use (or is forced to use) new calendars for different purposes (new work position, new group, etc.). The problem arises when at certain point one has to check several calendar services in order to synchronize all the events (even those not written in calendars) and to avoid overlapping or missing an event.
A typical architecture of different calendar usage is presented in Figure 1 showing how an user connects to multiple popular calendar services (using appropriate GUIs) in order to check the events and schedules. These activities can be also exhausting.
In this paper we give an overview of possibilities to exchange and gather different information from various calendar providers. Several conceptual models have been proposed: • Compatible Collaborative Calendar-Server (CCS) Web
Services [
Yet all these solution do not include most of todays’ popular calendar services.
The idea about calendar integration is offered by some existing products, like Hipmunk and Nimble - social CRM, but they are neither stand-alone products nor they cover only some of popular calendar platforms.
Our initial motivation in this research was to exploit the calendar interoperability and to create a stand-alone software agent which joins all the popular calendar services at one place and offers the users a possibility to join all their calendar and scheduling events at one place, unlike the multiple calendar scenario shown on Figure 1. Also our goal was to exploit the existing technologies to ease the usage of multiple calendars.
The paper is organized as follows. Section 2 presents the common establish and used protocols concerning calendars and web services. Section 3 briefly describes the characteristics of the calendar platforms we have used. Section 4 gives architectural and structural overview of the new proposed solution. Finally we conclude our work and describe our future work in Section 5.
The need for storing calendar events and sharing
standards about event storage and organization emerged in 1996
due to the big number calendars and scheduling products
and their limitation to exchange information only among
users within the same system. At that moment some
proprietary standards existed, but there was no single and open
specification. A working group of Internet Engineering Task
Force (IETF) was created and this group outlined three key
areas for future standardization: exchange format,
interoperability protocol and access control [
This Calendaring and Scheduling (CalSch) workgroup over time produced few standards: • Internet Calendaring and Scheduling Core Object Specification (iCalendar), • iCalendar Transport-Independent Interoperability Protocol (iTIP) and • iCalendar Message-Based Interoperability Protocol (iMIP).
Today iCalendar is widely used standard used by a large
number of popular calendar products like Google
Calendar [
In the following sections we give a short explanation about iCalendar protocol, the WebDav protocol and the REST framework. We will also explain the oAuth security protocol, which is widely used by the calendar services providers.
Internet Calendaring and Scheduling Core Object
Specification (iCalendar) standard defines ”data format for
representing and exchanging calendaring and scheduling
information such as events, to-dos, journal entries, and free/busy
information, independent of any particular calendar service
or protocol ” [
It defines a MIME content type and enables exchange
using several standard transport protocols (like HTTP and
SMTP), different file systems and more types of transport
and communication. It provides mapping of the content
type to set of messages for calendaring operations [
The first version of the HTTP Extensions for Distributed
Authoring (WEBDAV) specified ”set of methods, headers,
and content-types ancillary to HTTP/1.1 for the
management of resource properties, creation and management of
resource collections, namespace manipulation, and resource
locking (collision avoidance)” [
This protocol was initially created for remote Web site
authoring and it supports remote collaborative authoring of
Web sites and individual documents, as well as remote access
to document-management systems [
Calendaring Extensions to WebDAV (CalDAV) defines
”extensions to the Web Distributed Authoring and
Versioning (WebDAV) protocol to specify a standard way of
accessing, managing, and sharing calendaring and scheduling
information based on the iCalendar format” [
The CalDAV protocol provides three key features:
calendar maintenance, calendar queries and calendar security
[
REST is a framework that defines Web Services with
focus towards resources rather than operations. In the REST
style interactions do not depend on any context stored on a
server [
The four basic design principles of REST web services are
[
The OAuth 2.0 protocol provides secure authorization in a simple and standard method from web, mobile and desktop applications. Third-party applications are using this protocol to obtain limited access over the private user data stored on different information system without knowing the user credentials.
The simplest explanation of the OAuth protocol says:
”For most people, their car is one of their most valuable
possessions, valued in tens of thousands of dollars. They are
convenient places to leave our other valuables like computers
and clothing. Yet we are sometimes required to give them to
a parking attendant or valet whom we’ve not met before. A
valet key solves the problem - it’s an access token with limited
rights that can operate the vehicle but not grant access to the
trunk or glove box.” - Eran Hammer [
User credentials are replaced with single text string called Access Token entrusting the client (third-party app) with limited access over the user data. For obtaining access token user grant is needed.
Validity of the token expires after certain amount of time however, if needed third-party application can be de-authorized and the generated token will be non-valid. Different platforms encourage different access token life times based on their security projections.
There are three types of tokens: BEARER TOKEN, MAC TOKEN and SAML. Services that we were using have implemented the OAuth protocol using the BEARER TOKEN which actually is big randomly generated number. Implementation of OAuth protocol which consumes BEARER TOKEN has to encrypt all service calls using SSL encryption.
Figure 2 depicts the so called oAuth dance is presented with a simple sequence diagram representing the oAuth 2.0 protocol way of work.
In this section we overview of the calendar platforms used in this research and their evolution. 3.1
The calendar service agent is working with a variety of platforms constructed by the social networking prodigies such as Facebook and Google followed by Microsoft. Their calendar services are popular and it’s only natural that clients would want them easy accessible altogether.
In last 10 years Google, Facebook and Microsoft have created their own APIs and services regarding their calendars in order to create the best possible solution for their clients and the developers working with their platforms. By employing different technologies and techniques they all converged to probably, the best solution nowadays. This is the reason behind the fact that all the platforms i.e. Facebooks Graph API, Googles Callendar APIv3 and Live Connect API include communication by using REST and authenticate external application with oAuth 2.0 protocol. Besides the functional similarities, the platforms clearly differ as they all employ different information systems.
An essential difference between the companies and their APIs is in their business logic. Google divides their APIs in spite of Microsoft Live and Facebook who use one API to share everything. The division of APIs means that the client produces API dedicated access token whereas Facebook and Microsoft Life in order to limit their clients only to certain privileges generate different access tokens using the same API.
Another obvious difference between APIs is the format of the request and response messages, although they are all using REST web service and communicate using basic HTTP verbs. 3.2
Platforms are subjects to constant improvement and evolution. During 2011 majority of the platforms started to deprecate the OAuth 1.0 protocol with his known security flaw. Main purposes of the evolution from 2011 were concentrated on enhancing the security of the APIs. However, the evolution is still ongoing and the new trends are demanding standardization of the APIs which will result in decreasing the learning curve for the APIs. The Calendar Service Agents had to evolve together with the changes of each platform.
Since October 2011 Facebook platform migrates to OAuth
2.0 and completely removed former Legacy Connect Auth
[
Enhancing the security Facebook announced that from
October 2012 long-lived tokens which never expired will be
replaced with tokens which are valid up to 60 days [
Google in the version 3 of the Calendar API will replace
GData response format with JSON data objects In order to
satisfy clients needs Google decided to keep GData response
format active, minimizing the clients costs for migration [
In this section we describe the architecture of the new proposed software agent for calendars. Due to popularity of web services, the calendar service agent is in fact a web service.
For our research we have developed a prototype using Java EE. Data for the web service is being stored in the MySQL database. The calendar agent is constructed as a RPC style web service using SOAP messages for communication. Data in the messages are structured as JSON strings because of JSONs’ clean structure and in order to make the web service easy to use and integrate. The whole calendar agent architecture is depicted in Figure 3.
The calendar agent was implemented using the ”facade” design pattern by integrating and wrapping up three other private subagents that can’t be accessed from an external agent. Each subagent has assignment to execute a task on a particular platform and to store the results from the task in the database. Clients can only access the calendar agent by sending authentication details wrapped in a single JSON message. The message has to be SSL encrypted and its contents vary depending on the task being executed. If the task is successful then the results are stored in the database and sent back to the user like JSON string.
Figure 4 depicts the structure of the calendar agent. Private factory methods, that generate instances of subagents, construct the calendar agent. Each subagent respectively implements entire logic for executing tasks for the dedicated platform. Scalability for the calendar agent is being ensured by following the open/closed object orientated principle for subagent development.
The number of accounts the clients can have is unlimited. Registration of each account requires valid access token that will be stored in the database of appropriate calendar agent.
Functions implemented in the current calendar agent are: • Fetch events, • Create event, • Update event and • Delete event.
This paper shows how to exploit and compose together the possibilities of calendar interoperability offered by the existing and popular calendar solutions. We have succeeded in our intention and we have created Calendar Agent Services as a one check point for the most popular calendars the user have today. With this application the user don’t have to check all the different calendar services he/she uses on their native platforms, but to have them all in one place. This solution is service-oriented, easily scalable and modifiable and it includes the popular calendar services. The whole solution is built with web services, so the interface can be changed very fast and it is easily adoptable and maintainable to different device platforms.
Calendar Service Agents is not the only calendar
synchronization and exchange calendar solution. There are a lot of
Desktop calendar solutions like Desktop Calendar [
Our solution it is unique, it is based on web services, offers more adaptability since it can be reached from any browser (including smart phone browsers) and includes today most popular calendar services.
Calendar Service Agents is a project that constantly evolves and adapts. In the last year we had to make a lot of changes due to change of platforms by different calendar providers, changed APIs or authentication protocols. At the moment we provide user interface that can be used via browser.
Our next milestone is to extend this project with mobile applications for Android and iOS and to include other popular calendar services. We also want to include oAuth 2.0 authentication for our agent and to create REST web services for our project, beside the standard RPC solution. Our further future work include extending the research to wide-range cloud-based SaaS calendars interoperability.