Collaborative Virtual Environment Development: An Aspect-Oriented Approach *

M. Pinto, M. Amor, L. Fuentes, J.M. Troya Dpto. de Lenguajes y Ciencias de la Computacidn, Universidad de Malaga Campus de Teatinos, s/n. cp. 29071 Malaga (SPAIN) email:(pinto,pinilla,lBtroya)@lcc.uma.es

Abstract
Nowadays the interest in collaborative environments has increased considerably, probably due to the current technological advances specially on Internet computing. Howevel; the lack of a standard reference architecture f o r the development of these systems makes difJicult the development of useful collaborative environments that can be used in real work. Our goal is the development of a framework f o r the construction of collaborative virtual environments. We consider that aspect-oriented programming is very suitable f o r both the design and implementation of these systems, then we present in this paper an aspect-oriented approach f o r the development of collaborative virtual environments.

1. Introduction
Current technological advances make possible the use of computers to collaborate and communicate with people who are geographically dispersed. Organizations want to take advantage of the possibilities offered by new tools like textual chats, whiteboards, shared editors, and videoconferences, that allow distributed team members to work in groups, forming virtual teams. In order to make possible the work of virtual team members without loss of efficiency and productivity, the system must offer a shared environment for the group and the artifacts they use - individual tools, collaborative tools and documents of different types, where members can communicate and collaborate with one another. They need to interact with other team members using different medias - text, graphics, audio or video, and using different modes of communication - asynchronous or synchronous, unicast, broadcast or multicast, scheduled or informal.
"This research w s funded in part by the ClCYT under grant TIC99a 1083-CO2-01,and also by the telecommunication organization "Fundacidn
Retevisidn"

