=Paper=
{{Paper
|id=None
|storemode=property
|title=Service Agents for Calendar Exchange
|pdfUrl=https://ceur-ws.org/Vol-920/p142-kostoska.pdf
|volume=Vol-920
|dblpUrl=https://dblp.org/rec/conf/bci/KostoskaVBRG12
}}
==Service Agents for Calendar Exchange==
https://ceur-ws.org/Vol-920/p142-kostoska.pdf
Service Agents for Calendar Exchange
Magdalena Kostoska Goran Velkoski
Ss. Cyril and Methodius University Ss. Cyril and Methodius University
Faculty of Information Sciences and Computer Faculty of Information Sciences and Computer
Engineering Engineering
16 Rugjer Boshkovikj 16 Rugjer Boshkovikj
Skopje, FYR Macedonia Skopje, FYR Macedonia
magdalena.kostoska@finki.ukim.mk velkoski.goran@students.finki.ukim.mk
Krste Bozinoski Sasko Ristov
Ss. Cyril and Methodius University Ss. Cyril and Methodius University
Faculty of Information Sciences and Computer Faculty of Information Sciences and Computer
Engineering Engineering
16 Rugjer Boshkovikj 16 Rugjer Boshkovikj
Skopje, FYR Macedonia Skopje, FYR Macedonia
bozhinoski.krste@students.finki.ukim.mk sashko.ristov@finki.ukim.mk
Marjan Gusev
Ss. Cyril and Methodius University
Faculty of Information Sciences and Computer
Engineering
16 Rugjer Boshkovikj
Skopje, FYR Macedonia
marjan.gushev@finki.ukim.mk
ABSTRACT main purpose is to schedule or share information about meet-
With the emerging use of electronic calendars services on ings, activities or events. Somehow every person becomes
the Internet the users are constantly increasing the number conformable using and depending upon usage of this elec-
of calendar platforms they use and the need to have them tronic service as reminder and organizational tool.
synchronized in one place is increasing. In this paper we A lot of services are offered on the market and a typical
discuss the evolution of the electronic services for calendars, Internet user starts to use (or is forced to use) new calen-
and give overview of the APIs they use, along with protocols dars for different purposes (new work position, new group,
and interfaces to these services. etc.). The problem arises when at certain point one has
We introduce an idea to create Calendar Service Agent as to check several calendar services in order to synchronize all
a software agent in order to exchange, modify and synchro- the events (even those not written in calendars) and to avoid
nize information about events from different calendar plat- overlapping or missing an event.
forms. The solution is explained by protocols and patterns, A typical architecture of different calendar usage is pre-
as well as the structure and architecture, and platforms in- sented in Figure 1 showing how an user connects to multiple
cluded. popular calendar services (using appropriate GUIs) in order
to check the events and schedules. These activities can be
Categories and Subject Descriptors also exhausting.
In this paper we give an overview of possibilities to ex-
D.2.0 [Software Engineering]: General—Standards; D.2.11
change and gather different information from various cal-
[Software Engineering]: Software Architectures; D.2.12
endar providers. Several conceptual models have been pro-
[Software Engineering]: Interoperability
posed:
Keywords • Interorganizational Intelligent Meeting-Scheduler (IIMS)
Calendar protocols, calendar services, calendar interoper- [17],
ability
• Compatible Collaborative Calendar-Server (CCS) Web
1. INTRODUCTION Services [1] which exploit the iCalendar protocol,
Nowadays almost every person that uses electronic ser-
vices also uses calendars offered by different providers. The • Gadget for Personal Information Integration [5] which
performs data extraction and visualization, and
BCI’12, September 16–20, 2012, Novi Sad, Serbia.
Copyright c 2012 by the paper’s authors. Copying permitted only for private and
• Collaborator [12] which provides enterprise users with
academic purposes. This volume is published and copyrighted by its editors.
Local Proceedings also appeared in ISBN 978-86-7031-200-5, Faculty of Sciences,
a shared workspace to support the activities of virtual
University of Novi Sad. teams.
142
Today iCalendar is widely used standard used by a large
number of popular calendar products like Google Calen-
dar [18], Apple iCal [6], Microsoft Outlook [24], IBM Lo-
tus Notes [22] etc... Thanks to this protocol calendar files
can be shared and edited by using WebDav server, which
represents a RESTful interface.
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 proto-
col, which is widely used by the calendar services providers.
2.1 iCalendar
Internet Calendaring and Scheduling Core Object Speci-
fication (iCalendar) standard defines ”data format for rep-
resenting and exchanging calendaring and scheduling infor-
mation such as events, to-dos, journal entries, and free/busy
information, independent of any particular calendar service
Figure 1: User connection to multiple calendar or protocol ” [15].
providers via their GUI. It defines a MIME content type and enables exchange us-
ing several standard transport protocols (like HTTP and
SMTP), different file systems and more types of transport
Yet all these solution do not include most of todays’ popular and communication. It provides mapping of the content
calendar services. type to set of messages for calendaring operations [15].
The idea about calendar integration is offered by some
existing products, like Hipmunk and Nimble - social CRM, 2.2 WebDAV and CalDAV
but they are neither stand-alone products nor they cover The first version of the HTTP Extensions for Distributed
only some of popular calendar platforms. Authoring (WEBDAV) specified ”set of methods, headers,
Our initial motivation in this research was to exploit the and content-types ancillary to HTTP/1.1 for the manage-
calendar interoperability and to create a stand-alone soft- ment of resource properties, creation and management of
ware agent which joins all the popular calendar services at resource collections, namespace manipulation, and resource
one place and offers the users a possibility to join all their locking (collision avoidance)” [13].
calendar and scheduling events at one place, unlike the mul- This protocol was initially created for remote Web site
tiple calendar scenario shown on Figure 1. Also our goal authoring and it supports remote collaborative authoring of
was to exploit the existing technologies to ease the usage of Web sites and individual documents, as well as remote access
multiple calendars. to document-management systems [31].
The paper is organized as follows. Section 2 presents the Calendaring Extensions to WebDAV (CalDAV) defines
common establish and used protocols concerning calendars ”extensions to the Web Distributed Authoring and Version-
and web services. Section 3 briefly describes the characteris- ing (WebDAV) protocol to specify a standard way of access-
tics of the calendar platforms we have used. Section 4 gives ing, managing, and sharing calendaring and scheduling in-
architectural and structural overview of the new proposed formation based on the iCalendar format” [14].
solution. Finally we conclude our work and describe our The CalDAV protocol provides three key features: cal-
future work in Section 5. endar maintenance, calendar queries and calendar security
[9].
2. CALENDAR PROTOCOLS AND APIS 2.3 REST
The need for storing calendar events and sharing stan-
REST is a framework that defines Web Services with fo-
dards about event storage and organization emerged in 1996
cus towards resources rather than operations. In the REST
due to the big number calendars and scheduling products
style interactions do not depend on any context stored on a
and their limitation to exchange information only among
server [29]. The web applications using REST web services
users within the same system. At that moment some pro-
are being build based on data and data processing. The
prietary standards existed, but there was no single and open
main task is to identify resources [26]. Almost always this
specification. A working group of Internet Engineering Task
means cleaner and simpler service structure. By choosing
Force (IETF) was created and this group outlined three key
them as technology, Google, Facebook and Microsoft Live,
areas for future standardization: exchange format, interop-
confess that REST technology is very useful for data driven
erability protocol and access control [7].
applications and use the popularity of this kind of web ser-
This Calendaring and Scheduling (CalSch) workgroup over
vices to encourage more developers to use their services.
time produced few standards:
The four basic design principles of REST web services are
• Internet Calendaring and Scheduling Core Object Spec- [27]:
ification (iCalendar), • Use of explicit HTTP methods,
• iCalendar Transport-Independent Interoperability Pro- • Stateless design,
tocol (iTIP) and • Directory structured-like URIs and
• iCalendar Message-Based Interoperability Protocol (iMIP). • Transfer data using XML, JSON or even both.
143
3.1 Overview of the Included Platforms
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 cre-
ated 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 in-
clude communication by using REST and authenticate ex-
ternal 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
Figure 2: The so called dance of oAuth2 [2]. spite of Microsoft Live and Facebook who use one API to
share everything. The division of APIs means that the client
2.4 oAuth 2.0 produces API dedicated access token whereas Facebook and
Microsoft Life in order to limit their clients only to certain
The OAuth 2.0 protocol provides secure authorization in a privileges generate different access tokens using the same
simple and standard method from web, mobile and desktop API.
applications. Third-party applications are using this proto- Another obvious difference between APIs is the format of
col to obtain limited access over the private user data stored the request and response messages, although they are all us-
on different information system without knowing the user ing REST web service and communicate using basic HTTP
credentials. verbs.
The simplest explanation of the OAuth protocol says:
”For most people, their car is one of their most valuable 3.2 Platforms Evolution
possessions, valued in tens of thousands of dollars. They are
convenient places to leave our other valuables like computers Platforms are subjects to constant improvement and evo-
and clothing. Yet we are sometimes required to give them to lution. During 2011 majority of the platforms started to
a parking attendant or valet whom we’ve not met before. A deprecate the OAuth 1.0 protocol with his known security
valet key solves the problem - it’s an access token with limited flaw. Main purposes of the evolution from 2011 were con-
rights that can operate the vehicle but not grant access to the centrated on enhancing the security of the APIs. However,
trunk or glove box.” - Eran Hammer [21]. the evolution is still ongoing and the new trends are de-
User credentials are replaced with single text string called manding standardization of the APIs which will result in
Access Token entrusting the client (third-party app) with decreasing the learning curve for the APIs. The Calendar
limited access over the user data. For obtaining access token Service Agents had to evolve together with the changes of
user grant is needed. each platform.
Validity of the token expires after certain amount of time Since October 2011 Facebook platform migrates to OAuth
however, if needed third-party application can be de-authorized 2.0 and completely removed former Legacy Connect Auth
and the generated token will be non-valid. Different plat- [11]. Following Facebook, Google and Microsoft also started
forms encourage different access token life times based on using OAuth 2.0 as basic authorization protocol [19], [25].
their security projections. Enhancing the security Facebook announced that from
There are three types of tokens: BEARER TOKEN, MAC October 2012 long-lived tokens which never expired will be
TOKEN and SAML. Services that we were using have im- replaced with tokens which are valid up to 60 days [10].
plemented the OAuth protocol using the BEARER TOKEN Google in the version 3 of the Calendar API will replace
which actually is big randomly generated number. Imple- GData response format with JSON data objects In order to
mentation of OAuth protocol which consumes BEARER satisfy clients needs Google decided to keep GData response
TOKEN has to encrypt all service calls using SSL encryp- format active, minimizing the clients costs for migration [20].
tion. GData response format required additional client API to be
Figure 2 depicts the so called oAuth dance is presented installed in order to successfully retrieve data and installa-
with a simple sequence diagram representing the oAuth 2.0 tion of this client wasn’t trivial task.
protocol way of work.
3. OVERVIEW OF THE CALENDAR SER- 4. SOFTWARE AGENT ARCHITECTURE
In this section we describe the architecture of the new
VICE AGENTS proposed software agent for calendars. Due to popularity
In this section we overview of the calendar platforms used of web services, the calendar service agent is in fact a web
in this research and their evolution. service.
144
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 ser-
vice easy to use and integrate. The whole calendar agent
architecture is depicted in Figure 3.
Figure 4: Calendar Agent structure.
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.
Figure 3: Calendar Agent architecture. Calendar Service Agents is not the only calendar synchro-
nization and exchange calendar solution. There are a lot of
The calendar agent was implemented using the ”facade” Desktop calendar solutions like Desktop Calendar [28] and
design pattern by integrating and wrapping up three other Desktop iCalendar [8] but they are restricted in platforms
private subagents that can’t be accessed from an external and can be used only on the pre-installed computer. VueSoft
agent. Each subagent has assignment to execute a task on have developed VueMinder Calendar [30] but this solution
a particular platform and to store the results from the task supports windows platform only, does not support Facebook
in the database. Clients can only access the calendar agent synchronization and beside the regular price the user has to
by sending authentication details wrapped in a single JSON pay additionally to have synchronization in both directions.
message. The message has to be SSL encrypted and its Also the Blackberry Default Calendar (CICAL) [3], besides
contents vary depending on the task being executed. If the the limitation to the platform have issues with Facebook
task is successful then the results are stored in the database synchronization and by a lot of user have been declared as
and sent back to the user like JSON string. a non-user-friendly product. There a also a few Android
Figure 4 depicts the structure of the calendar agent. Pri- products like Smooth Calendar [4], Fliq Calendar [23] or
vate factory methods, that generate instances of subagents, CalDAV-Sync [16] but they are also limited only to the An-
construct the calendar agent. Each subagent respectively droid platform and not all them support all the popular
implements entire logic for executing tasks for the dedicated services.
platform. Scalability for the calendar agent is being ensured Our solution it is unique, it is based on web services, offers
by following the open/closed object orientated principle for more adaptability since it can be reached from any browser
subagent development. (including smart phone browsers) and includes today most
The number of accounts the clients can have is unlimited. popular calendar services.
Registration of each account requires valid access token that Calendar Service Agents is a project that constantly evolves
will be stored in the database of appropriate calendar agent. and adapts. In the last year we had to make a lot of changes
Functions implemented in the current calendar agent are: due to change of platforms by different calendar providers,
• Fetch events, changed APIs or authentication protocols. At the moment
we provide user interface that can be used via browser.
• Create event, Our next milestone is to extend this project with mo-
bile applications for Android and iOS and to include other
• Update event and popular calendar services. We also want to include oAuth
• Delete event. 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
5. CONCLUSION AND FUTURE WORK wide-range cloud-based SaaS calendars interoperability.
This paper shows how to exploit and compose together the
possibilities of calendar interoperability offered by the exist-
ing and popular calendar solutions. We have succeeded in 6. REFERENCES
our intention and we have created Calendar Agent Services [1] W. W. Ahmet Fatih Mustacoglu and G. Fox. Internet
as a one check point for the most popular calendars the user calendaring and scheduling core object specification
have today. With this application the user don’t have to (icalendar) compatible collaborative calendar-server
145
(ccs) web services. In International Symposium on rest architectural style. In IEEE 34th Annual
Collaborative Technologies and Systems, pages 12–17, Computer Software and Applications Conference
2006. (COMPSAC), pages 171–178, 2010.
[2] Z. Bi and X. Yu. Add oauth authentication support to [30] VueSoft. Vueminder feature overview.
httpclient, Dec. 2010. [31] J. Whitehead. Webdav: versatile collaboration
[3] Blackberry. How to merge multiple calendars into one multiprotocol. Internet Computing, IEEE, 9(1):75–81,
calendar on the blackberry smartphone. Jan.-Feb. 2005.
[4] C. Cedergren. Smooth calendar.
[5] C.-M. L. Chia-Hui Chang, Shih-Feng Yang and
M. Kayed. Gadget creation for personal information
integration on web portals. In IEEE International
Conference on Information Reuse and Integration,
pages 469–472, 2008.
[6] D. Crow. AppleâĂŹs ical and ical/vcal format.
[7] F. Dawson. Emerging calendaring and scheduling
standards. Computer, 30(12):126–128, Dec. 1997.
[8] Desksware. Desktop icalendar – internet desktop
calendar.
[9] L. Dusseault and J. Whitehead. Open calendar
sharing and scheduling with caldav. Internet
Computing, IEEE, 9(2):81–89, Mar.–Apr. 2005.
[10] Facebook. Authentication, 2012.
[11] Facebook. Completed changes, Jul. 2012.
[12] M. M. Federico Bergenti and M. Garijo. Collaborator
– enabling enterprise collaboration through agents. In
13th IEEE International Workshops on Enabling
Technologies: Infrastructure for Collaborative
Enterprises, pages 41–46, 2004.
[13] I. E. T. Force. Http extensions for distributed
authoring – webdav, Feb. 1999.
[14] I. E. T. Force. Calendaring extensions to webdav
(caldav), Mar. 2007.
[15] I. E. T. Force. Internet calendaring and scheduling
core object specification (icalendar), Sept. 2009.
[16] M. Gajda. Caldav-sync beta.
[17] C. Glezer. A conceptual model of an
interorganizational intelligent meeting-scheduler
(iims). Journal of Strategic Information Systems,
12:47–79, 2003.
[18] Google. Import events from icalendar or csv files.
[19] Google. Oauth 2.0 playground: Open to developers!,
Nov. 2011.
[20] Google. Migrating to google api java client, Jun. 2012.
[21] E. Hammer. Explaining oauth, Sept. 2007.
[22] IBM. Ibm lotus notes 8.5 icalendar: Interoperability,
implementation, and application.
[23] Mark/Space. Fliq calendar.
[24] Microsoft. View and subscribe to internet calendars.
[25] Microsoft. Windows live developer platform updated
with oauth 2.0 support and more, Jun. 2011.
[26] A. R. Mikko Hartikainen, Markku Laitkorpi and
T. Systa. How to drill down to rest apis: Resource
harvesting with a pattern tool. In 13th IEEE
International Symposium on Web Systems Evolution
(WSE), pages 135–140, 2011.
[27] A. Rodriguez. Restful web services: The basics, Nov.
2008.
[28] T. Software. About desktop calendar.
[29] H. S. Takeru Inoue, Hiroshi Asakura and
N. Takahashi. Key roles of session state: Not against
146