A Development Framework for Collaborative ... - IEEE Xplore

A Development Framework for Collaborative Applications Based on the Access Grid Yingjie Xia, Yao Zheng, Xuqing Zhu, Chuihao Kong College of Computer Science, and Center for Engineering and Scientific Computation, Zhejiang University, Hangzhou, Zhejiang, 310027, P.R.China {xiayingjie, yao.zheng, zxuqing}@zju.edu.cn Abstract Developing collaborative applications presents a challenge in solving the communication and synchronization problems. In this paper, we introduce a framework created to assist the developers. The framework takes the advantage of the Access Grid (AG) components, Venue Server, Venue Client and Event Channel, aiming to build a collaborative environment. In addition, the framework contains two user interface components, a wizard providing an interface to import new applications, and a main frame listing all the applications developed upon the framework. For a testing task, we implemented some collaborative applications using this framework. And the examples demonstrate that the framework enables the users to develop collaborative applications conveniently and efficiently.

1. Introduction The Access Grid (AG) is an infrastructure and software technology related to distributed active workspaces to support collaborations in science, engineering and education [8]. It assembles various resources including multimedia large-format displays, presentations and interactive environments, which are used to support the group-to-group interaction across the Grid, in contrast to the familiar desktopto-desktop tools [9]. Due to the recent international joint efforts, there have been more than 3,400 certificates issued to about 150 institutions across 47 countries for their remote meetings, distributed educations and other e-science applications [4]. The collaborative applications are a set of programs that allow user groups to work together by sharing information and processes. Each user, called a client, runs a copy of the same application and propagates the local update of the shared state to other collaborating clients. In such a way, the collaborative applications facilitate users to take activ-

ities cooperatively, e.g. IBM Lotus Notes and Domino, which focus on the business-critical collaboration to increase organizational productivity and responsiveness, and Microsoft NetMeeting, a collaborative product for internet conferences with audio, video, text chat and white board. For development of collaborative applications, a solution to the communication and synchronization problems remains as a challenge. Therefore, based on the AG architecture, a framework is proposed to simplify the development process of collaborative applications. In addition, all the applications have to be programmed in the language Python, consisting with the AG. The remainder of this paper is organized as follows: Section 2 introduces the AG, including the architecture and its applications and services. Next, in Section 3, requirements for developing collaborative applications are presented. In Section 4, we describe the design and implementation of the framework using the AG. Finally, conclusions and future works are addressed in Section 5.

2. Access Grid 2.1. Architecture The AG is built upon the Open Grid Service Architecture (OGSA), which identifies all the resources as the services. As shown in Figure 1, the AG architecture consists of the Venue Server and the Venue Client. The Venue Server provides a central infrastructure for performing advanced collaboration: persistent data storage, authorization manager, multicast address allocation, synchronized venue state for coherent distributed experience, etc. The Venue Server also contains some virtual venues to provide virtual spaces among the collaborators. In this way, the clients in the same virtual venue can utilize the shared applications and services [7]. Other than the Venue Server, the Venue Client provides users an interface, with which to operate on the data, ser-