The needs presented above have motivated great research [ 1I] [ 131 [ 121 in the development of collaborative virtual environments (CVE) in the last years. The main objective in the development of these systems is to construct a secure, persistent and integrated shared environment that provides to the geographically dispersed users the awareness they need to communicate and collaborate as if they were co-located in a real place. Another important issue in these systems are the users preferences. In order to be useful, the environment must be conjigurable, extensible, scalable, adaptable and able to take into account the different users preferences and necessities. Object-Oriented (00)application frameworks [4] [5] provide an approach to build applications that are more robust, more correct and with shorter development time that those built from scratch. A framework is a reusable design of all or part of a system that is represented by a set of abstract classes and the way their instances interact [8]. The primary benefits of 00 application frameworks stem from the modularity, reusability, extensibility, and inversion of control they provide to developers [3]. However, the development of a framework and the subsequent instantiation or extension to build custom domain specific applications is not a straightforward task and many times, the framework fails to provide the modularity needed to localize the impact of design and implementation changes. This decreases frameworks reusability and extensibility. In addition, very often a minor change in the functionality of the system can mean mayor changes in many components of the framework. The main complexity in the development of a framework is the decomposition of the system functionality in components. Many systems have properties that do not necessarily align with the functional components of the system [ 2 ] . These properties normally are present across different components of the system and are called aspects in the Aspect-Oriented Programming (AOP) [9]. Examples of aspects are synchronization, security, failure handling, persistence, awareness, authentication, resource management,

97
0-7695-1080-9/01$10.00 0 2001 IEEE

communication, and coordination. Our goal is to use aspects to achieve separation of concerns in the development of CVE. We think that the complexity in the development of this kind of systems is increased due to the existence of a large number of aspects that cut across many components in the system, creating interdependences between them that make difficult the extension and modification of these components. By using AOP, components main functionality and aspects that are present in more that one component are modeled separately resulting in more reusable, configurable and extensible systems [ 11, promoting the instantiation of the environment based on the users needs and preferences. In this paper we try to identify some of the most characteristic aspects that cut across components in CVEs making the development of these systems more difficult. Our main goal is the definition of an Aspect Oriented Framework that describes a common language for the development of CVE systems that can be automatically instantiated based on the users needs and preferences. Using an aspect-oriented framework, the developer can focus on the domain-specific issues and does not need to manage directly the aspects that are present across the system functionality. We model components functionality and aspects as independent entities inside the framework that are composed by using a composition mechanism that glue components with aspects according to the user profile of the service customer.

modeled as aspects in CVE. In addition to these aspects we have detected another ones that are more specific of these systems, like awareness, persistence and authentication. These are the aspects in which we are going to focus in this paper. These issues are present in some of the most well-known CVE, like DIVA 1131, TeamRooms [ 111 and TEAMScope [ 141, but are hard-coded throughout components functionality, drastically decreasing the reusability and extensibility of the environment. Regarding graphical representation we have found a new aspect that we have called multiples views. In CVE systems the graphical representation is a very important issue to take into account in order to produce a more usable environment for human society. One of our goals is to separate the graphical representation of a component from its functionality, in a way that the system would be able to change dynamically or statically the graphical representation according to the users preferences and resources, without changing the components behavior. By this way, the CVE might be able to offer different degrees of QoS even at runtime. Now we are going to present which are the reasons that lead us to consider that awareness, persistence, authentication and multiples views can be managed like aspects in the development of CVEs. We are going to define each of these aspects and the way they are managed in a CVE. 1. Awareness: The provision of other members awareness is very important in a collaborative environment. There are different forms and levels of awareness. It is very important to select carefully the information transmitted, because the system must provide awareness, but without invading the privacy of the sender or creating a disturbance for the receiver [7]. Some ways of awareness are for instance, document updates awareness. It is mandatory to assure the coherency of the environment. When a user works in a document, that user must know which are the last modifications performed by other users, and perhaps some extra information like the modification date or the pages modified. However, other forms of awareness regarding privacy and accessibility could be configurable by each user. For instance, if a user wants to work in isolation without disturbance, he or she could decide not to receive the awareness information about other users connections and disconnections, or other users activities. Other examples of awareness information arejoining or leaving the environment or what are you doing for observational purposes. If we use aspects to represent awareness, the configuration of the information that a specific user or artifact receives about the rest of the environment is more straightforward because is not hard-coded with the users or artifacts components and can be added, deleted or changed dynamically at runtime.

2. Aspects in Collaborative Virtual Environments

Firstly we are going to present which are the different aspects that arise in CVEs. In order to identify these aspects, we must take into account those things that characterize aspects: i. Aspects are moving targets. This means that different numbers of aspects can affect a variable number of components over time. ii. Aspects are quality factors in different components in a system. iii. Aspects are goals and purposes that the environment must achieve. iv. Aspects are processes or functions that cut across different components. v. Aspects are enduring entities that remain stable over the time. Likewise any other distributed system, some of the basic issues of these systems like synchronization, communication, coordination, security or failure handling can be

98

2. Persistence: Persistence is also an important issue in a CVE. The environment itself must be persistent since it must exist even when no user is connected to it. Other levels of persistence are the configuration of the environment for each user or the users actions, for instance, modifications in the user profile, or creation and modification of documents. In order to increase the flexibility of the system, the level of persistence for each component in the environment should be configurable, and again aspects are the most appropriate technology to achieve this flexibility. In addition, the use of aspects provides an extra level of configuration. Not only you can configure whether an object is persistent or not, but you can also configure the persistence process - automatically or driven by user actions. For instance, you could configure the environment in such a way that each time you join a chat application the content is automatically saved and can be loaded later, it is saved only if the user selects the appropriate option, or not saved at all. The most important benefit of this approach is that all these choices are available independently of the chat component behavior.

One option is to have a default set of persistence requirements impose by the environment that can be extended with the preferences of each user. Another issue that have to be taken into account will be the location of each user and other resources inside the room. Studying the characteristics described in the above paragraph for the meeting room, we can see that each of them can be modeled by one of the aspects defined previously. In addition, it is very important to note that the aspects are sometimes no orthogonal and must be evaluated in a specific order. For instance, if the graphical representation of the room (multiple views aspect) depends on the user profile, the authentication aspect must be evaluated before the multiple views aspect. In Figure 1 , we can see how to represent graphically the composition between aspects and components and how to express the evaluation order of the aspects. A square will represent a component and a wrapping circle will represent an aspect. If several aspects must be evaluated in a specific order the first one in being evaluated appear in the most external circle.
Authentication

3. Authentication: This aspect cuts across all the components in the virtual environment, because likewise a real work environment, the artifacts that constitute the virtual environment will have owners and indeed some restrictions of access. There will be objects that are owned by the environment, being the system which establishes access permissions. There will be objects owned by specific users who will be changing access permission at runtime.
4. Multiples Views: We want it to be possible for users to have different views of the environment depending on their preferences and resource availability. This can be traduced in different views of each component that can be changed dynamically at runtime. This feature cuts across all the components in the system with graphical representation, so we are going to consider multiple views another aspect in our aspect-oriented framework.
In order to have a better understanding of these aspects we present the following example. A typical component in a virtual environment, for instance, a virtual ofice is a meeting room in which participants collaborate sharing documents and other resources. Firstly, when a user of the environment wants to access to the room, he must authenticate himself. This authentication may imply a different representation of the room and the elements contained in it depending on the user preferences represented in his user profile. Also, different actions of the user in the room can be made persistent. This persistence can depend on the environment configuration but also on the users preferences,

Room

Mu1 t i p l e s Views

Figure 1. Representation of the composition between aspects and components

In this example, in first place, the user authenticates himself in the environment. If he is accepted, depending on his user projle will vary the graphical representation of the meeting room. It is not possible to evaluate the multiple views aspects before the authentication aspect and the system must assure this evaluation order.

3.

Aspect-Oriented Virtual

Environment

Framework
Aspects are not new properties in complex, large-scale systems. They are present, to some degree, in most systems. However, with the traditional object-oriented approach, these properties do not have special relevance in the design and implementation phases of the system. The system developers know the importance of, for instance, syn-

99

chronization, persistence, or failure handler issues but they just coded them as part of the components. This means that the main contribution of AOP is not the aspects themselves, but the modeling of these aspects in the framework as separate entities. The AOP is a design paradigm that aims the separation of components and aspects from the early stages of the software development, and combines them together at the implementation phase [ 101. The combination process between components and aspects has been termed weaving and the main difference between the several proposals that describe aspect-oriented software architectures (AOSA) is centered in the mechanism of weaving and at which level aspects and components integrate. Some proposals use domain specific aspect languages to express the aspects, while others use a general-purpose language. In these proposals, the weaver is static and combines the aspects and components together generating an intermingled code that then is compiled and executed. The result is highly optimized woven code whose execution speed is comparable to that of code written without AOSA [2]. However, the inconvenience of static weaving is that in the result code it is difficult to distinguish between the components and aspects code and therefore, it is not possible the dynamic composition of components and aspects as is achieved in [6] and the system is not as extensible as desirable. The alternative to a static weaver is a dynamic one. Dynamic weaving allows the integration between components and aspects at run-time, making the system more adaptable and extensible.

both functionality and aspects, and use dynamic weaving to integrate them during execution. We think that the most open and extensible solution is one in which the components and the aspects know nothing about each other. The aspects should be independent of the components without explicit references to them, and the components must be designed and implemented without having in mind by which aspects are affected. In our framework, the components and aspects are two basic entities that interact between them but without an explicit process of weaving. In order to weave components and aspects, maintaining this independence, some glue mechanism will be necessary to interconnect them. In the next subsection we will present this mechanism and the general architecture of our framework.

3.1. Framework Architecture

In our framework, functionality and aspects are modeled as separate entities, without any knowledge between them. In order to make this possible, during the execution of the system it is necessary to have some mechanism to establish the interaction between these entities. In the framework we present here (Figure 2) this interaction is achieved through a middleware layer that will offer a set of common services to the frameworks components. One of these services is the interconnection between the components and the aspects. The Aspect-Oriented Collaborative Virtual Environment (AO-CVE) middleware layer will have information about the aspects and the components registered in a service and the relationship between them. This relationship is the component-aspect oriented architecture that is expressed in terms of the following information:
0

Component

Aspects

eval(method,args)

Which aspects must be applied to each component The order in which the aspects must be applied.

~~

registerAspect(aspect)

s actachAspectFunct(functionality,aspect, ...) 0 execute(component,method,args)

registerFunctionality(functiona1ity)

Figure 2. The Architecture of the aspectoriented collaborative virtual environment

framework
Our main goal is the development of an AOP framework that manages two different components - functionality, that in advance we will call components and aspects, as two basic entities that will be at the same level and will maintain their identity and independence in all the software development phases. In order to achieve this goal, the objective is to use the same general-purpose language for representing

If the aspect is component-oriented or method oriented. An aspect is component-oriented if it is applied to the entire component. An aspect is methodoriented if it is applied to a method of a component but not necessarily to every components methods. This means that different aspects can be applied to different methods of the same component. If the aspect is an entry aspect or an exit aspect. An erztry aspect is an aspect that must be evaluated before the execution of a method in a component. An exit aspect is an aspect that must be evaluated after the execution of the method (Figure 3). We want to point out that although this information will be normally established during the design of the service and provided to the middleware layer statically when the service

100

Authentication Meeting

Persistence

Entry aspect

Exit aspect

Figure 3. Representationof the entry and exit aspects

In Figure 2 we have presented a very general approach of our framework. Now, we are going to describe in depth the middleware layer. In the case of virtual environments development, where the configuration of the environment for each user, based on the users preferences, is an important issue to take into account, the middleware layer should explicitly manage the different users configuration. In order to deal with this issue, as we present in Figure 4, the middleware layer should be divided into two levels. The core AOCVE Middleware Layer will define all the components and aspects that can be used in the environment, with their different implementations and composition restrictions, while the user-specific AO-CVE middleware layer defines only those aspects specifically used for the user it represents.

is instantiated the first time, the middleware layer will also offer the possibility of modifying it dynamically at runtime. This issue makes the framework very flexible and adaptable because you can add, delete or modify the architecture of the system by putting different versions of the same aspect at runtime. This dynamic modification of the architecture allow also the change of the service behavior. A valuable benefit is that you can achieve this without any modification in the functionality of components.

Conclusions and Future Work

The work presented in this paper is in its early stage. Our proposal is a first approach about how to apply the aspectoriented paradigm to the development of CVEs. Our goal is the development of a generic framework for the construction of CVEs in a configurable, extensible, scalable and adaptable way according to the users preferences. In order to achieve these goals, we have applied AOP as the design paradigm that promotes the separation in two different entities of components functionality and the execute(component.method.args) properties that appear in more than one component, finally __----_..-_------__-__.__ combining them at runtime. In a dynamic environment I :AO-CVE Middleware Layer like the one we are developing here, it is very important User-Specific AO-CVE Middleware Layer to assure that the communication and computation over: registerAspect (aspect) load, introduced by the dynamic composition of the enti: registerFunctionality(functiona1ity) I 0 attachAs~ectmnct(functionalit~~as~ct~-) ties in the system, does not affect the quality of the serexecute(component,method,args) i vices. Our work here is a first approach and it is diffiI 4 cult to discuss about performance issues yet. However, Core AO-CVE Middleware Layer we have experience in the development of MultiTEL [ 5 ] , a distributed dynamic framework, implemented in Java, for ; registerAspect(aspect) ; registerFunctionality(functiona1ity) the development of multimedia telecommunication services : e attachAspectFunct(functionality,aspect....) execute(component.method,args) ; over the Web. We have implemented and evaluated sevI era1 multimedia services in MultiTEL with excellent results. More information about MultiTEL can be found in the Web (http://www.lcc.uma.es/lff/MultiTEL/). Figure 4. The AO-CVE middleware layer deIn this paper we have presented some of the aspects that composition are considered in our framework and the main guidelines for the development of the component-aspect oriented architecture of our framework. One of the most important When a component in the framework invokes a method contributions of this work is that due to the compositional over other component, the source component does not have characteristics of the model, users can develop partiallyan explicit reference to the target component. The execution instantiated environments based on components and asgoes through the middleware layer invoking the method expects, which could be dynamically instantiated at runtime. ecufe(component,method,args). middleware layer conThe tains all the information needed to check which aspects Our future goals are to complete the definition of the asmust be applied before or after the execution of this method pects present in CVE and the design and implementation and is in charge of calling the evaZ(method,args)for each of of the aspect-oriented framework. A further goal of our research is to address the integration between other thirdthose aspect in the correct order.
i !

i-

101

party collaborative solutions and our framework, and build a working prototype.

[7] S. E. Hudson and I. Smith. Techniques for addressing funtia-

mental privacy and disruption tradeoffs in awareness support systems. Proceedings of the ACM, conference on CSCIVI,
1996. [8] R. E. Johnson. Frameworks = (components + patterns). Communications o the ACM, 40(10), October 1997. f [9] C. Lopes, E. Hilsdale, J. Hugunin, M. Kersten, and G. Kiczales. Illustrations of crosscutting. ECOOP 2000 Workshop on Aspects & Dimensions of Concerns, June 1 112 2000. [IO] P. Netinant, C. A. Constantinides, T. H. Elrad, and M. Fayitd.

References
[I] C. A. Constantinides, A. Bader, and T. H. Elrad. An aspectoriented design framework for concurrent systems. 4th International Workshop on Component-Oriented Programming WCOP99 in conjunction with the European Conference on Object-Oriented Programming ECOOP99, June 1999. [2] C. A. Constantinides, A. Bader, T. H. Elrad, M. Fayad, and P. Netinant. Designing an aspect-oriented framework in an object-oriented environment. ACM Computing Surveys, March 2000. [3] M. Fayad and D. Schmidt. Object-oriented application frameworks. Communications of the ACM, 40( lo), October 1997. [4] M. Fayad, D. Schmidt, and R. Johnson. Building application frameworks: Object-oriented foundations of framework design. September 1999. [5] L. Fuentes and J. M. Troya. A java framework for web-based multimedia and collaborative applications. IEEE Inrernet Computing, 3(2), MarcMApril 1999. [6] L. Fuentes and J. M. Troya. Coordinating distributed components on the web: an integrated development environment. Software-Practice and Experience, 3 1,2001.

[I I]
[ 121

[ 131

[I41

Supporting aspectual decomposition in the design of operating systems. 3rd Object-Oriented and Operating Systems (000s)Workshop, 14th ECOOPOO,June, 12-16 2000. M. Roseman and S. Greenberg. Teamrooms: Network places for collaboration. Proceedings ofACM CSCW, 1996. H. Shinkuro, T. Tomioka, T. Ohsawa, K. Okada, and Y. Matsushita. A virtual office environment based on a shared room realizing awareness space and transmitting awareness information. Proceedings o the 10th annual ACMsymposium on f user interface software and technology, 1997. M. Sohlenkamp and G. Ghwelos. Integrating communication, cooperation and awareness: The diva virtual office emvironment. Proceedings of ACM CSCW, 1994. C. Steinfield, C. Y. Jang, and B. Pfaff. Supporting virtual team collaboration: The teamscope system. Intemational ACM SIGGROUP Conference on Supporting Group Wixk (GROUP99),1999.

102