Computer Supported Cooperative Work

Abstract- In the Computer Supported Cooperative Work (CSCW) domain, researchers have always wondered about which principles and models to adopt for the development of collaborative applications capable to really meet the needs of their users. However, these users' requirements are unpredictable and depend on several task or environment-related factors. Integrated collaborative environments are rarely open, extensible and reconfigurable enough so as to meet these requirements. This paper presents an environment, called LEICA (Loosely-coupled Environment for Integrating Collaborative Applications), allowing the integration of existing cooperative applications. LEICA adopts a loosely-coupled integration approach which is based on Web services Services technology, an event notification system, and the definition of Collaboration Policies to control the interactions among integrated applications. LEICA allows different functionalities of existing applications to be dynamically combined and controlled, enhancing therefore the flexibility. Through a case study we show how LEICA was successfully used to integrate three collaborative applications: a co-browsing tool, an instant messaging tool and a VoIP conference controller.

Index Terms-Collaborative work, integrated collaborative environments, web services.

INTRODUCTION

Advances in networking and computing technologies, combined with the fact that companies and work teams are becoming geographically distributed, have created increased a need for communication technologies to ease distance collaboration among distributed individuals (virtual work teams). This leads to the appearing of the so-called Integrated Collaboration Environments (ICEs), having as main goal to integrate different collaborative applications together into a single easy-to-use operational environment [1].

Users' needs are very frequently unpredictable and depending on several emerging factors, including the size of the workgroup, the collaborative activities to be accomplished, the intensiveness of the required communications, the coordination policy and the communication needs of the workgroup. Therefore, the possibility of dynamically integrating new functionalities to the environment appears as an important characteristic for collaborative applications [3]. Supporting the integration of new collaborative functionalities reflects how flexible the environment is while responding to unpredictable users' needs. We can define this characteristic as "integration flexibility" that denotes the ease with which an ICE can be its functionalities in response to the users' needs.

Nowadays one of the main problems of ICEs is that their lack of integration flexibility and as consequence various users decide to set-up their own environments composing different collaborative applications executed independently. In this case, each application is completely "isolated" from others, without any possibility of coordination among them. This lack of integration can lead to a loss of control from the part of the user, since the operation environment is particularly artificial.

Promoting the integration flexibility of ICEs could bring significant benefits to users, allowing different functionalities of existing applications to be dynamically combined and controlled (enhancing therefore the flexibility itself). For instance, a whiteboard application can be integrated with an instant messaging application in such a way that whenever a user joins an instant messaging room, he is automatically logged into the same whiteboard session, instead of been forced to manually login into a session of each one of these collaborative tools. Another case could be the integration of a distributed game and an audio conference application. Whenever a user avatar enters a level/place into the game, his is logged into the audio conference session associated to that level/place, so that the users can online discuss with each other.

In order to achieve the integration of existing collaborative applications without having to deal with their low-level features, this work presents LEICA, a "Loosely-coupled Environment for Integrating Collaborative Applications". Relying on Web services Services (WS) technologies and an event notification system, different collaborative applications can interoperate by exchanging information within the context of a global collaborative session. The loosely-coupled approach proposed by LEICA overcomes a key problem usually related to integration environments - it does not require a true semantic integration of applications. Accordingly, it supports further integration possibilities, such as the integration of third party applications, enhancing, thus, flexibility.

LEICA also offers flexibility in the level of the integration semantics. Based on Collaboration Policies to control the interactions between integrated applications, LEICA provides means to define how the collaboration activity supported by one collaborative application will be affected by information received from other collaborative applications. In practice, these collaborative applications interact through the notification of events which may lead to performing specific action(s) in some of these applications themselves.

As we will explain later in detail, we think that once a collaborative session has been configured, the use of LEICA can improve users' productivity by reducing the application-related administrative tasks, focusing precisely on the collaboration activity itself, and all that by just by interpreting the rules stated for a particular session, all this in function of some pre-established policy rules (also to be explained in detail later). In this way users will find a more natural collaboration environment from the users' point of view.

In order to illustrate the usability of LEICA in real-world conditions, this paper presents a case study that demonstrates the capability of LEICA to integrate collaborative applications. In this case study, LEICA was successfully used to integrate three collaborative applications: a co-browsing tool, instant messaging tool and a VoIP conference controller.

The paper is structured as follows. Section II presents related work regarding the integration of CSCW systems. Section III overviews the general integration approach proposed by LEICA. Section IV explains how to specify Collaboration Policies. Section V presents the LEICA's architecture, detailing how to integrate applications in practice. Some implementation issues are considered in section VI. Section VII describes a case study illustrating the use of LEICA. Finally, in section VIII we draw some conclusions and presents directions of future work.

RELATED WORK

There are several works oriented to improving integration flexibility of collaborative environments. In this context, four main approaches can be identified: user-tailorable solutions; CSCW toolkits; middleware based solutions; and platforms for integration of heterogeneous collaborative systems.

User-Tailorable Solutions

As stated in [2], different definitions of tailorability can be found in the literature. Most of them focus on "user tailorability" ([3], [4], [5] & [6]) defining that a tailorable application can be adapted and modified by its own users in order to meet their different requirements. In CSCW, tailorability must focus on the requirements of the group task and of the organization, in which the CSCW system is used [5]. Actually, tailorability is one of the main concerns of groupware development methods. For example, application of participatory design methods ([7] & [8]) has been proposed in order to approach the user involvement during groupware development, augmenting thus the opportunities for tailoring.

According to [6], tailoring can be supported in three different levels: customization, selecting among a set of predefined configuration options; integration, linking together predefined components within or between applications; extension, improving the implementation by adding new program code. Most of user-tailorable groupware tools support only the customization or integration level (e.g. [2] & [9]). Note that the integration level supposes that the functionality to be integrated has been pre-developed and is available "somewhere" [6]. Only at the extension level users would be able to integrate new functionalities, even if they have not been anticipated by developers at design time.

A method frequently used for supporting tailoring at the extension level is the component-based tailoring. For example, in [10], components are implemented using Flexibeans (an extension of the Java Beans model) and end-users tailor the system using a composition language. In [11], end-users may assemble components into larger composite components using the visual representation rather than writing lines of code. However, even at the extension level the integration flexibility is partial as the integration of existing collaborative systems or groupware would require them to be redesigned according to the system architecture.

CSCW Toolkits

CSCW toolkits ease the implementation of CSCW systems by providing reusable components and behaviors designed to be applicable in a range of circumstances [12]. The need for flexibility and tailorability in CSCW toolkits is well acknowledged.

