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