Proceedings of the First International Multi-Symposiums on Computer and Computational Sciences (IMSCCS'06) 0-7695-2581-4/06 $20.00 © 2006 IEEE

Figure 1. Architecture of the AG vices and applications in the virtual venue collaboratively. Moreover, the Venue Client can manage the resources in the AG nodes, including videos, cameras, etc. If there is more than one venue in the Venue Server, the client is also permitted to travel from one venue to another. The AG node consists of a Node Service, one or more Service Managers, and some correlative services, which can be distributed to multiple machines [7]. The Service Managers abstract all the resources into services, according to the OGSA of the AG. An example configuration of the AG node is shown in Figure 2. In this case, the services include Video Producer Service, Video Consumer Service and Audio Service. Each of the three Service Managers controls a separate service, and all of them are manipulated by the Node Service, which is a gateway to the Venue Client.

some limited storage and event channels, for the log of application states and secure communications among clients, respectively. Compared with the shared application, the AG service appears in the Venue Client. It is referenced in the venue, while not interacting with the venue. The service exposes the third-party resources and supplies them to the third-party clients. Whatever the shared applications or the services are, most of them are open source software and are implemented in Python. There exist various shared applications over the AG. For example, the Shared Browser [2], developed in Argonne National Laboratory, allows multiple parties to browse collaboratively the same web sites. One more example is the Shared Desktop application, where a local user can listen to other Shared Desktop users and access the shared desktops via the VNC. It also allows the local user to share his desktop with the other collaborators. Recently, the Shared OpenSceneGraph, a new shared application for 3D visualization, is released. It grants users to view and manipulate 3D objects collaboratively. As AG services, two media tools, Video Conference Tool (VIC) [10] for video and Robust Audio Tool (RAT) [5] for audio, are encapsulated in the node. The VIC is a video conferencing application developed by the Network Research Group at the Lawrence Berkeley National Laboratory, in collaboration with the University of California at Berkeley. The RAT is an open-source audio conferencing and streaming application that allows users to participate in audio conferences over the Internet. Both of them can work between two participants directly, or among a group of participants on a common multicast group. A snapshot of using the VIC and RAT in the AG is shown in Figure 3.

3. Requirements for Developing Collaborative Applications

Figure 2. Architecture of the AG node

2.2. Shared Applications and Services An AG shared application is a piece of software based upon the AG architecture, where more than one person is allowed to view, modify, and add information simultaneously. It is represented in the Venue as an application object with

The collaborative application is a kind of groupware, facilitating user groups to work together. It has two main characteristics, coordinating the activities without the need for participants to move physically, and sharing information among participants, such as documents, 2D audio-visual natural representations, 3D synthetic objects and complex virtual environments [1]. Both of the characteristics are applied to the improvement of current isolated applications. Therefore, collaborative applications expand widely and rapidly. In Figure 4, the anatomy of collaborative applications is illustrated with veteran nodes and a newbie node. The three Veteran nodes identify existing collaborators, while the Newbie node is a new participant in the Collaborative Environment. The Collaborative Environment defines a communication mode, that if one of the nodes updates the state, it will notify the others in the same environment to


Figure 3. Two media tools, the VIC and RAT, act as the AG node services make the corresponding update. In addition, the original updated node stores the new state in the State Repository, which keeps the up-to-date state of the Collaborative Environment. Therefore, whenever a Newbie node joins, the State Repository will assign the current state to it, in order to keep the whole environment consistent. Moreover, the mechanism of ”Queue” and ”Lock” has to be imported, dealing with the cases that more than one node tries to change their state concurrently, or when the repository assigns the state to a Newbie node, a Veteran node coincides to carry an update.

Based on the analysis of collaborative applications above, a framework is proposed to simplify the development of collaboration components in a software package. The framework is necessary to hold the state repository and the participant node structures. And some application programming interfaces (API) must also be supplied to implement the state storage, state assignment and state consistency. In this case, as a proper solution to meet these requirements, the AG architecture performs excellently on constructing the development framework for collaborative applications.

4. Design and Implementation upon the Access Grid

Figure 4. Anatomy of collaborative applications

According to the introduction in Section 2.2, the AG shared application is a piece of software enabling collaborative work. Figure 5 shows an overview of the shared application system. When one application starts up in the client, the Venue creates an application session to produce an Event Channel for sending messages between the clients. The session also starts the Application Service for client registration and storage of the global state information. In Figure 5, the Event Channel and the Application Service enable the Venue to provide a mechanism for discovery, coherence and synchronization among the application clients. And the class, termed SharedAppClient, is a programming interface for the shared applications. It includes methods


for all necessary client operations, which can be invoked to access the Event Channel and the Application Service [6].

Figure 5. Overview of the shared application system

Comparing Figure 5 with Figure 4, it is obvious that they describe similar architectures. The Event Channel is analogous to the Collaborative Environment, and the Application Service takes the place of the State Repository. Thus, recurring to the AG, it is achievable to implement the collaborative applications.

A programming framework is constructed using the AG API, highly assisting to develop the collaborative applications. As shown in Figure 6, the framework layer is inserted between the SharedAppClient interface and the applications in the client. The SharedAppClient object is encapsulated into a dictionary structure, which is defined in the framework and ultimately transferred to each application. Besides, the dictionary instance also contains ID, log, venueURL, and appURL, to meet the requirements of different applications. The ID, generated via the SharedAppClient object, distinguishes the event senders and receivers. And the URL is just for the specific applications, which require the data in the Venue. Eventually the dictionary is referenced by the constructor of each application, facilitating to share the same interface. We make use of a wizard to facilitate the developers to easily implement collaboration functions for the applications. The user customizes the application name, icon, class name and constructor specification. Besides, all the files, including the Python files and other resource files, are specified via the wizard, for the purpose of their registrations in the AG. The application name and its selected icon are shown in the main frame, with the corresponding event response bound to the specific application class. As an input component of the framework, the wizard transforms the user customizations into the code, which is directly added to the source files. Since Python is an interpreted programming language, the modified files are re-interpreted to show an updated main frame containing the appended collaborative application. Snapshots of the wizard are shown in Figure 7, and the main frame of the framework with imported applications is shown in Figure 8. As shown in Figure 8, there are four windows. The left window is the main frame, with a list of icons identifying the collaborative applications developed upon the framework. And the others indicate three running applications, including the Shared WhiteBoard, Shared OSG [3] and Shared Browser. These collaborative applications are modified from the corresponding isolated applications. Therefore, this framework provides a convenient interface to implement the collaboration functions for the applications.

5. Conclusions and Future Works

Figure 6. Modified application client with a development framework for collaborative applications

In this paper, we have proposed a development framework for collaborative applications. The framework makes use of the AG, and promotes to implement the collaboration features. As an input component of the framework, a wizard facilitates the developers to customize some necessary characteristics of their applications, which are translated to the Python code and inserted into the source files. Another component, a main frame, lists all the applications developed upon the framework, to offer a universal access portal


Figure 8. Main frame of the framework with some imported collaborative applications for users. The whole framework obviously provides an efficient approach in developing collaborative applications, as well as a friendly user interface to access them. At present, the framework has been applied to only five

common applications, including editor, browser, visualization software, etc. In the future, we plan to import as many collaborative applications as possible, for widening utilization area.

Acknowledgements The authors wish to thank the National Natural Science Foundation of China for the National Science Fund for Distinguished Young Scholars under grant Number 60225009. We also appreciate helpful discussions among the members of the Grid Computing Group at the Center for Engineering and Scientific Computation (CESC), Zhejiang University, and thank them for their assistance in the project.

References

Figure 7. Snapshots of the wizard

[1] Collaborative applications: Requirements and architecture. February 2000. URL: http://www.nem-tp.org/ publicwebspace/P900-series/P922/p922d2.pdf. [2] AG Shared Browser. URL: http://www.apaccessgrid.org/AG2/sb4linux.html. [3] OpenSceneGraph (OSG). URL: http://www.openscenegraph.org. [4] ANL. Access Grid. URL: http://www.accessgrid.org. [5] ANL. Robust Audio Tool (RAT). URL: http://agcentral.org/help/glossary/rat. [6] ANL/UC. Developer documentation. URL: http://wwwunix.mcs.anl.gov/fl/research/accessgrid/documentation. [7] S. W. Han and J. W. Kim. High-quality video services for the access grid. Proceedings of International Conference on Artificial Reality and Telexistence, November 2004.


[8] R. Stevens, T. Disz, L. Childers, and B. Olson. The access grid? group to group collaboration on the grid. URL: http://www-fp.mcs.anl.gov/ag/events/tutorial-sept00presentations/sept-tutorial-disz.pdf. [9] R. Stevens, M. E. Papka, and T. Disz. Prototyping the workspaces of the future. IEEE Internet Computing, 7:51– 58, July 2003. [10] UCB/LBNL. Video Conferencing Tool (VIC). URL: http://www-nrg.ee.lbl.gov/vic.