The Neem Platform [13] offers a generic (application-neutral) evolvable framework upon which socially and culturally aware applications are developed. Flexibility and extensibility in Neem result from its foundation on a core architectural coordination model [13]: decoupled components interact indirectly through message exchanges.

Intermezzo [14] is a collaboration support environment supporting the coordination information sharing, offering fluid interactions, user awareness, session management and policy control. It addresses dynamic flexibility [12] by allowing applications to adapt not just their own behavior, but also the behavior of the toolkit in reacting to the changing dynamics of the world they run into.

The Groupware Toolkit/Shared Dictionary (or GT/SD) toolkit [15][16] has been developed to support rapid development of groupware, focusing mainly on networking and data sharing aspects. GT/SD's extensibility is based on its modular design, which allows adding or modifying behavior by replacing or wrapping different components.

Toolkits may represent an interesting solution for helping the development of CSCW systems, as they promote the reuse of components. But in general, CSCW toolkits offer a limited set of functionalities or they are target for some specific kind of domain. Besides, to reuse components of the toolkit, developers often need to implement very specific details of the toolkit in order to adapt it to the application needs [16][17].

Middleware based solutions

The integration of heterogeneous applications has been a widely investigated subject, mainly in distributed systems area. General integration solutions based on middleware, like CCM (CORBA Component Model), .NET and Enterprise JavaBeans have been developed. Moreover, integration solutions associated with specific domains have also been proposed, such as Enterprise Application Integration systems [17][18]. The emergence of Web services WS has also led to the development of general solutions for integration of distributed applications, due mainly to the use of open standards.

In the CSCW domain, some middleware-based solutions have been proposed. Dustdar et al. [18][19] discuss the importance of using Web services WS in order to provide collaborative application interoperability. But in order to be integrated, collaborative applications must originally support Web servicesWS. Even if Web servicesWS represent an emerging software trend, only a limited set of collaborative applications are currently supporting these technologies.

As an enhancement to traditional middleware, some SOA (Service Oriented Architecture) solutions have also been proposed. For example, WGWSOA [19][20] uses Web ServicesWS as an access interface in order to support the reuse and the interoperability of different collaborative services. But an important drawback of WGWSOA is that collaborative services must be developed following the respective middleware architecture.

It is also important to note that like WGWSOA, most middleware based solutions present technical responses to the so called "syntactic interoperability" [20][21]. They provide mechanisms allowing applications to communicate and interact through information exchange. But according to [21][22], the integration concept goes beyond the possibility of sharing and exchanging specific information. Applications must agree upon the meaning (or the semantics) of these exchanges. In other words, integration solutions should provide means for defining integration semantics. Thus, interoperability can be seen as a requirement for integration.

The EcoSpace Project [22][23] proposes an environment that, besides being based on SOA and Web servicesWS, relies on Semantic Web technologies (WSDL-S with services ontologies) to support semantic description of collaborative services. Besides a semantic description of each service, it would be necessary a semantic description of the composition of services so as to coordinate their orchestration. However, this part of the project remains as design aspect. Moreover, using Web serviceWSs as integration technology may imply some performance loss, particularly associated to the use of SOAP (Simple Object Access Protocol) [23][24].

Luo et al. [24][25] claim that "Web ServicesWS should be only used in situations which are really heterogeneous". They propose a service-oriented solution for the integration of collaborative applications that, instead of using SOAP, adopts a unified service bus (implemented through an open source Enterprise Service Bus).

Platforms for integrating heterogeneous collaborative systems

The latter latest approach to improve the integration flexibility of collaborative environments is to create platforms aiming specifically at the integration of collaborative applications. They focus on the integration of collaborative functionalities provided by these applications while trying to define any semantics behind integration.

Iqbal et al. [25][26] propose an integrative framework based on the three-level model presented by [26][27]: the Ontological Model specifies shared objects, their relations and taxonomies; the Coordination Model specifies how interactions take place during system execution; and the User Interface Model specifies how the system is presented to the final user. Integration process consists firstly in identifying, for each collaborative application, the elements associated with these three models. Then, on each level the elements from different applications are grouped and merged when equivalent. As a result, common ontological, coordination and user interface models are generated. In spite of enabling a multi-level integration, this approach requires an internal knowledge of the collaborative applications so that their functionalities can be mapped into the three-level model. Accordingly, the integration of third party applications becomes a complex task.

In order to avoid considering application internals during the integration process (facilitating the integration of existing applications), some integration solutions propose the so called loosely-coupled approach. This approach presents two main features: (i) once integrated to the environment, collaborative applications preserve their autonomy, i.e., they can still be used as standalone application; (ii) the integration environment remains independent of integrated applications, and accordingly, applications can be integrated and detached from the environment without compromising its behavior. This last feature is particularly important considering the integration flexibility aspect. In fact, in a loosely-coupled environment, the set of integrated applications must be easily modified according to users' needs.

Systems like AREA [27][28] and NESSIE [28][29] have proposed a loosely-coupled integration for supporting cross-application awareness. Both systems represent a collaborative environment where independent applications can share a common information space, implemented through an event notification system. Users can receive notifications of activity relevant events from different applications (executed by other users). An important aspect of these systems is the use of open Internet technologies (such as HTTP and CGI) to enable the integration of third party collaborative applications. However, the main drawback of both systems is that the integration semantics is statically defined - collaborative applications are integrated so as to offer a common awareness of the whole collaboration activity.

Another proposal also based on a loosely-coupled approach is the framework XGSP [29][30]. XGSP proposes the integration of audio and videoconferencing tools based on SIP and H.323 standards, as well as the integration of Access Grid applications [30][31]. In this framework, XGSP manager servers are in charge of controlling collaborative sessions. A different gateway is defined for each application type (i.e. SIP, H.323 and Access Grid applications). Using a signaling protocol based on Web servicesWS, these gateways are employed to mediate the communication between applications and XGSP servers. An important disadvantage of XGSP is the fact that, originally, it only allows the integration of application based on SIP, H.323 and Access Grid.

Loosely-coupling is also inherent to the Web servicesWS based solutions presented in the previous section. Similarly to those solutions, LEICA represents an integration environment that proposes a loosely-coupled approach based on Web servicesWS technologies.

