SynCFr: Synchronization Collaboration Framework L. Ardissono, A. Goy, G. Petrone and M. Segnan Dipartimento di Informatica, Università di Torino Corso Svizzera 185, 10149 Torino, Italy liliana,goy,giovanna,marino @di.unito.it Abstract We present the SynCFr framework (Synchronization Collaboration Framework) supporting the management of composite applications and the synchronization of heterogeneous applications and services cooperating within a shared context. SynCFr supports the management of services and applications based on Web APIs, REST interfaces and WSDL/SOAP interfaces. The key element of SynCFr is the Cross-Application Context, a shared dataspace used to collect and distribute the business data and synchronization information generated by the components to be integrated. By exploiting SynCFr, we developed an Integrated Collaboration Environment answering different organizational life needs, both in the user s private life, and in team collaboration. The Environment provides the user with a unified view of her activities in multiple collaboration spheres. This paper is going to appear in the Proceedings of the Fourth International Conference on Internet and Web Applications and Services (IW 2009). IEEE Press. 1. Introduction Currently, the e-collaboration is based on a variety of tools and services offering Web Conferencing [1], Application Sharing, Instant messaging, Electronic Whiteboard, Shared Workspace, Forum/discussion, and other similar functions. Moreover, earlier tools support people communication and individual scheduling needs; e.g., e-mail and calendar applications. Unfortunately, all these systems are available as distinct services: with the exception of some vertical tools developed in the project management area (e.g., [2], [3]), there are no integrated environments providing the users with a unified view of their activities. This is problematic, as people are often involved in different collaborations and processes, e.g., at work and in their private life, and demand for a single view of their commitments, impediments, and tasks to be fulfilled. However, in order to offer a user centric environment, the context information concerning the user s activities, and those of her collaborators, should be merged and exploited to support a context-aware execution of the applications integrated in the environment. Although Web mashup technology aims at integrating these kinds of services (e.g., see [4]), it currently offers limited support to e-collaboration because it does not enable the sharing of context information among applications. Thus, there is no integration, e.g. in terms of events sent to other applications when an activity has been completed. Moreover, if a team is involved in a human workflow, its members should be able to inspect the state of the process. Furthermore, they should be notified about the tasks they have to perform, depending on their role in the process. Notice also that current mashups cannot integrate straightforwardly WSDL/SOAP Web Services, which might have to be invoked in the backend of the applications. In order to address such issues, a new integration middleware is needed, which offers an intra-application and cross-application coordination layer. In this paper, we present SynCFr (Synchronization Collaboration Framework), which enables the synchronization of heterogeneous services and applications, such as WSDL/SOAP Web Services, RESTful services, and applications offering Web API, in a integrated environment. The key element of SynCFr is the Cross-Application Context, a shared dataspace used to collect and distribute the business data and synchronization information among the applications. The explicit management of the Cross-Application Context supports the synchronization of heterogeneous applications, which do not need to directly interact with each other in order to share information. Moreover, it supports the introduction of mediation techniques for data mismatches. Furthermore, it is the basis for a unified management of the context information and for the introduction of specialized information management and notification policies. SynCFr supports the integration of services and applications, both programmatically invoked through heterogeneous types of interfaces, and invoked by human users through a Web-based interface. Moreover, the framework supports a user-centric vision of the coordination of the multiple processes involving activities in different spheres of the user s life. As such, it contributes to take mashup technology one step forward towards the features offered by traditional Web Service composition (e.g., see [5], [6]), while preserving both the simple approach characterizing RESTful services, as well as a more flexible synchronization model. 1 1. Although the proposal to extend BPEL to support RESTful services [7] goes in this direction, it still suffers from the rigidity that characterizes composition by orchestration.
Based on SynCFr, we have developed a prototype Integrated Collaboration Environment (ICE) supporting the user in the management of home and work activities concerning different collaboration spheres. The ICE offers a document sharing application, an e-calendar and a process management service. Moreover, it can be extended with other applications which the user wants to utilize for her activities. The peculiarity of the ICE is the fact that the integrated applications are executed by explicitly taking the user s collaboration spheres into account. For instance, the notifications supporting the workspace awareness in each sphere are separately handled and can be filtered on the basis of the user s notification preferences. The ICE demonstrates the high flexibility of SynCFr, which offers advanced collaboration features as well as an open architecture, allowing the synchronization of heterogeneous applications. In the following, Section 2 presents a scenario motivating our work. Section 3 describes the our framework and Section 4 describe our prototype ICE. Section 5 compares our work to the related work and Section 6 concludes the paper. 2. A usage scenario for SynCFr Giorgio is a professor at a Computer Science University Department where he leads the Service-Oriented Computing research group. Beside his teaching activity, he coordinates the EuroPro international research project, and ItaPro national one. He has two children and he actively participates in their school activities. Since the CS Department adopted SynCFr, Giorgio is provided with a Web-based desktop supporting the coordination of his work activities. His Web desktop includes: Document Sharing; Calendar; Instant messaging and chat; Process Management Component; Admin Tool; Travel Agency Service. Moreover, Giorgio can include external components, such as the e-learning application hosted by the children s school server, which enables parents to manage the school activities. Lucy is a Ph.D student, working in the Service-Oriented Computing group. By means of the Process Management Component, used to handle the activities related to the two research projects, Giorgio assigned Lucy the task of attending a conference, related to the ItaPro project topics. Lucy utilizes the Admin Tool to manage the procedure (workflow) for organizing conference participation, from the authorization to the refunding step. The Admin Tool coordinates all the required activities: e.g., as soon as Lucy has filled in the authorization form, this is sent to the fund owner (Giorgio), who is alerted that he has to sign the form, and so on. Moreover, Lucy books a flight and a hotel, through the Travel Agency Service. While Lucy is attending the conference, the travel service notifies her that her flight was cancelled and she was rebooked on another flight, leaving the day after. Therefore, she connects to her Web desktop via PDA in order to modify the date of her return flight. The Admin Tool notifies the Administration Office about the change, and the workflow is automatically re-arranged with the new date. When Lucy is back to her office, she publishes a report about the conference on the Document Sharing Tool, so that Giorgio and the other group members can provide comments. Giorgio starts a chat in order to discuss Lucy s report and then he decides to schedule a meeting. When he opens his calendar, he discovers that he is already busy in the date he had in mind, with a parent meeting scheduled by the school application. Giorgio thus schedules the meeting the week after, invites all the group members, adds a task in the ItaPro workflow, and assigns it to Lucy. 3. The SynCFr framework The integration of separate e-services and applications poses two main architectural requirements. First, in order to develop an integrated environemnt hosting heterogeneous components, it is necessary to abstract from the details of their communication protocols; e.g., consider the access to an URL with respect to the invocation of a WSDL operation by means of a SOAP message, or the invocation of a Web API. Second, in order to provide a user centric vision of multiple applications, the context information generated by each of them has to be merged in a shared context. E.g., the user s impediments can be taken into account by different applications when a meeting has to be scheduled. In the research on distributed processes, several coordination models were proposed to enable the cooperation between heterogeneous systems, by abstracting from language and interaction protocol details; e.g., see [8]. In particular, data-driven coordination models are based on the Shared Dataspace metaphor, which decouples processes in both space and time by modeling their interaction as the access to a common, content-addressable data structure, used to post and retrieve information. Moreover, the data-driven coordination models use tuple-based coordination languages, such as Linda, which support the posting and the retrieval of complex data items. Technically, the posting and retrieval of data items from a Shared Dataspace has been implemented by means of the Publish and Subscribe pattern to support an efficient and robust interaction. In particular, the centralized management of the context information supports the data consistency management. This coordination model nicely fits our architectural requirements because it supports the exchange of possibly complex information between applications and it scales to the introduction of new applications and new data types. However, this model does not explicitly address the heterogeneity in the execution models of the components to be integrated (e.g., Web APIs, RESTful services and WSDL/SOAP Web Services). Therefore, we focused on
User Agent1 User Agent2 Cross- Application Context Group Manager Coordination Middleware Notification Manager Data Mediator Talk app Figure 1. Architecture of an ICE. app1 app2 app3 this aspect. Specifically, the integration of heterogeneous components in SynCFr is based on two main elements: The framework manages a Cross-Application Context which includes two types of information, uniformly represented as events: (i) Business data items to be used as input parameters when the operations of a software component are performed; (ii) Synchronization information, needed to trigger the execution of operations at the appropriate time. The Cross-Application Context is managed by a Coordination Middleware, which propagates the context information among components according to the Publish and Subscribe pattern. The framework manages the integrated applications (software components) as autonomous agents cooperating in a shared context. Components do not directly invoke operations on one other: their interaction is mediated by the Coordination Middleware, which supports the exchange of the context information needed to select the operations to be performed by each of them. The components are executed in context-dependent way by managing them as event-driven systems [9]; see below. The context information may concern the coordination of activities within a composite application; for example, the completion of a task, managed by a certain component, might enable the execution of an operation within another component. Moreover, some of the events and data items may concern different services utilized by the user. For instance, different processes involving the user might provide input to one another; e.g., a work related workflow could influence and provide input data or events to a home or family related workflow. 3.1. Architecture Figure 1 shows the architecture of an Integrated Collaborative Environment based on the SynCFr framework and is used in the following to describe the basic concepts introduced by our framework. Each software component is wrapped by a Communication Interface () which masks the differences in the execution models and supports a seamless integration of heterogeneous applications. The manages the interaction with the Coordination Middleware by offering suitable APIs for receiving context information from the Middleware and for notifying the Middleware about the context information generated by the component. Moreover, the maps the business data received from the Middleware to the local data handled by the wrapped component, and vice versa. Furthermore, the runs the component in an event-driven way [9], depending on the available context information. At component start time, the subscribes for the events relevant to the component. At runtime: The translates the events/messages generated by the component to external events and sends them to the Coordination Middleware. The external events represent the business data and synchronization information generated by the component. For instance, the might return the information acquired during the execution of a user task and inform the rest of the system that the task has been completed. The receives from the Coordination Middleware the events it has subscribed to; moreover, it steers the execution of the component. Specifically, when the business data and the synchronization information required for the execution of an operation are available, the invokes the operation on the actual parameters. Section 3.2 describes the event-driven execution of components. Although the is logically connected to the wrapped component, it may run on any remote server; e.g., the server hosting the Coordination Middleware, or a server owned by the user and permanently connected to the internet. 3.2. Event-driven component execution A software component can be run in event-driven way by triggering the execution of its operations, depending on the incoming events. In turn, such events may be originated by the fact that the user has performed some operations on another application, or they may depend on the execution of automated activities within another component. In order to run software components as event-driven systems, a has to be developed for each component to be integrated in a synchronization environment based on SynCFr. The structure of the depends on the nature of the component, and its implementation can be more or less straightforward according to the standard compliance of the component interface and its interaction model. E.g., in the case of a WSDL/SOAP Web Service, we have built more automatic support to the construction; see Section 3.2. For other types of components, we can only give guidelines,
Figure 2. ICE environment with two users. as explained in the following. The differences between the wrapped components also determine the complexity in the configuration settings of a, which can require the specification of a knowledge base or can be stored in a configuration file. Event-based and RESTful components. If the component is natively event-based, such as several User Interface components, or is a RESTful service, the is a relatively simple wrapper, to be implemented by taking the APIs of the component and of the Coordination Middleware into account. This is, e.g., the case of Web calendars (e.g., Google Calendar) and dynamic maps (e.g., Google Maps). Specifically, a has to invoke an operation on its component when the input parameters of the operation are available. E.g., if a Google Map is part of a larger application supporting the management of meetings and conference participation, it should be refreshed when the user inputs the location of a meeting and searches for travel information. When the component performs an operation, the has to notify the Coordination Middleware about the output information generated by the operation (if any) and, possibly, about the completion of the operation (e.g., a human task). The must also map the application s events to those expected by the other applications integrated in the synchronization environment. WSDL/SOAP Web Services. The of a WSDL/SOAP Web Service is more complex because a Web Service exchanges SOAP messages with its interacting peers, but the Coordination Middleware supports the posting and the retrieval of events. In order to leverage the development of the, we propose a general model supporting the eventdriven execution of a Web Service based on a declarative description of its interaction protocol; see [10]. Specifically, the can be developed as a Web Service consumer which mediates the interaction between the wrapped Web Service and the Coordination Middleware. The has to invoke the WSDL operations offered by the Web Service and it has to intercept its outbound messages. Moreover, the has to propagate the generated context information to the Coordination Middleware via APIs. In order to enable the context-dependent invocation of WSDL operations, each operation can be described as an action of an autonomous agent. The idea is that the operation can be performed when its input parameters are available and the partial order relations on inbound/outbound messages imposed by the interaction protocol of the Web Service are satisfied. In our model, such relations are enforced by associating each operation with an applicability condition specifying the synchronization constraints to be satisfied before the invokes the operation; see [10]. During the Web Service execution, the checks whether any WSDL operation can be invoked. If so, the invokes the operation, retrieves the results and propagates the synchronization information and the output data just generated. When the receives an outbound message from the wrapped Web Service, it propagates the related business data and synchronization information. For configurability purposes, the actions are specified in a knowledge base, the KB, which stores: (i) the applicability conditions for the invocation of the WSDL operations offered by the Web Service; (ii) the input and output data items and synchronization information associated to WSDL operations and outbound messages, and (iii) their bindings to the data of the Cross-Application Context.
Figure 3. Giorgio s Web Desktop. 4. Prototype We have developed a prototype Integrated Collaboration Environment (ICE) based on SynCFr. The scenario is the coordination of personnel activities (professors, students, etc.) in a University Department, supporting also their private life activities. The ICE provides the user with a unified view of her commitments and activities in multiple collaboration spheres, which can involve different user groups. Moreover, it supports a personalized management of the workspace awareness, in order to help the user to separately handle the notifications concerning her collaboration spheres. Figure 1 shows the architecture of our ICE. The core includes the Coordination Middleware and the components supporting the ICE management. Specifically, the User Agent manages the user s identity, it tracks the collaboration sphere she is working at and it handles the user s notification preferences (e.g., notifications can be filtered on a relevance basis). The Group Manager manages the groups of users belonging to the various collaboration spheres. The Notification Manager mediates the delivery of notifications to the user, according to her preferences. This component exploits an Instant Messaging (IM) Application to generate the notification messages. The Data Mediator addresses data mismatch problems by reading the context data in the Cross- Application Context and applying transformation rules to generate new context data, in the required formats. Within an instance of the core, other applications can be integrated as components providing specific services. For instance, our ICE embeds a document sharing application (Google Docs), a calendar tool (Google Calendar) and a process management component which handles the workflows of University projects. Figure 2 depicts the components integrated in our prototype and sketches the Web Desktops of two users: User1 (Giorgio) and User2 (Lucy). The Coordination Middleware exploits GigaSpaces [11], which supports the propagation of data items according to the Linda tuple space model. GigaSpaces, which is Javabased, manages the propagation of serializable objects, thus supporting the propagation of complex information items between software components. Our Process Management Component (PMC) is a lightweight, Java-based workflow management application. It handles the execution of a graph of activities the members of a team must perform to complete a project. The progress in the execution depends on the events which the PMC receives. Such events are generated depending on the users actions (e.g., the completion of a task), or on the execution of other ICE applications. Figure 3 shows a snapshot of Giorgio s Web desktop, which is implemented as an igoogle page and contains Google Gadgets. The PMC displays the status of the graph execution by means of a Gadget (Activity Report). Notice that this is the best representation of our idea of a Webbased dashboard including views (Gadgets) on independent applications. However, there is no architectural commitment to use an igoogle page as the main User Interface. 5. Related work Team, Group, Collaboration & Sharing Tools enable teams or other groups to share files and collaborate to manage projects, e-learning activities or other distributed work. A Collaboration Environment, accessible by any browser, builds a common workspace to share documents,
ideas, experiences, organizing information in a way easier to search and exploit. However, these tools are mostly available as Project Management vertical tools [3], [2]. Our work is different because SynCFr offers a general integration model, suitable for developing various kinds of collaborative applications. In contrast, such tools are based on vertical architectures, cannot be exploited in different domains, and manage hard-wired processes which cannot be modified to meet different process requirements. [12] points out that Web mashups offer very little support in terms of models and tools for presentation integration. Thus, the presentation aspect of most mashups is developed by means of ad hoc scripts or general purpose programming languages, which are little reusable. Indeed, some work attempts to standardize the mashup development; e.g., the IBM Sharable code platform provides a language and a set of Web-based tools to develop well-structured mashups [13]. Even though such proposals enhance mashup technology, they do not address other issues, which limit its applicability to the integration of applications. As discussed in [14], mashups are unsuitable for Enterprise Application Integration with a long lifespan and advanced QoS requirements because they fail to provide features such as transaction management and security. Moreover, we claim that mashup technology makes the integration of applications cumbersome, as the various components are not provided with a flexible context propagation mechanism. While we are interested in application scenarios where QoS requirements are not central, e.g., e-learning, team management and human workflows, the second limitation is a major problem for us. Our work advances the state of the art in mashup technology on this respect, thanks to the introduction of a Cross-Application Context supporting the propagation of business data and synchronization information between heterogeneous services. Similar to [12], we adopt an event-based model for managing the interaction between components. However, our event-driven execution model supports the integration of heterogeneous software, e.g., Web APIs and WSDL/SOAP Web Services. In particular, SynCFr supports the integration of composite applications based on orchestration engines satisfying different application requirements; e.g., lightweight engines and Web Services orchestrators. This feature makes our work more general than [15], which introduces a specific language to compose heterogeneous applications. 6. Conclusions The SynCFr framework supports the integration and synchronization of heterogeneous services and applications based on Web APIs, REST and WSDL/SOAP interfaces. SynCFr is based on (i) the introduction of wrappers, which mediate the interaction between heterogeneous software components, and mask the differences in their execution models; (ii) the management of a Cross-Application Context for the propagation of business data and synchronization information between the integrated software components. We exploited SynCFr to develop an Integrated Collaboration Environment supporting team collaboration in work and home scenarios. Although the Environment currently provides few collaboration functions, it can be seamlessly extended with external components. In the future, we will enhance SynCFr to address privacy issues in the management of the Cross-Application Context. References [1] Adobe, Acrobat connect, http://www.adobe.com/products/acrobatconnect/, 2008. [2] ActiveCollab, Project management & collaboration, http://www.activecollab.com/, 2008. [3] Collanos, Products overview: Team enabling professionals, http://www.collanos.com/en/products, 2008. [4] J. Yu, B. Benatallah, F. Casati, and F. Daniel, Understanding mashup development, IEEE Internet Computing, no. September-October, pp. 44 52, 2008. [5] M. Papazoglou and D. Georgakopoulos, Eds., Service- Oriented Computing. Communications of the ACM, 2003, vol. 46, no. 10. [6] OASIS, OASIS Web Services Business Process Execution Language, http://www.oasis-open.org/ committees/documents.php?wg abbrev=wsbpel, 2005. [7] C. Pautasso, BPEL for REST, in Proc. of BPM 2008, LNCS 5240, Milan, Italy, 2008, pp. 278 293. [8] G. Papadopoulos and F. Arbab, Coordination models and languages, in Advances in Computers. Academic Press, 1998, pp. 329 400. [9] R. Lu and S. Sadiq, A survey of comparative business process modeling approaches, in Proc. of 10th Int. Conf. BIS, LNCS 4439, Poznan, Poland, 2007, pp. 82 94. [10] L. Ardissono, R. Furnari, A. Goy, G. Petrone, and M. Segnan, An event-based model for the management of choreographed services, in LNCS n. 5183, E-commerce and Web technologies, Springer-Verlag, 2008, pp. 51 60. [11] GigaSpaces, GigaSpaces SBA, http://www.gigaspaces.com/pr overview.html, 2008. [12] B. Benatallah, F. Casati, F. Daniel, and M. Matera, A framework for rapid integration of presentation components, in Proc. of WWW 2007, Banff, Canada, 2007, pp. 923 932. [13] E. Maximilien, A. Ranabahu, and K. Gomadam, An online platform for Web APIs and service mashups, IEEE Internet Computing, no. September-October, pp. 32 43, 2008.
[14] C. Pautasso, O. Zimmermann, and F. Leymann, RESTful Web Services vs. big Web Services: making the right architectural decision, in Proc. of WWW 2008, Beijing, China, 2008, pp. 805 814. [15] F. Rosenberg, F. Curbera, M. Duftler, and R. Khalaf, Composing RESTful services and collaborative workflows, IEEE Internet Computing, no. September-October, pp. 24 31, 2008.