The ToxicFarm Integrated Cooperation Framework for Virtual Teams

Distributed and Parallel Databases, 15, 67–88, 2004 c 2004 Kluwer Academic Publishers. Manufactured in The Netherlands.
The ToxicFarm Integrated Cooperation Framework for Virtual Teams CLAUDE GODART PASCAL MOLLI GÉRALD OSTER OLIVIER PERRIN HALA SKAF-MOLLI LORIA, INRIA Lorraine, France godart@loria.fr; claude.godart@loria.fr PRADEEP RAY p.ray@unsw.au.edu FETHI RABHI School of Information Systems, Technology and Management, University of New South Wales, Australia Recommended by: Dimitrios Georgakopoulos Abstract. Developing a collaboration solution, that scales to an entire organization, that offers an integrated collection of cooperation tools, that is general enough to address a large range of applications, and that is easy to deploy for most people, is still an open challenge. This paper presents ToxicFarm services that are an integral part of a framework for hosting Internet virtual teams. The originality of this work is in providing a synthesis between contributions from different domains, including version management in software engineering, process management in data engineering, and awareness in groupware tools. The paper describes the overall services offered, discusses design choices for their integration and implementation, presents relations with existing work and describes their use in several emerging e-business application domains, such as e-finance, e-learning and e-telecom. Keywords: virtual teams, coordination, workflow, Awareness Provisioning, Web services, e-business, groupware 1. Introduction Due to the rapid growth in the number of virtual teams cooperating over the Internet and in the increasing complexity of the corresponding cooperative applications, there are now many tools that are intended to support such cooperation models. However, most of these tools are specialized in that they only deal with one facet of cooperation. They are either synchronous or asynchronous. The former include video-conference tools, IP-telephony, application sharing [29], collaborative tools, groupware toolkits [16] and real time editors [11]. The latter include forums, email, mailing lists and object sharing [2]. Some frameworks federate existing tools such as BSCW [5], SourceForge [34] and Lotus Notes [24] but none of them provides a complete collaboration solution. In addition, they are proprietary, not so easy to deploy, and require solid programming skills. Therefore, there is a need to develop collaboration solutions that are integrated, scalable to entire organizations, general enough 68 GODART ET AL. to address a large range of applications, and easy to deploy for most people. This presents a number of research challenges. This first challenge is to find the appropriate balance for the integration of different dimensions of cooperation. It cannot be achieved by simply juxtaposing contributions from different domains. If the right balance is found, these contributions should complement each other. For example, a workflow capability and an awareness capability put together can generate process awareness. On the other hand if the right balance is not found, a contribution could be a “parasite” in relation to another. For example, if awareness management and activity management are not synchronized, the environment may become unworkable. The second challenge is to address a large range of applications in a way that makes facilities like version management, workspace management and workflow definition usable by nonspecialist users. We believe that these two challenges must be addressed side by side in any solution. This paper reports on our experience in developing such an integrated environment called ToxicFarm. Initially, the objective of ToxicFarm was to develop an environment to support the co-design and co-engineering activities in the AEC (Architecture, Engineering, Construction) domain [14]. The idea was to develop an environment along the lines of BSCW and SourceForge but with extra features such as ease of deployment, and enhanced cooperation facilities for virtual team coordination. This environment is now more widely used to support co-authoring, co-design and co-engineering activities for a community of skilled workers. In addition, it is being applied to other domains such as e-learning, e-finance, and in some cases real usage analysis [20]. The paper is structured as follows. The next section introduces ToxicFarm services. Section 3 presents the ToxicFarm architecture and the technology used for its implementation. Section 4 discusses some related work. Section 5 describes some applications of ToxicFarm. Section 6 concludes the paper and presents future research directions. 2. Overview of ToxicFarm services As mentioned earlier, coordinating a virtual team requires the integration of several services that complement each other. In this section, we discuss the choices that were made to achieve this objective. We do not wish to discuss all the services at the same level of detail. While we focus on the more innovative aspects, i.e. data sharing, task coordination, and awareness services, we quickly overview other services such as project administration, communication, security, audit and mobility. 2.1. Cooperation model Before presenting services, we need to introduce ToxicFarm’s cooperation model. This model has its roots in the nature of cooperation itself. Through the use of tools, it has been applied on one hand, to the software engineering domain through the Copy/Modify/Merge (http://www.cvshome.org/docs/manual/) paradigm, and on the other hand to the groupware domain, typically in the Diverge/Merge model of Prospero [10]. Our approach emphasizes Multi-Synchronous Work where working activities proceed in parallel (multiple streams of activity), during which time the participants are disconnected (divergence occurs) and THE TOXICFARM INTEGRATED COOPERATION FRAMEWORK 69 periodically their individual efforts are integrated (synchronized) in order to achieve a consistent state and to make progress on the activities of the group” [9]. Cooperation is implemented by creating alternative contributing versions of a base object, merging them back into the base object, creating alternative versions and so on. Privacy between partners is generally achieved by maintaining a multi-space. This is a central repository which contains up-to-date versions of the shared objects. Each partner is associated with a private workspace where objects that need to be modified can be checked out. Before committing changes to the common repository, users must merge them with other changes committed to the repository since their last check out. This can lead to potential conflicts since it is possible for two people to modify the same file in their own private workspace. Such conflicts must be resolved before the file can be committed to the common repository (this can be done automatically or involve some communication between the people concerned). 2.2. Data sharing service The ability to share objects is the minimal condition for any cooperation. This service is also the more dependent on the cooperation model described above. It involves the management of a multi-space, i.e. different levels of workspaces. 2.2.1. Workspace management. As figure 1 shows, there is one referential directory (central repository) on a dedicated server (called central server) that contains all the objects Figure 1. ToxicFarm workspaces. 70 GODART ET AL. Figure 2. Private workspace and objects states. shared by all participants of the ongoing project. These objects are multi-versioned [8, 19], i.e. all the successive values of an object (in fact the delta between objects) are stored. This allows the recovery of a consistent state in case there are problems resulting in loss of data. The set of current versions of all objects in the referential repository constitutes the current state of the ongoing project. From a new user’s perspective, the first operation is to create a private workspace (see figure 2) by selecting the create workspace command of the current project page. This results in a directory that is a copy of the referential directory to be created on the server machine (in the private workspace). For convenience and/or mobility purpose(s), users can create a local workspace on their own machine that is a copy of their private workspace. This is achieved through the synchronizer tool (see figure 3), which requires a local directory for storing the workspace’s copy to be specified. Users can modify objects in their private workspaces on the server through a web interface. Alternatively, modifications can be made to the local workspace using any tools provided by the local system. Periodically, users can synchronize their local copy with the one in their private workspace using the synchronizer tool. There are two motivations for supporting the notion of local and private workspaces. The first one is that users can operate on objects using tools that are already familiar to them. The second one is to support mobility and remote work. For example, users can copy their private workspace on their laptops before disconnecting from the Internet and continuing to work at home, or when travelling. From time to time, users can reconnect to the Internet and THE TOXICFARM INTEGRATED COOPERATION FRAMEWORK 71 Figure 3. Synchronizer between local and private workspaces. synchronize their local workspaces with their private workspaces to save any modifications. While being reconnected, they can also update their private workspace with the referential repository to synchronize with other participants. Synchronization between workspaces is based on the CMM (Copy-Modify-Merge) paradigm and the Long Transaction Model [12]. CMM implies that users must update their private workspaces before publishing their modifications, i.e. they must integrate the modifications published by other participants in the referential repository since the last time they visited it. A Long Transaction means that a user updates, publishes and synchronizes a complete workspace, and not a file or a directory as in the simple CMM popularized by CVS [2]. The advantage of the long transaction model is that it allows a more simple manipulation of workspaces while supporting a higher level of consistency. Its drawback is that for each transfer, it requires computing of all the deltas between all modified files. The choice of the Long Transaction Model to manage workspaces is a good example of a choice that has been made to simplify the user interface on one hand and to facilitate the integration of this cooperation component with others (e.g., group awareness) in the other hand. Initially, we planned to base workspace management on the COO-transaction model [7] which was designed for this purpose. COO-transactions manage transfers at the granularity of a file or a directory (like CVS does), while preserving consistency between files (CVS does not manages integrity constraints between files). However, our experiments have shown that the long transaction model (updating a workspace as a whole and not at the granularity of a file or a directory) is sufficient for a very large number of applications and has many advantages. It is easier for users to understand than CVS or COO-transactions, it maintains the same level of consistency than COO-transactions, and it is simpler to implement. This last consideration is especially important as we have decided to implement our proper version management system from scratch. This gives us the ability to catch the events necessary for supporting awareness and especially state awareness on-the-fly (see Section 2.3.2). 72 GODART ET AL. 2.2.2. Other considerations Access Control. ToxicFarm provides traditional access rights control, allowing only authorized members to read or modify an object. Rights are organized in roles, but currently limited to two roles: administrator and user. Dynamic role creation is being implemented. Notification. When users make new versions of objects available in the repository, specific events are generated. They are used to trigger emails for email lists and update state awareness (see Section 2.3.2). 2.3. Coordination services As team members are distributed across wide geographic areas, the coordination of their activities is a difficult problem that we address in two complementary ways [13]: – task coordination (or explicit coordination): this is based on the hypothesis that it is possible to define a process and enforce this process on working sites, – group awareness (or implicit coordination): this is based on the hypothesis that if the right information about what other people do, is sent at the right time to the right people, this information will trigger communication between people that will result in automatic coordination of the virtual team. 2.3.1. Task coordination. When people work together for a common objective, they generally agree on some well defined tasks that are more or less formalized. This can take different forms. Project Management Tools define tasks and their synchronization (i.e. process modelling). Tasks are defined but not enacted. In this case, the execution of tasks is not controlled by a tool and the link between project management and working sites is weak. To-Do lists. In this case, tasks are dynamically and opportunistically defined by members without any prior planning. Although this can be an efficient way to support cooperation, it is inefficient for project management. Workflow provides both process modelling and enactment [36]. Unfortunately, we have remarked that current workflow technology is not adapted for all aspects of task management, especially for synchronization of the more creative tasks [15]. In ToxicFarm, task coordination is currently based on a combination of To-Do lists and a flexible workflow engine. Our innovative workflow model is based on the following observation. We can easily observe that the “paper description” of a process, whether it is an administrative or production process, or a co-design or co-engineering process, is done in similar ways, using the same basic formalisms such as annotated boxes, circles and arrows. However, it is clear that people looking at such diagrams will interpret them in different ways depending on the context. For example, in an administrative context, we interpret two boxes separated by an arrow as a strict sequencing of two tasks (represented by the two boxes) and it is implicitly assumed that the second task cannot start its execution before the first one terminates. Alternatively, when we consider the same schema in the context of a codesign process, our interpretation is much more flexible. We know that this schema is THE TOXICFARM INTEGRATED COOPERATION FRAMEWORK 73 Figure 4. Anticipation and feedback in a process model. a general indication, but that tasks will probably overlap, interact with each other, iterate and so on. More generally, in case of an administrative or production process, we see tasks as black boxes, executing serially and sharing information only when they start and terminate. In case of creative processes, we see tasks as white boxes, making visible some intermediate results, overlapping with each other and even iterating in their executions. To develop this idea, we have defined the COO-Flow workflow model [17]. While the description (syntax) of a workflow remains a traditional one (like in WfMC), interpretation of control flow and data flow connectors is more flexible for supporting the nature of cooperative interactions. For example, the execution of an activity can be anticipated, i.e. an activity can start its execution even if all its activation conditions are not fulfilled, or are only fulfilled with intermediate results from the preceding activities (thus potentially inconsistent). This is illustrated in figure 4 which shows a process description at the top and two possible executions at the bottom. Execution (1) results from a traditional interpretation of the process. In execution (2), activities “Review” and “Modify” have been anticipated, execute in parallel and interact with each other. In addition, activities can have a transactional behaviour because encapsulation of activities in COO-transactions [7] allows activities to share intermediate results in a consistent way. It can also be noted that in the case where anticipation and exchange of intermediate results are prevented, a cooperative workflow has a traditional behaviour. This model has been implemented in the Bonita1 system and integrated in the ToxicFarm platform in two ways: – a workflow model can be defined and enacted to govern the execution of a whole ToxicFarm project, – a cooperative activity of a cooperative workflow can be implemented as a ToxicFarm project. Each project member is associated a worklist (see figure 5). A worklist consisting of the list of projects associated with the user, a to-do list containing the ready and anticipatable activities the user can activate or anticipate in the current project, and an activity list that lists the active and anticipated (or anticipating) activities of the user. Ready activities are highlighted in yellow colour, anticipatable activities are in green, active are in red and finally, anticipating are in purple. Also, project members can locate and monitor their own actions thanks to the display of the workflow network (see figure 6). 74 GODART ET AL. Figure 5. Three worklists for 3 users. User admin executes activité1, user test anticipates activité2. Activities activité3, activitŕ4 and activité5 are anticipatable by any of the 3 users. Figure 6. Display of a network of activities. The COO-flow model also results from some difficult choices. It represents a good synthesis of needs expressed by users. It does not mean that it is the best model in all cases. An ad-hoc model like in CMI [32] is probably better adapted for critical applications and/or for skilled people ready to develop (complex) models. In addition, we have proposed new operators for modelling cooperative situations [15] but some THE TOXICFARM INTEGRATED COOPERATION FRAMEWORK 75 experiments have shown that people prefer to continue modelling processes the way they are already accustomed to. However, these advanced concepts are not contradictory to our solution and could be implemented in an upper layer of the user interface if necessary. 2.3.2. Group awareness. Awareness services keep users aware of project activities. They are strongly relying on shared data services and task coordination services. Their role is to gather, filter, aggregate events coming from these sources, and deliver them to the destination users. Awareness must be pertinent and must not increase the cognitive overload of destination users. The way awareness is visualized by users is also an important issue. There are different classes of awareness [18]: state awareness which is based on the state of shared data [26], availability awareness which based on the knowledge of the physical presence and current status of a member, process awareness [1] which is based on the knowledge of current activities and their place in a global process and finally divergence awareness which is based on the quantity of conflicts introduced by integrating concurrent operations [4, 27]. Of course, this list is not exhaustive as there are other classes of awareness. ToxicFarm integrates most of the above classes of awareness as discussed next. However, divergence still exists in an embryonic state in the current version. This is discussed in more detail in Molli et al. [26]. State awareness describes the state of shared objects in the following way: to each representative state is associated a colour. For example, a yellow colour associated with a file in a user’s workspace means that the file is locally modified, i.e modified by the user himself in his current workspace; a pink colour means remotely modified, i.e. modified by another user in another workspace; an orange colour means that the file is being modified both locally and remotely indicating a potential conflict. In the user interface, state awareness is dispatched in different ways: – a colored square is associated to file names in directory listings, – a summary of file states is displayed in the header of each workspace’s web page; to each meaningful color is associated the number of files in the corresponding state, – coloured treemaps are used to visualize a very large amount of objects (http://www. bouthier.net). At the same time that state awareness [26] is being displayed, information about conflicting people and the amount of divergence between conflicting objects can be displayed (as example the number of different bytes between the local value and the value in the referential repository). This was partly illustrated back in figure 2. This figure displays the content of the server workspace called SEBOTULE in the project BOTULE. It indicates that the private workspace has: – 28 files that are up-to-date with the repository. – 107 files that need update i.e. they have been modified in the repository since the last checkout of these files, – 42 files that have been added since the last synchronization with the repository of the project – 3 files that will conflict i.e. these files are currently being modified by both the user of SEBOTULE workspace and by another member of the project. 76 GODART ET AL. We can display the states of these objects using treemap by selecting the “Affichage” menu option in the synchronizer agent (see figure 3). We do not include treemap screenshots in this paper because of their lack of legibility but interested readers can check our state treemap library online at: http://woinville.loria.fr or http://www.bouthier.net. Process awareness is supported by the concept of work lists introduced in the previous section and coloured codes for activities. Workflow graph displays (like the one shown in figure 6) also allow users to locate their tasks in the global process. Availability and presence awareness are provided by an instant messaging client (a ICQlike tool supporting the Jabber protocol [22]). As indicated in the two previous sections, the power of awareness depends on the quality of the events that can be caught from the other components. The decision to integrate awareness in our cooperation environment has deeply influenced the design of these components. 2.4. Other services 2.4.1. Project administration service. When a new project is created, at least one administrator for this project has to be registered. This action simply consists of filling appropriate web forms. New users can also register themselves by giving their name and an email address. figure 7 shows the home page of the ToxicFarm environment (http://woinville.loria. fr). Users can log in and see their personal home pages. Project lists can be visualized and related news browsed. A user can also create a new project of which he becomes an Figure 7. ToxicFarm Home Page. THE TOXICFARM INTEGRATED COOPERATION FRAMEWORK 77 administrator. An administrator of a project can add new users in a project, giving them either administrator or user roles. 2.4.2. Communication services. These services reuse traditional tools, either asynchronous, i.e. forums, mailing lists or synchronous, i.e. instant messaging, voice conferencing coupled with a shared whiteboard. They are integrated and coupled with objects states to inform users of principal events on objects. 2.4.3. Security management. In ToxicFarm, security is limited to access control based on roles and encryption in order to guarantee confidentiality of data during network transmission. At the moment, our environment supports the Secure Socket Layer [35] protocol. In addition, we are experimenting with a new architecture that provides the level of privacy required by virtual enterprises (see Section 5.3). 2.4.4. Audit. We focus on the following two aspects of audit services: measuring of project activity and object tracking. Statistics play an important role in measuring the activity rate of a project, its dynamism and its effectiveness; even if it has to be recognized that a universal algorithm to measure the activity of a project has not yet been defined. In ToxicFarm, different kinds of statistics (number of accesses to project home pages, amount of downloaded information, number of commit operations etc.) can be defined and visualized in different forms (e.g. pie charts and plot graphs). Interpreting this data is left to the project’s manager. ToxicFarm also stores the history of object versions so that it is possible to trace and rollback an ongoing project. 2.4.5. Mobility. As stated earlier, mobility is quite an important capability that is too often poorly considered in most systems. Owing to the ToxicFarm’s server-based architecture and its web interface, users can connect to their working environment from any point in the world as long as they have an Internet connection. In addition, thanks to the duplication of a user’s workspace on the server and on his working machine, users can easily disconnect from the server to work at home or on public transport. When they come back to the normal place of work, they only have to synchronize their work with what was done during their absence. In addition, state awareness, news and update logs give precise information about all activities that occurred during their absence. We have experimented the use of personal assistants but currently, this concept is only working for a limited set of functions, typically of awareness nature. 3. ToxicFarm architecture This section gives a brief overview of the ToxicFarm’s architecture (see figure 8) and how it has been implemented in the current version. In short, the ToxicFarm server can be seen as a web service that is a composition of other web services. This architecture provides the ability to easily add a new service or to replace one implementation of a service by another. In relation to existing software architecture patterns [6], the ToxicFarm Microkernel provides services for user management, security, accounting and administration. The Data Sharing 78 Figure 8. GODART ET AL. ToxicFarm architecture. and Coordination services are supported by internal servers. The Data Sharing service provides an API to the State Awareness Service for collecting events. The main kernel and some other services are written in PHP/Mysql [28, 31]. The workflow engine is fully compliant with the J2EE architecture. Each service exports a XML/SOAP API [33]. This protocol is also used for the communication between services and the kernel. The web front end server is an Apache HTTP server with an XSLT [37] processor that applies XSL stylesheets and XSLT transformation rules to aggregation of XML data coming from the ToxicFarm server. The synchronizer which is used to synchronize a private workspace and a corresponding local space is written in Java. This application is deployed on the user’s computer using Java WebStart technology, that provides an automatic and transparent update procedure. As a consequence of this architecture, a user only requires Java WebStart to be installed and the synchronizer to be downloaded on the local machine to be able to start using ToxicFarm! 4. Related work In this section, we compare ToxicFarm with other integrated environments that federate individual tools. Tables 1 and 2 show a summary of comparing ToxicFarm with BSCW, SourceForge and Collaboration Management Infrastructure frameworks. We consider BSCW and SourceForge because they are widely used (SourceForge has around 665,556 registered users and 65,646 hosted projects at the time of writing this paper) and they have largely influenced the development of ToxicFarm. Collaboration Management Infrastructure CMI is also included since it is the initiative that is most comparable to ours in terms of objectives 79 THE TOXICFARM INTEGRATED COOPERATION FRAMEWORK Table 1. Comparative table of different services provided by the frameworks (a). Services Frameworks Features ToxicFarm BSCW SourceForge CMI Data sharing Repository Database Database CVS Database Private WS Private local WS Provided Not provided Not provided Provided Provided Object model Filesystem Filesystem + URL + forum Filesystem Not provided Concurrency CMM + Long Transaction Locking CMM Versioning Linear on files and directory Linear on files only Nonlinear on files and directory Access control ACL ACL ACL Notification API Application Application Visio-conference (can) Call Not provided Not provided Communication Synchronous Instant message External tool Not provided Instant message forums mailing list Forums Forums Task coordination Flexible workflow To-do list Not provided To-do list Workflow + Advanced primitives Group awareness State awareness Not provided To-do list State awareness Availability awareness Not provided To-do list State awareness Asynchronous Coordination and approach. We do not consider here Lotus Domino [24] because, on the one hand, its functionalities are not innovative enough and on the other hand, it is a very closed software, due to its adopted integration strategy. Data sharing. SourceForge uses CVS for workspace management. Although CVS is widely used, it suffers from several bottlenecks. Firstly, workspaces are not hosted on the server. If a user wants to continue working on his workspace on another computer, he has to publish a new version of the data. This new configuration has no meaning for other users. In addition, it is impossible to know anything about the work done by other users before the work is committed on the server. For this reason, it is impossible to predict data conflicts. Such conflicts will only occur much later and they will be difficult to solve by then. In ToxicFarm, each time users resynchronize their workspaces, they ensure durability of their uncommitted changes. They also provide the server with the ability to notify others users of potential conflicts on data. In addition, CVS is not conforming to the long transaction model. This means that users can commit or synchronize only part of 80 GODART ET AL. Table 2. Comparative table of different services provided by the frameworks (b). Services Features Frameworks ToxicFarm BSCW SourceForge CMI Awareness Activity awareness State awareness Log of events Not provided Activity state awareness Presence awareness ICQ Like ICQ Like Not provided Process awareness Colored to-do lists, Activity network display Not provided Not provided Customized role-specific awareness Security Encryption Network encryption ACL ACL Access control ACL ACL ACL access count Not provided Audit Statistical data Access count Not provided Commit count Not provided Commit count Not provided Download count Not provided Download count Not provided the local data. This strategy can lead to situations where users can see inconsistent states. Finally, ToxicFarm can be deployed very easily by nave users whereas solid programming skills are required to install and use CVS and SourceForge. BSCW has no real synchronization tools. Users can copy remote files from the server to local computers, but the consistency of replicates is poorly or not managed at all. Due to its process-centred approach, CMI delegates data sharing management to workflow activities definitions. Thus, it does not provide support for workspaces, version management and data events are difficult to manage too. CMI includes a service definition interface that provides active support for cross-organizational applications, and especially cross-organizational workflows. Coordination. Neither SourceForge nor BSCW provide workflow support. Only SourceForge provides Bug Tracker and To-Do List which weakly support coordination. ToxicFarm integrates a flexible workflow engine that allows the definition and the enactment of processes, and for process awareness. A user has information on who is doing which job, on which data, why, and the next actions after tasks are completed. BSCW mainly provide activity awareness. Users know what is happening and what has happened on shared data. ToxicFarm provides the same level of awareness based on meta-data in the repository. Nevertheless, ToxicFarm provides a much more active awareness level thanks to process awareness and state awareness. CMI is more “process centred” than ToxicFarm. The coordination model is based on standard coordination primitives augmented with advanced primitives. These include primitives for process extensibility that permit the specification of process templates that can be subsequently refined and extended as required by the situation at hand. THE TOXICFARM INTEGRATED COOPERATION FRAMEWORK 81 Awareness. CMI provides an advanced level of awareness that allows focusing, customizing, and temporally constraining the awareness delivered to each process participant [1]. Unlike ToxicFarm which only provides built-in awareness, CMI awareness allows the specification of what information has to be given to what users and at what time using awareness roles and awareness specifications. The awareness service of CMI is potentially more powerful than ToxicFarm’s but needs an important deployment effort, while the ToxicFarm’s awareness capability does not require any deployment effort. In summary, the advantages of ToxicFarm in relation to SourceForge and BSCW are in its more advanced coordination capabilities, and its deployment simplicity. Compared to CMI, ToxicFarm is much simpler to deploy and to use for a large number of applications. ToxicFarm’s drawback is that CMI is more powerful in dealing with ad-hoc complex processes. 5. Emerging e-business application domains As mentioned in the introduction, ToxicFarm has been designed to support creative cooperative applications for professionals with limited computing or programming skills. Beside the original application frame, it is envisaged that ToxicFarm could play an important role in a much wider context, covering the interface between IT infrastructures and e-business cooperation models as illustrated in figure 9. This section reports on some experimentations of ToxicFarm in the areas of e-finance, elearning and e-telecommunications. The first experiment describes our first attempt in dealing with a realistic business application. The second experiment addresses a coauthoring application intended for primary school users. The purpose is, on one hand to introduce the concept of cooperation through the Web in youth culture and on the other hand demonstrate that this concept is at everyone’s reach. The last experiment concerns the management of cross-organizational processes. The interesting feature here that these applications require a high level of privacy for partners that is not available in ToxicFarm. All these experiments Figure 9. The role of cooperation frameworks in e-business applications. 82 GODART ET AL. aim at validating the idea that ToxicFarm services define a comprehensive cooperative kernel. 5.1. e-Finance If support for collaboration is an important requirement in all business applications today, it is also the case in the context of financial services in capital markets (e-finance). In this section, we discuss a particular collaboration case study in the context of financial services in capital markets (e-finance). This is being developed as part of the Capital Markets Cooperative Research Center (see http://www.cmcrc.com), a research initiative in Australia which aims at investigating novel uses of IT in the finance sector. Most exchanges around the world (e.g. New York Stock Exchange, Bourse de Paris, and Australian Stock Exchange) operate during normal working hours. However, trading has become more and more a global activity because of the recent technological developments that have facilitated the instantaneous exchange of information, securities and funds worldwide. Buy/sell decisions have become more complicated because they involve decisions made by different people interacting across wide geographic boundaries and different time zones. A large number of good trading opportunities are lost because traditional communication medium (phone, fax, email) are too inefficient and slow to take advantages of these opportunities. Our case study is concerned with an application that supports a global 24-hour securities trading system. This application has the following features: – A virtual team represents investors and brokers engaged in a common business venture. – A project involves the monitoring of a particular global stock (i.e. a stock listed in several exchanges) or any other global security (e.g. future, option etc.), – All information for a single stock is represented as a shared object. Brokers have the responsibility of updating information automatically when changes (e.g. a price rise or fall) occur, – Investors have the ability to send buy/sell decisions for a particular stock any time to an appropriate broker. Investors can choose to invest locally or globally, according to an investment policy. Investors and Brokers need to quickly react when some important trading opportunities arise. For example, there could be a price differential in a global stock because of an unexpected rise or fall in foreign exchange rates which makes the combined buy/sell of the same stock on different exchanges a lucrative option. Investors and brokers have already heavily invested in existing systems and there will be reluctance to use ToxicFarm as a separate application to support this new business model. For this reason, we are integrating the ToxicFarm Server with the existing applications. Figure 10 shows the structure of the overall system. Each shared object is held in the ToxicFarm server. Requests for changes to these objects are handled through the ToxicFarm Web Service API. This way, we achieve integration of legacy systems while delegating all cooperation aspects to the ToxicFarm Server. THE TOXICFARM INTEGRATED COOPERATION FRAMEWORK Figure 10. 83 A 24-hour trading system. All communication with the ToxicFarm Server is handled through SOAP messages. At present, only shared objects are used to enable information on securities to be concurrently accessed or modified between brokers and investors. In the future, we are planning to “capture” investment policies using ToxicFarm’s To-Do lists. This will enable the use of ToxicFarm’s group awareness facilities to provide automatic notifications to brokers and investors. So far, our experience in designing a collaborative system for this type of e-business applications shows that such a system should be realized in two distinct parts: – A backend server to support the logic and persistence required for collaboration. In our case, the ToxicFarm Server provides a useful and flexible platform for this purpose. – A front-end to provide the application/business- specific support (including user interfaces) for collaboration of human roles. As much as possible, existing legacy applications should be preserved. 5.2. e-Learning This work is being developed in the frame of the COOPERA project (http://www.loria.fr/ equipes/ecoo/coopera/). Its objective is to develop an e-learning environment which uses real cooperation capabilities to support cooperative learning pedagogical objectives, including the learning of cooperative work in the world of Internet. This is not the first project with the same objective, but most of similar experiments are based on simple communication tools, like email, forums and chats for simple activities such as taking turns for web pages creation, federation of web pages, etc. The ambition of the COOPERA project is to support more complex and more cooperative activities between children (from primary school) who cooperate asynchronously through shared workspaces. The first two experiments aim at assessing the feasibility of conducting a cooperative project with primary school children (10–11 years old), using the original ToxicFarm interface. The application consists of cooperatively writing illustrated poetry. Children from al classes and all schools worked in pairs where each pair wrote a small poem, proposed an illustration for a poem written by 84 GODART ET AL. another pair (from another class in another school) and finally made the “pretty printing” of a third poem from a third pair. This first experiment involved 24 pairs in two classes from two schools over a period of 2/3 months. The second experiment is concerned with the cooperative creation of a Web site. It involved 36 pairs of children in three classes from 3 schools over a period of 4/5 months. Most of the work was asynchronous due to the different organizations in the schools. Only one synchronous session was planned after the second third of the experiment. A usage analysis was conducted by psychologists. See Hautecouverture et al. [20] for a detailed description of the usage analysis methodology. Usage analysis resulted in the following considerations. While children get used rather quickly to the interface although it was not adapted for them, they had difficulties to manage their workspaces, i.e. to navigate between them, publish, update and synchronize their data. They misunderstood the concept of multi-space used to support the different levels of privacy. They needed help from software-aware people (teachers, psychologists) to share cooperative data between schools. The encouraging fact is that children have used the environment not only as a co-design tool, but also as a socialization tool. Some children used the environment to establish real (virtual) social interactions, for example by generating on their own initiative awareness information to report on their work progress (mostly to prevent their co-workers becoming impatient!). Teachers were very enthusiastic with the system and recognized that it is well adapted for the stated educational objectives. The reasons are the cooperation model is adapted to real cooperation behaviours and it also works in an asynchronous way. The latter is a strong requirement for supporting cooperation between different schools, as they cannot define a common agenda. School managers also applauded the fact that the system as does not require a complex software deployment scheme, and that is very important for schools without qualified computer staff. In reaction to this experiment, a specialization of ToxicFarm has been developed: the COOPERA Environment that can be tested at http://woinville.loria.fr/coopera. It is now under experimentation through France for several applications at different school levels. The main enhancement carried out was to change the workspace management interface as illustrated in figure 11. All the commands of transfers between different levels of workspaces have been grouped together, in the same Web page, looking closely to the interface in figure 2. Combined with a (small) usage lecture prior to undertaking the exercises, this evolution has allowed children to have a good comprehension of the concept of a multi-space. 5.3. e-Telecommunications This last experiment is concerned with a Virtual Enterprise (VE) application. Contrary to classical organizational structures based on long-standing business partnerships, VE organizational models represent more dynamic and loosely coupled associations with specific business partner organizations and locations. Our application is part of a larger project with France Telecom R&D, the objective of which is to provide a Web commercial service that allows SME enterprises with non-specialised computer staff, to interconnect their processes. Since these processes are distributed across several enterprises, each partner implements a THE TOXICFARM INTEGRATED COOPERATION FRAMEWORK Figure 11. 85 A one page visualization of the different workspace levels. subset of the activities comprising the overall process. However, the same activity can be implemented jointly by several enterprises, i.e. it requires the cooperation between the enterprises concerned to achieve it. We call such an activity a cooperative activity. In particular, synchronization activities of local organization process fragments belong to this category. To deal with such cooperative activities, we are defining a model for cross-organizational processes in which local enterprise processes are interconnected using Synchronization points (SP) [3]. A SP provides, on one hand some cooperation services (object sharing, workflow, awareness. . .), and on the other hand some decision making services in the form of a restricted process implementing the Demming plan-do-check-act cycle (PDCA) [23]. 86 GODART ET AL. Note that a decision can involve changes to VE process in situations such as modifying a deadline, adding an activity or delaying an activity. A prototype that implements the cooperation services required by SPs is being developed using ToxicFarm. In other words, ToxicFarm is used to implement cooperative activities of a workflow. To our knowledge, there are few workflow systems such as CMI that explicitly support cooperative activities. Another problem was that ToxicFarm’s support for privacy is weak when dealing with the additional security and privacy requirements of a VE. To extend the limitations of ToxicFarm, we have introduced the idea a tiers partner that intercepts the transfers between workspaces of participants in two ways [30]. Firstly, some artefacts are not directly stored in the referential repository, but are represented by a proxy that allows to redirect a request towards the owner of the artefact space. Secondly, the access to an artefact, directly or through its proxy, can be filtered to limit the view a partner has on this artefact (filters are defined by contracts). 6. Conclusions and future work This paper has presented the ToxicFarm framework as an open cooperation management platform for virtual teams. It is an open source implementation available online at http://woinville.loria.fr. The framework is intended for non-specialist users as it is entirely Web based and does not rely on any computing or computing experience. This paper has shown how this environment integrates new data engineering results (advanced transactions, flexible workflow, data event based awareness) to enhance the set of cooperation capabilities provided while keep the platform simple and easy to deploy. We are currently enhancing existing functionalities to address the requirements of emerging e-business applications described in Section 5 along the following three research directions: – Context awareness: we are developing a cognitive awareness model taking advantage of the user context for filtering information at both capture and display times, – Synchronization: we are introducing synchronization technology [11] to better support convergence of copies. As a blocking point with this technology is the confidence in transformation tables, we work for secure and proved transformation [21, 25]. – Concurrency: starting from the observation that there are several process models (instead of just one) in a cooperation project, and that these processes are not always well defined, we are developing a technology for mining and controlling concurrency between these processes. Note 1. http://www.freshmeat.net/bonitaworkflow. References 1. D. Baker, D. Georgakopoulos, H. Schuster, and A. Cichocki, “Awareness provisioning in collaboration management,” International Journal of Cooperative Information Systems, vol. 11, nos. 1/2, pp. 145–173, 2002. THE TOXICFARM INTEGRATED COOPERATION FRAMEWORK 87 2. B. Berliner, “CVS II: Parallelizing software development,” in Proceedings of USENIX, Washigton, DC, 1990. 3. J. Bitcheva, O. Perrin, and C. Godart, “Cooperative process coordination,” in The 2003 International Conference on Web Services (ICWS’03), Las Vegas, Nevada, USA, 2003. 4. A. Bouazza, H. Skaf-Molli, and P. Molli, “Coordinating virtual teams by measuring group divergence,” in Workshop on Groupware related Task Design at GROUP’99 Conference, Phoenix, Arizona, USA, 1999. 5. BSCW, “BSCW,” 2003, Online http://bscw.gmd.de. 6. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, Pattern Oriented Software Architecture: A System of Patterns. John Wiley & Son Ltd., 1996. 7. G. Canals, C. Godart, P. Molli, and M. Munier, “A criterion to enforce correctness of indirectly cooperating applications,” Information Sciences, vol. 110, nos. 3/4, pp. 279–302, 1998. 8. R. Conradi and B. Westfechtel, “Version models for software configuration management,” ACM Computing Surveys, vol. 30, no. 2, 1998. 9. P. Dourish, “The parting of the ways: Divergence, data management and collaborative work,” in Proceedings of the Fourth European Conference on Computer-Supported Cooperative Work, CSCW Mechanisms II, 1995, pp. 215–230. 10. P. Dourish, “Using metalevel techniques in a flexible toolkit for cscw applications,” ACM Transactions on Computer Human Interaction, vol. 5, no. 2, pp. 109–155, 1998. 11. C.A. Ellis and S.J. Gibbs, “Concurrency control in groupware systems,” in SIGMOD Conference, 1989, vol. 18, pp. 399–407. 12. P.H. Feiler and G.F. Downey, “Transaction-oriented configuration management: A case study. Technical Report CMU/SEI-90-TR-23 ESD-90/TR-224, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213, 1990. 13. C. Godart, C. Bouthier, P. Canalda, F. Charoy, P. Molli, O. Perrin, H. Saliou, J.-C. Bignon, G. Halin, and O. Malcurat, “Asynchronous coordination of virtual teams in creative applications (co-design or co-engineering): Requirements and design criteria,” in Information Technologies for Virtual Enterprises, 2001. 14. C. Godart, G. Halin, J.-C. Bignon, C. Bouthier, P. Malcurat, and P. Molli, “Implicit or explicit coordination of virtual teams in building design,” in Computer-Aided Architectural Design Research in Asia (CAADRIA’01), Sydney, Australia, 2001. 15. C. Godart, O. Perrin, and H. Skaf, “Coo: A workflow operator to improve cooperation modeling in virtual enterprises,” in 9th IEEE International Workshop on Research Issues in Data Engineering Information Technology for Virtual Enterprises (RIDE-VE’99), 1999. 16. S. Greenberg and M. Roseman, Groupware Toolkits for Synchronous Work. John Wiley and Sons Ltd., 1999. 17. D. Grigori, F. Charoy, and C. Godart, “Flexible data management and execution to support cooperative workflow: The COO approach,” in CODAS, 2001. 18. C. Gutwin, “Workspace Awareness in Real-Time Distributed Groupware.” PhD thesis, University of Calgary, 1997. 19. A. Haake and J. M. Haake, “Take cover: Exploiting version support in cooperative systems,” in Human Factors in Computing Systems. ACM Press: New York, 1993, pp. 406–413. 20. J.C. Hautecouverture, N. Grégory, F. Charoy, M. Patten, and I. Faugeras, “Coopera: Analyse de l’usage d’une plateforme de cooperation á l’usage des enfants,” in 14th Euro-Micro Conference on Human Centered Processes, Luxembourg, 2003. 21. A. Imine, P. Molli, G. Oster, and M. Rusinowitch, “Proving correctness of transformation functions in realtime groupware,” in 8th European Conference on Computer-Supported Cooperative Work, Helsinki, Finlande, 2003. 22. Jabber, “Jabber: An open XML-based presence and instant messaging,” 2003, Online http://www.jabber.org. 23. D.J.L.T. Kaoru Ishikawa, What Is Total Quality Control?: The Japanese Way (Business Management). Prentice Hall Trade, 1985. 24. Lotus, “Lotus notes and domino,” 2003, Online http://www.lotus.com/. 25. P. Molli, G. Oster, H. Skaf-Molli, and A. Imine, “Using the transformational approach to build a safe and generic data synchronizer,” in GROUP 2003 Conference, Sanibel Island, Florida, USA, 2003. 26. P. Molli, H. Skaf-Molli, and C. Bouthier, “State treemap: An awareness widget for multi-synchronous groupware,” in 7th International Workshop on Groupware—CRIWG’2001, Darmstadt, Germany, 2001. 88 GODART ET AL. 27. P. Molli, H. Skaf-Molli, and G. Oster, “Divergence awareness for virtuel team through the web,” in International Conference on Integrating Design and Process Technology (IDPT’02), 2002. 28. MySQL, MySQL, 2003, Online http://www.mysql.com. 29. NetMeeting, Netmeeting, 2003, Online http://www.microsoft.com/netmeeting. 30. O. Perrin, F. Wynen, J. Bitcheva, and C. Godart, “A model to support collaborative work in virtual enterprises,” in Business Process Management (BPM’2003), W.M.P. van der Aalst, A.H.M. ter Hofstede, and M. Weske (Eds.), vol. 2678 of Lecture Notes in Computer Science, Eindhoven, The Netherlands, 2003, pp. 104–119. 31. PHP, PHP, 2003, Online http://www.php.net. 32. H. Schuster, D. Baker, A. Cichocki, D. Georgakopoulos, and M. Rusinkiewicz, “The collaboration management infrastructure,” in 16th International Conference on Data Engineering (ICDE), San Diego: California, USA, 2000, p. 677. 33. SOAP, SOAP: Simple object access protocol, 2003, Online http://www.w3.org/TR/SOAP. 34. SourceForge, SourceForge.net: Breaking down the barriers to open source development, 2003, Online http://www.sourceforge.net. 35. SSL, SSL: Secure sockets layer, 2003. Online http://home.netscape.com/security/techbriefs/ssl.html. 36. WfMC, WfMC: Workflow management coalition, 2003. Online http://wfmc.org. 37. XSLT, XML/XSLT, 2003. Online http://www.w3.org/TR/xslt.