Regarding the performance implications of SOAP, Alonso et al. [31][32] suggest that Web ServicesWS technologies should be used only to implement coarse-gained interactions, where the impact of the overhead associated to SOAP would be less important. Following the recommendations of [31][32], Web servicesWS are employed by LEICA for coarse-grained operations only. As it will be detailed in the following sections, LEICA defines a hybrid architecture where Web ServicesWS are applied as an initial mechanism for registering newly integrated applications, as well as for setting and starting up collaborative sessions. Then, during the execution of integrated collaborative sessions a different infrastructure is used to interconnect collaborative applications. Another important aspect concerns integration semantics. Unlike the previous solutions, LEICA provides users with the possibility to define the desired integration semantics for each collaborative session.

The Integration Environment: LEICA

LEICA aims at the integration of different collaborative applications, where integration semantics is to be defined according to user requirements. Before explaining the general integration approach and the behavior of LEICA, a possible scenario is presented to better illustrate the advantages of such integration.

Integration Scenario

An important domain where collaborative environments have been largely used is e-Learning. In particular, a CVE (Collaborative Virtual Environment) can be used to implement a 3D shared world representing a school building divided into: one entrance hall, classrooms, and teachers' rooms. Different collaborative applications could be associated to each room: (i) a chat room associated to the entrance hall; (ii) a collaborative web browsing (it would enable teachers to guide students through lecture notes) and an audio conference tool associated to the classrooms; and (iii) a shared whiteboard associated to each of the teachers' room.

Un paragraphe pour montrer la situation: Utilisation des outils non integrA©es, et l'intA©gration avec LEICA.

With this integration semantics, whenever an avatar enters into a room, the respective user is automatically connected to the associated collaborative application(s). Besides, only authorized users should enter into private rooms (e.g. the teachers' rooms with its whiteboard could be restricted to teachers). Another possible behavior specified by this integration semantics is some kind of "floor coupling" between the two applications used as a support for virtual class sessions. This way, it would be possible to assure that the user holding the Web browsing floor (i.e. the one guiding the lecture notes browsing) is the only one to have the right to speak to the class attendees.

General Integration Approach

As previously mentioned, and illustrated in Fig. 1, LEICA follows a hybrid architecture where Web ServicesWS are applied at the collaborative sessions start up, and an event notification system allows collaborative applications to interact through the exchange of event notifications. Two other basic components of LEICA are the Wrappers and the Session Configuration Service (SCS).

The integration of a collaborative application to LEICA is achieved by attaching a Wrapper to it. Three main cases may be considered: a) open source applications, b) API-based applications, and c) applications without any available API. Integration of open source applications can achieve the tightest interaction degree, since any internal event/action can be exported/performed; it might however imply great development efforts. API-based integration is straightforward, and interaction is limited to the provided API. Applications without API are the most limitating ones, constraining to interact only through application start and stop actions.

LEICA's integration approach is mainly driven by case (b), believing that developers are certainly interested in creating specific and performable collaboration tools that can be used either stand-alone or integrated with other applications (through a flexible API, being able to get a great share of the market). This is for instance the case of Skype a successful example of communication tool that has released its API since some time ago.

Fig. 2 summarizes LEICA's general integration framework. The first step of the LEICA's integration framework is the Collaborative Application Integration. For instance, in the illustrative scenario presented in III.A, the first step to integrate the CVE with the instant messenger (supporting the chat room associated to the entrance hall), the collaborative Web browser and the audio conference applications, it is necessary to create a Wrapper for each one of these applications. As detailed in Section V, these wrappers can be automatically generated by LEICA's API Factory, based on the API description of each collaborative application. The Wrappers comprise a Web services Services WS interface allowing the collaborative application to register itself with LEICA. As illustrated by Fig. 1, through the Wrapper's Web servicesWS ports, the integrated application can interact with the Session Configuration Service (SCS).

The SCS is a Web service Service WS used for (i) configuring new global SuperSessions and (ii) starting up SuperSessions. A SuperSession is an integrated collaborative session holding the whole collaboration activity. Within the context of a global SuperSession, different specificSessions can exist. A specificSession is a conventional collaborative session defined within the context of a collaborative application (e.g. a videoconference session, a whiteboard session, etc.).

The SCS dynamically contacts each integrated application, during the SuperSession configuration process, in order to request: (i) which specific data is required to create specificSessions for this respective application (e.g. a videoconference tool could require an IP multicast address); and (ii) which kind of events it can notify, and action requests it can handle. The interaction degree among the integrated applications depends essentially on the nature of the events they are able to exchange, and actions they are able to perform.

In order to create a SuperSession, a user must define its integration semantics. It is accomplished by configuring the Collaboration Policy. A Collaboration Policy is a set of rules under a condition/action model. These rules define how collaborative applications must react when receiving information (events) notified by other integrated applications. In other words, the specification of Collaboration Policies allows defining specific integration semantics (i.e. how to coordinate integrated applications) to each SuperSession, according to the different users' requirements.

Once a SuperSessions has been created (and its associated configuration file is generated), it can finally be started up. The SCS firstly contacts each integrated collaborative application requesting them to create the specificSessions defined in the SuperSession. Then, during the execution of collaborative sessions the integrated application can interact through the exchange of event using the Event Notification System. According to predefined Collaboration Policies, these notifications may lead specific actions to be performed.

Wrappers are in charge of managing the SuperSession's Collaboration Policy. When the Wrapper of a collaborative application receives event notifications, it verifies if the notified events enable any policy rule concerning this collaborative application. If so, the Wrapper sends action requests to the respective application. Note that LEICA is not intended to support low-level physical events (e.g. mouse click/scrolling) or high frequency synchronization events (e.g. current position of moving objects). It aims at supporting activity relevant events that carry some semantics.

SuperSession Concept

As previously mentioned, LEICA controls the whole collaboration activity within the context of a global SuperSession. A SuperSession model has been defined in order to precisely identify and describe its components. Based on this model, LEICA maintains concise and coherent SuperSession state information. Furthermore, a well-defined taxonomy of the components and their attributes are also implied from the model.

General models for describing collaborative applications have already been proposed in the literature. Some of them [26][27] & [32][33] represent a conceptual or ontological model describing the entities and relationships of individual CSCW systems. Few models aim at describing integrated CSCW systems, like OOActSM [33][34] and the conceptual model presented in [34][35]. However, these models are based on the notion of a general "activity" as the central abstraction, which was considered rather abstract for a detailed specification of the SuperSession. Nevertheless, these models have inspired several concepts adopted in the defined SuperSession model.

The SuperSession represents a collaboration activity involving different integrated applications, a group of users and general roles associated to these users.

Formally, a CIE Session CS is a tuple:

SS = (SSid, CA , NA , Rl , U , SSat)

where:

• SSid is a unique identifier;
• CA = {CAi } | i AZ [1,I]} is a finite set of collaborative applications where CAi = (CAidi, spSi, CAati) a specific collaborative application running a set of specificSessions (sSi). CAati is a list of attributes characterizing the collaborative application. These attributes provide information about the application description, including name, type, whether it is a role-based application, its distribution architecture (client/server, multi-servers, peer-to-peer) and the type of user applications (stand-alone or webWeb-based).);
• NA is a finite set of non-collaborative applications (data converters, databases, web applications, etc.);
• Rl = {Rlk } | k AZ [1,K]} is a finite set of general roles. The concept of general role refers to a group of users owning the same set of responsibilities and privileges inside LEICA;
• Rlk = (Rlidk , Rlatk). Rlidk is a unique role identifier; and Rlatk is a list of attributes characterizing this general role. This list provides details like role's description, membership and administration rights. Regarding the membership, it defines how the role is associated with users: it may be either (i) a static association (there is a membership list), (ii) an automatic association (there is a predicate function based on users parameters and SuperSession state) or (iii) a user's choice (password protected or not).);
• U = {Ul } | l AZ [1,L]} is a finite set of connected users;
• Ul = (Uidl, URlidl, Mbl, Uatl) represent a user, where Uidl is a unique identifier; URlidl is one general role associated with the user; Mbl is a finite set of membership relations; Uatl is a list of attributes (name, email, IP address, network connection, device type, etc.);

Mbl.n = (mCAidl.n , mSidl.n , msRlidl.n) is a membership relation, where mCAidl.n is an application identifier; mSidl.n is a specificSession identifier; msRlidl.n is a finite set of specific roles identifiers. Thus, each membership relation indicates the participation of a connected user to a specificSession of a collaborative application (once connected to the SuperSession, a user can concurrently take part in none, one or more specificSessions of different collaborative applications);

SSat is a list of attributes characterizing the SuperSession. These attributes describe information like session context (name, purpose, etc.), scheduling (if scheduled or not, duration, etc.), accessibility type (open or closed), role association type (how users are associated to a general role) and maximum number of connected users.

A specificSession regards a conventional collaborative session of a collaborative application. The role of the specificSession entity (spSi.m), wich is formally represented by the tuple:

spSi.m = (Sidi.m, sRli.m, pUidi.m, Rsi.m, spSati.m)

is not to precisely describe each aspect of a collaborative task. Instead, it captures relevant elements like the specific roles defined for this session (sRli.m), the users participating to this session (pUidi.m.) and the shared resources accessed by these users (Rsi.m).

A specific role is a tuple, sRli.m.o = (sRlidi.m.o, sRlati.m.o), where sRlidi.m.o is a specific role identifier and sRlati.m.o is a list of attributes characterizing the specific role (description and maximum number of simultaneous users).

A resource is also a tuple Rsi.m.p= (urli.m.p, Rsati.m.p ), where urli.m.p is a resource locator and Rsati.m.p is a list of attributes characterizing the resource. The purpose of the resource element is simply to allow the implementation of an inter-application access control mechanism. LEICA will not need to keep the state of each resource. Thus, resource's attributes just describe its type (file, device, virtual object, interface widget, etc.) and the read/write access type (exclusive or concurrent).

SuperSession Configuration

In order to create a SuperSession, a two step configuration process is carried out: (i) Session Management configuration and (ii) Collaboration Policy configuration.

In the first configuration step, two groups of information should be specified:

General Session Management information (GSMinfo): It carries management information such as scheduling, membership and general user roles.;

Integrated Applications information (IAinfo): It defines the list of integrated applications to be used during this SuperSession; for each collaborative application, a list of specificSessions is defined, where specific data required by this application for creating sessions is provided (e.g. a videoconference application will be provided with an IP multicast address).

Once Session Management configuration is completed, the Collaboration Policy configuration must be performed. The association of a Collaboration Policy to a SuperSession represents a key concept of LEICA. In fact, a Collaboration Policy is responsible for linking the collaboration activities supported by different specificSessions in the context of a global SuperSession, defining thus a specificspecific integration semantics. The next section introduces the Collaboration Policy concept describing its configuration and formalization.

Collaboration Policies

A Collaboration Policy defines how the collaboration activity supported by one application will be affected by information received from other applications. It is composed by a set of policy rules, where each rule basically associates n event notifications to the execution of m actions (under certain conditions).

Aiming at an intuitive and simple configuration process that, at the same time, provides a more elaborated model than the traditional "event-condition-action", a graphical specification method has been chosen. Using a Collaboration Policy editor (a part of the Web application used during SuperSession configuration), policy rules are created through the composition of GUI components, called policy widgets. Using these widgets it is possible to specify simple rules, associating one event notification to the execution of just one action, or more complex rules combining different event notifications, conditions and actions.

In order to specify rules it is required to know a-priori which type of events each integrated application is able to notify, as well as which type of actions each application should execute. Actually, when an application is integrated to LEICA, it provides specific information concerning its API (a list describing the different events and actions, and their parameters, the application can handle).

Based on the graphic specification of the policy rules, a textual specification is generated which is then attached to the respective SuperSession configuration file. This semantics is implemented by a sub-module of the Wrapper which is in charge of executing the Collaboration Policy during a SuperSession.

Collaboration Policies Configuration

Fig. 3 illustrates the policy widgets used to create policy rules. These widgets can be connected through their connection points or coupled through their coupling interface. The basic composition rules are:

• policy rules are read from left to right;
• only widgets without any connection point or coupling interface on their left can appear on the left end of a policy rule;
• only widgets without any connection point on their right can appear on the right end of a policy rule;
• every rule must be composed by, at least, one Event or Trigger widget, and one Action widget.

The rules defined in the Collaboration Policy of a SuperSession are concurrently executed (a rule in execution is called an active rule). Whenever the widgets of a policy rule are enabled, the respective rule is enabled and, then, fired.

The Event widget represents an event notification, while the Action widget represents an action execution request. Events and Actions are of specific types (field "type") and are associated with a collaborative application (field "from" and "to", respectively). In the Event's "Parameters" part it is possible to define matching patterns (filters) for parameters' values. Whereas, in the Action "Parameters" part, the values for all the required parameters must be specified.

A Predicate widget allows the association of conditions to enable policy rules. A Predicate must be coupled to any policy widget but an Action. It contains a predicate that is specified in the Java language syntax. Predicates can impose time constraints, as well as conditions based on the current SuperSession state (state elements are referenced using a syntax based on the SuperSession model. When a Predicate is coupled to an Event (or to a Latest) it can also reference the parameters of the respective Event (or the parameters of the Events grouped by the Latest). The Predicate is enabled whenever its coupled widget is enabled and the specified condition is true. Optionally, Predicates can define an alternative behavior (the connection point in Fig. 3) when connected to Action widgets.

Fig. 4 shows a simple Collaboration Policy rule where, according to a Predicate, one of the two Actions must be executed when the specified Event is notified (the '%' character in this figure is a reference operator). It represents an example of policy rule that might be specified in order to implement the following behavior described on the integration scenario of section VI: whenever a Teacher avatar enters into the teachers' room, the respective user is automatically connected to a specific Whiteboard session; otherwise, the user's avatar is moved back to the main entrance hall. Note that Events are always numbered in order to avoid references ambiguities. For example, the Action's parameter "u" has its value copied from the parameter "user" of Event "1".

A Trigger is another widget defining conditions for enabling rules. But, contrary to the Predicate, it must not be coupled to any other widget. This widget must continually be evaluated and, whenever the specified condition becomes true, the widget is enabled. Besides, unlike the Predicate, Triggers can only impose conditions regarding the SuperSession state.

The Earliest and Latest widgets allow the composition of different Events and Triggers for the specification of a policy rule. When widgets are grouped through an Earliest, the policy rule is enabled when one of the specified widget is enabled (i.e. when an Event is notified or when a condition imposed by a Trigger becomes true). When widgets are grouped through a Latest, the policy rule is enabled after all widgets have been enabled.

Regarding again the previously described e-Learning scenario, suppose that a virtual class must be stopped whenever (i) the theacher's avatar exits the virtual classroom and (ii) there are less than 5 students attending the course. Fig. 5 presents an example of policy rule (using a Latest to group an Event and a Trigger specifying situations (i) and (ii)) that might be specified in order to implement this behavior. Note the parameter tw (waiting time) associated to the Latest. This parameter defines the maximum accepted delay between the enabling of grouped widgets (i.e., the maximum time interval between event notifications and/or the triggering of conditions).

An upcoming problem is related to the fact of having different Events grouped through an Earliest. As the Earliest defines a non-deterministic behavior (there is no way of knowing a priori which among the Events will enable the policy rule) parameters from Events grouped through an Earliest can not be referenced by a Predicate coupled to this Earliest neither by the Actions of the rule.

LEICA's Architecture

To precisely describe LEICA's architecture elements, the three activities composing the general integration framework (illustrated in Fig. 2) are now detailed.

Collaborative Application Integration

Collaborative applications may present different distribution architectures, varying from client/server or multi-server, to peer-to-peer (P2P). When integrating client/server or multi-servers applications, a Server Wrapper must be attached to the servers. In the case of a P2P collaborative application, a P2P Wrapper is used. As shown in Fig. 6, the difference between these two Wrappers deals with the WS Interface (Web services S ervices WS Interface), not present in the second case. Actually, P2P applications are usually dynamically executed in the users' hosts when they get connected. Thus, they cannot be permanently available as Web services S ervices WS. To overcome this problem, a P2P Proxy is used. As it will be detailed, this proxy plays the role of Web services Services WS representing integrated P2P applications.

To decrease development effort when integrating applications, a special module called API Factory is defined. This module works as a Wrapper factory: based on XML specifications of the application's API, it generates a Wrapper adapted to it. Actually, two description files must be created: (i) Specific Data File, describing which are the required data for creating specificSessions (regarding the example of a videoconference tool, in this file it would be specified that it requires an IP multicast address for creating a videoconference), and (ii) Attributes and API File, describing the event types the collaborative application is able to exchange, and the actions it is able to perform through its API.

Wrapper adaptation concerns the creation of an Application Interface sub-module defining all the necessary methods (corresponding to the events/actions API) for communicating with the application. This sub-module is used for attaching Wrappers to applications (the server(s) or the peers). Through this interface the collaborative application keeps the Wrapper aware of "what is happening" inside its collaboration context (i.e. make event notifications) and receives all specificSessions set up and action requests.

The main component of the Wrapper is the Session Manager, which implements its core functionalities. It is in charge of (i) receiving and handling specificSession configuration data; (ii) managing Collaboration Policies as it receives event notifications; and (iii) sending event notifications to other collaborative applications.

Once the Wrapper is attached to the collaborative application, it can register itself within LEICA. It publishes thus its services in a Private UDDI Registry. In multi-server applications, a Master Server is designated to register the application. In P2P applications, registering is made through the P2P Proxy.

SuperSession Creation

• For accessing the SCS (which manages SuperSessions creation) a Web portal is used; initially, the user must enter general management information (GSMInfo);
• Meanwhile, the SCS requests the UDDI Registry about integrated collaborative applications; in response, it receives the URL pointing to the Web servicesWS interface of each Server Wrapper (in the case of P2P applications, it receives a URL pointing to the P2P Proxy);
• The SCS contacts integrated applications in order to get information about specific configuration data (needed for configuring specificSessions) and the type of events and actions it can handle. ;
• Based on this information, the IAinfo and the Collaboration Policy can be defined.

SuperSession Execution

The numbered steps in Fig. 7 schematize the start up of a SuperSession:

1. The same Web portal is used to start the execution of a SuperSession.;
2. The SuperSession configuration file is retrieved and parsed; the collaborative applications to be used in this SuperSession are identified;
3. The SCS contacts the concerned Server Wrappers to set up specificSessions and to send them the Collaboration Policy of this SuperSession;
4. The Server Wrappers are interconnected through the Event Notification System; from this point, Web ServicesWS are not used anymore.

The Event Notification System is based on the publish/subscribe paradigm [35][36]. Publish/subscribe interaction scheme is well-adapted to loosely-coupled environments. In general, subscribers register their interest in patterns of events and then asynchronously receive events matching these patterns, regardless of the publishers.

Each Wrapper analyses the Collaboration Policies in order to discover: which type of events it is able to publish, and which type of events it needs to subscribe to. A Wrapper just needs to publish events that could enable policy rules, and subscribe to events that could enable a policy rule defining actions to its associated application.

1. The LClient contacts the Session Configuration Service and it receives the GSMinfo, IAinfo and the Collaboration Policy defined to the chosen SuperSession;
2. The LClient is in charge of locally launching client and P2P applications; to do so, it executes the Collaboration Policy in order to know when client/P2P applications must be launched, thus, it must also connects to the Event Notification System;
3. Suppose that, initially, this user is to be connected just to two specificSessions, concerning a client/server and a P2P collaborative application; then, the LClient runs the respective applications;
4. The P2P Wrapper receives from the LClient all SuperSession configuration information. It connects to the Event Notification System and executes the Collaboration Policy.

Implementing and Deploying LEICA

In order to get a concise and correct implementation of LEICA, we have specified a design model of the environment. To design LEICA's architecture entities, the UML-based modeling tool TAU G2 [36][37] has been used.

During the design process, a top-down development approach was adopted. Architectural elements have been decomposed and dynamic behaviors have been defined for each sub-component. Simulations using the UML case tool have been carried out in order to validate the correctness of our model.

Technologies

Based on the UML model, LEICA's first prototype was developed. Java has been chosen as underlying technology (Java Native Interface might be used for integrating non Java applications). Special Java APIs have been used in order to implement the Web ServicesWS interactions:

• Apache jUDDI for implementing the UDDI Registry;
• the Wrapper's WS Interface and the P2P Proxy use (i) UDDI4J (from IBM) to interact with the UDDI Registry and (ii) Apache Jakarta Tomcat 5.0 and Apache SOAP

to interact with the SCS;

LClient also uses Apache SOAP 2.3.1 to contact the SCS.

To implement the Event Notification System based on the publish/subscribe approach; the Scribe [37][38] infrastructure has been used. Scribe implements a large-scale, peer-to-peer publish/subscribe approach with efficient application level multicast.

Case Study

This section demonstrates how LEICA can be used to create an Integrated Collaboration Environments (ICEs) from three collaborative applications. The goal of this ICE is to offer these collaborative applications together into a single easy-to-use co-browsing environment.

Co-Browsing Environment

Collaborative Web Browsing (or co-browsing) allows many users, each one using its own computer, to browse together the Web in a synchrous way. Several fields can take advantage of this new browsing paradigm, such as e-learning, collaborative search, browsing on support materials during video-conferences, etc. In [38][39], we proposed CoLab, a co-browsing tool based on a synchronization model that allows establishing/releasing browsing synchronization relations among the members of a co-browsing session.

In order to represent the organization of the existing workgroups in a CoLab session, we use a data structure called SDT (Synchronization Dependency Tree). A typical SDT is shown in Fig. 9. A SDT is a tree where nodes represent the users connected to a single collaborative session, and arcs represent the synchronization relations eventually existing among them. An arc oriented from a node A to a node B (B is the son of A), characterizes the fact that the browsing activities of user B are currently synchronized to those of user A.

In order to create a more useful co-browsing environment it is necessary to complement CoLab with real-time communication support allowing users to discuss about the co-browsed contents. Thus, the proposed co-browsing environment integrates CoLab with two communication tools: (i) an audio conference system composed by our Conference Controller (CC) [40][41] and the Asterisk IP PBX [41][42]; and (ii) Babylon Chat [39][40], an open source multi-room chat.

Integrating CoLab with Babylon Chat and CC implies the need of managing both tools together in order to guarantee a coherent behavior. In this case it would mean that whenever two users are collaboratively browsing, both of them should be assigned the same messaging room and conference. This integration was accomplished using the LEICA, which allows some functionalities of these three tools to be dynamically combined and controlled together.

Overview of the Co-browsing Environment

• Session Configuration Service (SCS): is used to create and initiate the so called CoLabCCBabylon SuperSession.
• Colab Proxy Server and its Wrapper: The Colab Proxy Server acts as a mediator between the website (where the requested Web pages are hosted) and the collaborating users in order to manage co-browsing sessions. Besides allowing CoLab to register itself with LEICA, the CoLab's Wrapper is also in charge of managing the SuperSession's Collaboration Policy regarding this application.
• Babylon Server and its Wrappers: The Babylon server manage instant messaging sessions. Its Wrapper registers this application with LEICA and manages the SuperSession's collaboration policy.
• LEICA Client (LClient): it initially connects to the SCS and receives configuration information for a given SuperSession (chosen by the user.. LClient launches the CoLab client (a web browser containing the initial page of the co-browsing session) and the Babylon chat client (a new Web browser window containing a Web page with the java applets implementing the Babylon chat client). The LClient does not need to run the SIP user agent (this last is supposed to be already running as a background application or as a service). Note that this behavior is completely configurable and based on the Collaboration Policy.
• Event Notification System: Based on this system, CoLab, Babylon Server and Conference Controller notify events during the CoLabCCBabylon SuperSession. Meanwhile, the rules of the Collaboration Policy are continually analyzed in order to verify if any action must be executed in response to notified events.

Creating the LEICA Wrappers

The first integration step is to generate the LEICA wrappers to each collaborative application. As presented in section V, these wrappers are automatically generated by LEICA's API Factory, based on the API description of each collaborative application.

Both CoLab and CC offer APIs that define the ways by which client programs may request functions and be notified of event generated by the other collaborative applications. To generate the Wrappers, the following XML files were created: Specific Data File describing which are the required data for creating specificSessions; and the Attributes and API File, describing the event types each collaborative application is able to exchange, and the actions it is able to perform through their APIs. After the creation of these XML files, the LEICA's API Factory was used to automatically generate the Wrappers adapted to CoLab and CC APIs. Afterwards, these Wrappers were properly attached to CoLab's Proxy server and CC using their APIs.

Originally, the Babylon Chat Server doesn't provide an API. In order to integrate this collaborative application with LEICA it was necessary change the Babylon chat server to create an API for this collaborative application. Next, we applied the same process described previously to generate the Babylon wrapper.

Definition of the Integration Semantics

With the integration of CoLab, CC and Babylon to LEICA, a SuperSession using these applications was created. This SuperSession was called CoLabCCBabylon, and its configuration file was created following the process described in section III.DIII.C. Among other relevant information, in this file we find the Collaboration Policy specifying the desired integration semantic. In this integration scenario, there are some integration semantics that can be defined. Fig. 11 presents two possible Collaboration Policies defining two different integration scenarios. The policy illustrated by Fig. 11-a) (composed by a simple rule) defines the simplest scenario where all session members must join the same single (audio/video) conference and the same chat room. In order to define this behavior, the illustrated rule specifies that, whenever a user is connected to the SuperSession, this user will be connected to a CoLab session, to a chat room and to a Conference Controller session.

The Collaboration Policy illustrated by Fig. 11-b) defines a more complex integration scenario. In this scenario, all session members must join the same chat room, but members of dynamic workgroups are connected to different (audio/video) conferences. As in the context of a CoLab session different workgroups might be formed during collaborative work, each workgroup will be associated to a different (audio/video) conference. Accordingly, as synchronization relations are dynamically created and released into a CoLab session, leading to different workgroup configurations, the respective conferences must be created/eliminated by the Conference Controller in consequence. The rules composing this Collaboration Policy, particularly rules 2 and 3, specify this behavior, associating special action requests (e.g. asking the Conference Controller to move users from one conference to another) to event notifications representing users' synchronizations or desynchronizations into CoLab.

Moreover, the Collaboration Policy could include floor control information, associating privileges to different user roles. For instance, a Collaboration Policy could define that only asynchronous users of CoLab (root nodes of the SDTs) can talk-and-listen in a conference while the others can listen-only.

Functionality Testing

In order to verify whether LEICA meets the intended functional requirements, we simulated some collaborative activities in the previously presented ICE. In each test we changed the number of integrated collaborative applications and the Collaboration Policy: an ICE composed by CoLab and Babylon Chat; an ICE composed by Colab and Conference Controller; and an ICE composed by CoLab, Babylon Chat and Conference Controller. We used the both Collaboration Polices presented in Fig. 11 in the latest scenario. LEICA, through the SuperSession configuration, offers a quick and flexible manner to establish these various scenarios. Our prototype worked appropriately in all the simulations of collaborative sessions carried out.

In all scenario tests that we have conducted the actions performed by the integrated application was consistent with the integration semantics specified . For instance, Fig. 12 presents one of the scenario tests that we have conducted. In this scenario, six users (represented by letters A thru F) participate in a SuperSession including individual sessions of the previously mentioned tools. In this SuperSession, we adopted the collaboration policy presented in Fig. 11-b. Therefore, when a user connects to CoLab, he starts his browsing activity in an independent way (i.e. being asynchronous) and enters in a chat session where all connected users are gathered.

Fig. 12-a) illustrates a moment of the collaborative activity when users A, B and C are in the same workgroup (i.e. the same SDT), users D and E form a second workgroup, while user F is asynchronous. At this point, the Conference Controller has created properly two conferences: one connecting users A, B and C; and the other connecting users D and E. At a given moment, user D decides to get synchronized with user F. Thus, this last becomes the root of the SDT initially formed by users D and E. The Conference Controller receives then an event notification from CoLab informing this fact and, in response, the Controller invites user F to the conference connecting users D and E (this is guaranteed by rule 2 illustrated in Fig. 12-b).

Performance tests

An important performance parameter to be evaluated in solutions proving integration of collaborative environments is the event notifications latency, i.e. the delay between the occurrence of an event and the notification of this event to other application (e.g., the delay between user D decides to get synchronized with user F on CoLab and the notification of this event in the Conference Controller).

Using Wireshark network protocol analyzer 0[43], we captured the network packets during the tests simulations in each host. This analyzer records the send/receive time of each network packet. Using this data, we measured the delay between the transmission of the TCP packet transporting the event notification and the reception of the Invite SIP packet (SIP call). The average delay measured during the simulation tests was 25ms. This delay is imperceptible by humans, which demonstrates the good performance of our ICE. The components that influence in this delay are the processing in the CoLab proxy server, in the Conference Controller and Asterisk server, and the network delays during the various packets transmissions. The network delay can be neglected, because the simulations were carried out in a local network. In wide area networks the notification delay will be increased, but this is beyond the scope of LEICA's performance evaluation.

Conclusions and Future Work

After our dissertation about LEICA, we can conclude that existing collaborative applications can be integrated using Web ServicesWS as integration technology. In the context of a SuperSession, a global collaborative activity is supported where different integrated applications are used in a parallel and coordinated way. Besides providing flexibility in terms of integrated applications (due to its loosely-coupled approach), integration semantics is not imposed by the environment itself. Actually, LEICA provides users with the possibility to define this semantics according to their needs. Thus, each SuperSession is associated to a Collaboration Policy defining how integrated applications are coordinated.

In order to validate LEICA's integration approach, a prototype was developed where three collaborative applications were integrated. The prototype implementation confirmed the advantages of such a loosely-coupled integration, where integration processes were straightforward. Additionally, collaborative applications preserved their autonomy after integration. However a drawback of this approach is that client applications must be previously deployed on each user host (except Web applications, such as CoLab).

Regarding Web servicesWS, its suitability for implementing loosely-coupled interactions was confirmed. Besides, an important effort has been employed to propose solutions for optimizing the transmission and/or wire format of SOAP messages. In this perspective, the current Event Notification System of the LEICA could also become a Web servicesWS-based system without the performance problem currently inherent to SOAP.

Concerning the actual prototype, new collaborative applications are to be integrated, such as Asterisk (IP PBX) and Skype.

Concerning Collaboration Policies, since policy rule's semantics is defined using Petri nets, a verification based on this formalism could be conducted. Accordingly, conflicts and incoherencies due to incorrect specification could eventually be identified.

References

1. G. Fox, W. Wu, A. Uyar, H. Bulut and S. Pallickara, "Global Multimedia Collaboration System", in Proc. Int. Symposium on Collaborative Technologies and Systems, 2005, pp. 11-13.
2. N. Cheaib, S. Otmane and M. Mallem, "Integrating Internet Technologies in Designing a Tailorable Groupware Architecture", in Proc. Int. Conf. on Computer Supported Cooperative Work in Design, 2008, pp. 141-147.
3. H. Kahler, A. MA¸rch, O. Stiemerling, and V. Wulf, "Introduction to the Special Issue on Tailorable Systems and Cooperative Work", Computer Supported Cooperative Work: The Journal of Collaborative Computing, v.9, n.1. pp.1-4, 2000.
4. V. Pipek and H. Kahler, "Supporting Collaborative Tailoring". In End-User Development, Springer, 2006, pp. 315-345.
5. M. Koch and G. Teege, "Support for tailoring CSCW systems: Adaptation by composition", in Proc. 7th Euromicro Workshop on Parallel and Distributed Processing, 1999, pp. 146-152.
6. A. MA¸rch, "Three Levels of End-User Tailoring: Customization, Integration, and Extension". In Computers and Design in Context, Cambridge, MA: The MIT Press, 1997, pp. 51-76.
7. G. Fischer et al. "Seeding, evolutionary growth and reseeding: the incremental development of collaborative design environments", Coordination Theory and Collaboration Technology, Lawrence Erlbaum Associates, 2001, pp. 447-472.
8. T. SchA¼mmer and R. Slagter, "The Oregon Software Development Process", in Proc. XP2004, 2004, pp 148-156.
9. M. Bourimi, S. Lukosch, and F. KA¼hnel, "Leveraging visual tailoring and synchronous awareness in web-based collaborative systems", in Groupware: Design, Implementation, and Use, Springer, 2007, pp. 40-55.
10. O. Stiemerling and A.B. Cremers, "The Evolve project: Component-based tailorability for CSCW applications". AI and Society, vol. 14, pp. 120-141, 2000.
11. J. Hummes and B. Merialdo, "Design of Extensible Component-Based Groupware". Computer Supported Cooperative Work, vol. 9, pp. 53-74, 2000.
12. P. Dourish and W. Keith Edwards, "A Tale of Two Toolkits: Relating Infrastructure and Use in Flexible CSCW Toolkits". Computer Supported Cooperative Work, vol. 9, pp. 33-51, 2000.
13. P. Barthelmess and C.A. Ellis, "The Neem Platform: an Extensible Framework for the development of Perceptual Collaborative Applications", in Proc. Int. Conf. on Eng. and Deployment of Cooperative Information Systems, 2002, pp. 547-562.
14. K. Edwards, "Policy and Roles in Collaborative Applications", in Proc. ACM Conference on Computer-Supported Cooperative Work, 1996.
15. B. Alwis, C. Gutwin and S. Greenberg, "Combining Power and Simplicity in a Groupware Toolkit", Report 2009-923- 02, Department of Computer Science, University of Calgary, Canada, 2009.
16. M.C. Pichiliani and C.M. Hirata "A Guide to Map Application Components To Support Multi-User Real-Time Collaboration", in Proc. Int. Conf. on Collaborative Computing: Networking, Applications and Worksharing, 2006, pp. 1-5.
17. G. Alonso, F. Casati, H. Kuno and V. Machiraju, "Enterprise Application Integration", In Web Services - Concepts, Architectures and Applications, Springer pp.67-92, 2004.
18. S. Dustdar, H. Gall and R. Schmidt, "Web services for Groupware in Distributed and Mobile Collaboration", in Proc. 12th Euromicro Conference on Parallel, Distributed and Network-Based Processing, 2004, pp.241-247.
19. R.S.P. Maciel and J.M.N. David, "WGWSOA: A Service-Oriented Middleware Architecture to support Groupware Interoperability", in Proc. 11th Int. Conf. on Computer Supported Cooperative Work in Design, 2007, pp.556-561.
20. G. Lewis and L. Wrage, "Approaches to Constructive Interoperability", Technical Report CMU/SEI-2004-TR-020 Software Engineering Institute, Carnegie Mellon University, Pittsburgh (USA), 2004.
21. L.L. Brownsword et al., "Current Perspectives on Interoperability" Technical Report CMU/SEI-2004-TR-009 Software Engineering Institute, Carnegie Mellon University, Pittsburgh (USA), 2004.
22. M.A. Martinez-Carreras, A. Ruiz-Martinez, A.F. Gomez-Skarmeta and W. Prinz, "Designing a Generic Collaborative Working Environment", in Proc. IEEE Int. Conf. on Web Services, 2007, pp.1080-1087.
23. K. Chiu, M. Govindaraju and R. Bramley, "Investigating the limits of SOAP performance for scientific computing", in Proc. 11th IEEE Int. Symp. on High Performance Distributed Computing, 2002, pp.246-254.
24. L. Tiejian et al., "A Services Oriented Framework for Integrated and Customizable Collaborative Environment", in Proc. IEEE Int. Conf. on Information Reuse and Integration, 2007, pp.385-393.
25. R. Iqbal, A. James and R. Gatward, "A practical solution to the integration of collaborative applications in academic environment", in Proc. 5th Int. Workshop on Collaborative Editing Systems, 2003.
26. C.A. Ellis and J. Wainer, "A Conceptual Model of Groupware", in Proc. ACM Conf. on Computer Supported Cooperative Work, 1994, pp.79-88.
27. L. Fuchs, "AREA: a cross-application notification service for groupware", in Proc. 6th European Conf. on Computer Supported Cooperative Work, 1999, pp.61-80.
28. W. Prinz, "NESSIE: an awareness environment for cooperative settings", in Proc. 6th European Conference on Computer Supported Cooperative Work, 1999, pp.391-410.
29. G. Fox, W. Wu, A. Uyar, H. Bulut and S. Pallickara, "A Web services framework for collaboration and videoconferencing" in Proc. Workshop on Advanced Collaborative Environments, 2003.
30. https://www.accessgrid.org/, 2009.
31. G. Alonso, F. Casati, H. Kuno and V. Machiraju, "Web Services", in Web Services - Concepts, Architectures and Applications, Springer-Verlag pp.123-149, 2004.
32. H.P. Dommel, J.J. Garcia-Luna-Aceves, "Networking Foundations for Collaborative Computing at Internet Scope", in Proc. ICSC Int. Congress on Intelligent Systems and Applications, Symposium on Interactive and Collaborative Computing, 2000.
33. G. Teege, " Object-Oriented Activity Support: A Model for Integrated CSCW Systems", Computer Supported Cooperative Work: The Journal of Collaborative Computing, vol. 5, pp. 93-124, 1996.
34. C.R.G. Farias, L.F. Pires, and M. van Sinderen, "A conceptual model for the development of CSCW systems", in Proc. Int. Conf. on the Design of Cooperative System, 2000, pp. 189-204.
35. P. Eugster, P. Felber, R. Guerraoui, and A.M. Kermarrec, "The many faces of publish/subscribe", ACM Computing Surveys, vol. 35, 2003, pp. 114-131.
36. https://www.telelogic.com/, 2009.
37. M. Castro, P. Druschel, A.M. Kermarrec and A. Rowstron, "Scribe: A large-scale and decentralized application-level multicast infrastructure" IEEE J. Sel. Areas in Commun, vol. 20, pp. 1489-1499, 2002.
38. G.J. Hoyos-Rivera, R.L. Gomes, J.P. Courtiat and R. Willrich, "CoLab: A New Paradigm and Tool for Browsing Collaboratively the Web". IEEE Trans. Syst., Man, Cybern. B, vol.36, pp. 1074-1085, 2006.
39. https://visopsys.org/andy/babylon/index.html, 2009.
40. C.V. Lima, R. Willrich, G.J. Hoyos-Rivera, R.L. Gomes, J.P. Courtiat, "An Extensible Co-browsing Environment with Conference Support", in Proc. 16th IEEE Int. Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, 2007, pp. 204-205.
41. Asterisk: An Open Source PBX and telephony toolkit, https://www.asterisk.org, 2009.

Cite this page