Collaborative Virtual Environment Development an Aspect-Oriented Approach

8/3/2019 Collaborative Virtual Environment Development an Aspect-Oriented Approach

1/6

Collaborative Virtual Environment Development: An Aspect-OrientedApproach *

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

AbstractNow aday s the interest in collab orative environments has

increased considerably, proba bly due t o the current techno-logical advances specially on Internet computing. H owevel;the lack of a standard reference architecture fo r the deve l-opm ent of these systems m akes difJicult the developm ent ofuseful collaborative environments that can be used in realwork . Our goal is the development of a framework fo r theconstruction of collabor ative virtual environments. We con-sider that aspect-oriented programming is very suitable forboth the design and implementation of these systems, thenwe present in this pa per an aspect-oriented approach fo rthe development of collaborative virtual environments.

1. IntroductionCurrent technological advances make possible the useof computers to collaborate and communicate with people

who are geographically dispersed. Organizations want totake advantage of the possibilities offered by new tools liketextual chats, whiteboards, shared editors, and videocon-ferences, that allow distributed team members to work ingroup s, form ing virtual teams.In orde r to make possible the work of virtual team m em-

bers without loss of efficiency and productivity, the systemmust offer a shared environment for the group and the ar-tifacts they use - individual tools, collaborative tools anddocumen ts of different types, where mem bers can com mu-nicate and collaborate with one another. The y need to inter-act with other team m embers using different medias - text,graphics, audio or video, and using different modes of com -munication - asynchronous or synchronous, unicast, broad-cast or multicast, scheduled or informal.

"This research was funded in part by the ClCYT under grant TIC99-1083-CO2-01,and also by the telecommunication organization "FundacidnRetevisidn"

0-7695-1080-9/01$10.00 0 001 IEEE

The needs presented above have motivated great re-search [1 ] [131 [121 in the development of collaborativevirtual environments (CVE) in the last years. T he main ob-jective in the developm ent of these systems is to constructa secure, persistent and integrated shared environment thatprovides to the geographically dispersed users the aware-ness they need to communicate and collaborate as if theywere co-located in a real place. A nother important issue inthese systems are the users preferences. In order to be use-ful, the environment must be conjigurable, extensible, scal-able , adaptable and able to take into account the differentusers preferences and necessities.Object-Oriented (00)application frameworks [4] 5]provide an approach to build applications that are more ro-bust, more correct and with shorter development time thatthose built from scratch. A framework is a reusable designof all or part of a system that is represented by a se t of ab-stract classes and the w ay their instances interact [8]. Theprimary benefits of 00 application frameworks stem fromth e modularity, reusability, extensibility, an d inversion ofcontrol they provide to developers [3]. However, the de-velopment of a frame work and the subsequent instantiationor extension to build custom do main specific applications isnot a straightforward task and many times, the frameworkfails to provide the modularity needed to localize the im-pact of design and implementation changes. Th is decreasesframeworks reusability and extensibility. In addition, veryoften a mino r change in the functionality of the system canmean mayor changes in many components of the frame-work.The main com plexity in the development of a frameworkis the decomposition of the system functionality in com-ponents. Many system s have properties that do not nec-essarily align with the functional components of the sys-tem [ 2 ] . These properties normally are present across dif-ferent components of the system and are called aspects inthe Aspect-Oriented Programming (AOP) [9]. Example s ofaspects are synchronization, security, failure h andlin g,per -sistence, awa reness, authentication, resource m anagemen t,

97


2/6

communication, an d coordination.Ou r goal is to use aspects to achieve separation of con-cerns in the development of CVE. We think that the com-plexity in the development of this kind of systems is in-creased due to the existence of a large number of aspectsthat cut across many components in the system, creatinginterdependences between them that make difficult the ex-tension and modification of these components. By usingAOP, components main functionality and aspects that arepresent in more that o ne com ponent are modeled separatelyresulting in mo re reusable, configurable and extensible sys-tems [ 11, promoting the instantiation of the environmentbased on the users needs and preferences.In this paper we try to identify some of the most char-acteristic aspects that cut across components in CV Es mak -ing the development of these systems mo re difficult. Ou rmain goal is the definition of an Aspect Oriented Frame-work that describes a common language for the develop-ment o f CV E sys tems that can be automatically instanti-ated based on the users needs and preferences. Using anaspect-oriented framework, the developer can focus on thedomain-specific issues and does not need to m anag e directlythe aspects that are present across the system functionality.We model components functionality and aspects as inde-pendent entities inside the framework that are compos ed byusing a composition mechanism that glue com ponents withaspects according t o the user profile of the service customer.2. Aspects in Collaborative Virtual Environ-

mentsFirstly we are goin g to present which are the different as-pects that arise in CV Es. In order to identify these aspects,

we mu st take into account those things that characterize as-pects:i. Aspects are moving targets. This m eans that differ-ent numbers of aspects can affect a variable numbe r

of com ponents over time.ii. Aspects are quality facto rs in different com pone nts in asystem.iii. Aspects are goals an d purposes that the environmentmust achieve.iv. Aspects are processes or functions that cut across dif-

ferent components.v. Aspects are enduring entities that remain stable over thetime.

Likewise any other distributed system, some of the ba-sic issues of these systems like synchronization, commu-nication, coordination, security or failure handling can be

modeled as aspects in CVE. In addition to these aspectswe have detected another ones that are more specific ofthese systems, like awareness, persistence an d authentica-tion. These are the aspects in which we are going to fo-cus in this paper. The se issues are present in some of themost w ell-known CV E, like DIVA 1131, TeamR ooms [ 111and TEAM Scope [141, but are hard-coded throughout com-ponents functionality, drastically decreasing the reusabilityand extensibility of th e environment.Regarding graphical representation we have found a ne waspect that we have called multiples views. In CVE systemsthe graphical representation is a very important issue to takeinto account in order to produ ce a more usable environmentfor human society. On e of our goals is to separate the graph-ical representation of a compone nt from its functionality,in a way that the system would be able to change dynami-cally or statically the graphical representation according t othe users preferences and resources, without changing thecomponents behavior. By this way, the CV E might be ableto offer different degrees of QoS even at runtime.

Now we are going to present which are the reasons thatlead us to consider that awareness, persistence , authentica-tion an d multiples views can be m anaged like aspects in thedevelopment of CVEs. We are going to define each of theseaspects and the way they are m anaged in a CVE.

1. Awareness: The provision of other members aware-ness is very important in a collaborative environment.There are different forms and levels of awareness. Itis very important to select carefully the informationtransmitted, because the system must provide aware-ness, but without invading the privacy of the senderor creating a disturbance for the receiver [7]. S o m eways of awareness are for instance, document updatesawareness. It is mandatory to assure the coherencyof the environment. Whe n a user works in a docu-ment, that user must know w hich are the last modifica-tions performed by other users, and perhaps some ex-tra information like the modification da te or the pagesmodified. However, other forms of awareness regard-ing privacy and accessibility could be configurable byeac h user. For instance, if a user wants to work inisolation without disturbance, he or she could decideno t to receive the awareness information about otherusers connections and disconnections, o r other usersactivities. Othe r exam ples of awareness informationarejo in ing or leaving the environment or what are youdoing for observational purposes. If we use aspectsto represent awareness, the configuration of the infor-mation that a specific user or artifact receives aboutthe rest of the environment is mo re straightforward be-cause is not hard-coded with the users or artifactscompone nts and can b e adde d, deleted or changed dy-namically at runtime.

98


3/6

2. Persistence: Persisten ce is also an important issue in aCVE.The environment itself must be persistent since itmust exist even when n o user is connected to it. O therlevels of persistence are the configuration of the en-vironment for each user or the users actions, for in-stance, modifications in the user profile, or creationand modification of documents. In order to increasethe flexibility of the system, the level of persistencefor each compone nt in the environment should be con-figurable, and again aspects are the most appropriatetechnology t o achieve this flexibility. In addition, theuse of a spects provid es an extra level of configuration.Not only you can configure whether an object is persis-tent or not, but you can a lso configure the persistenc eprocess - automatically or driven by user actions. F orinstance , you cou ld configure the env ironmen t in sucha way that each time you join a chat application thecontent is autom atically saved and can be loaded later,it is saved only if the user selects the appropriate op-tion, or not saved at all. The most im portant benefitof this approach is that all these choices are availableindependently of the chat com ponent behavior.

3 . Authentication: This aspect cuts across all the com-ponents in the virtual environment, because likewisea real work environment, the artifacts that constitutethe virtual environment will have owners and indeedsom e restrictions of access. The re will be objec ts thatare owned by the environm ent, being the system whichestablishe s access permissions. There will be objectsowned by specific users who will be changing accesspermission at runtime.

4. Multiples Views: We want it to be pos sible for users tohave different views of the environmen t dependin g ontheir preferences and resource availability. This can betraduced in different views of each component that canbe changed dynamica lly at runtime. This feature cutsacross all the components in the system with graphi-cal representation, so we are going to consider multi-ple views anothe r aspect in ou r aspect-oriented frame-work.

In order to have a better understanding of these aspectswe present the following example. A typical comp onentin a virtual environment, for instance, a virtual ofice isa meeting room in which participants collaborate sharingdocum ents and other resources. Firstly, when a user of theenvironment wants to access to the room, he m ust authen-ticate himself. This authentication m ay imply a differentrepresentation of the room and the eleme nts contained in itdepending on the user preferences represented in his userprofile. Also, different actions of the user in the room canbe made persistent. This persistence can depend on the en-vironment configuration but also on the users preferences,

One option is to have a default set of persistence require-ments im pose by the environment that can be extended withthe preferences of each user. Another issue that have to betaken into account will be the location of each user and otherresources inside the room.

Studying the characteristics described in the a bove para-graph for the meeting room, we can see that each of themcan be modeled by one of the aspects defined previously.In addition, it is very important to note that the aspects aresometimes no orthogonal and must b e evaluated in a spe-cific order. For instance, if the graphica l represent ation ofthe room (multiple views aspect) depends on the user pro-file, the authentication aspect must be evaluated before themultiple views aspect. In Figure 1 , we can see how to repre-sent graphically the composition between aspects and com-ponents and how to expre ss the evaluation o rder of the as-pects. A square will represent a component and a wrappingcircle will represent an aspec t . If several aspects must beevaluated in a specific order the first one in b eing evaluatedappear in the m ost external circle.

Authentication-oom IMu1 i p l e sViewsFigure 1. Representation of the compositionbetween aspects and components

In this examp le, in first place, the user authen ticates him-self in the environment. If he is accepte d, depending onhi s u ser pro j l e will vary the graphica l representation of themeeting room. It is not possible to evaluate the multipleviews aspects before the authentication aspect and the sys-tem mu st assure this evaluation order.3. Aspect-Oriented Virtual EnvironmentFramework

Aspects are not new properties in complex, large-scalesystems. They are present, to some degree, in most sys-tems. However, with the traditional object-orien ted ap-proach, these propertie s do not have sp ecial relevance in thedesign and implementation phases of the system. T he sys-tem developers know the im portance of, for instance, syn-

99


4/6

chronization, persistence, or failure handler issues but theyjust coded them a s part of the components. This means thatthe main contributio n of AOP is not the aspec ts themselves,but the modeling of these aspects in the framework as sepa-rate entities.

The AOP is a design paradigm that aims the separationof components an d aspects from the early stages of the soft-ware development, and combines them together at the im-plementation phase [101.Th e combination process betweencomponents and aspects has been termed weaving and themain difference betwee n the several proposals that describeaspect-oriented software architectures (AOSA) is centeredin the mechanism of weaving an d at which level aspects andcomponents integrate. Som e proposals use dom ain specificaspect languages to express the aspects, while others use ageneral-purpo se language. In these proposals, the we a v e ris static and com bines the aspects and components togethergenerating an intermingled code that then is compiled andexecuted. The result is highly optimized woven code whoseexecution speed is comp arabl e to that of code written with-out AOSA [2]. However, the incon venience of static weav-ing is that in the result c ode it is difficult to distinguish be-tween the components and aspects code and therefore, itis not possible the dynam ic composition of components andaspects as is achieved in [6 ] and the system is not as ex-tensible as desirable. The alternative to a static weaver isa dynamic one. Dyna mic weaving allows the integrationbetween components and aspects at run-time, making thesystem more adaptable and extensible.

Aspectsomponent

eval(method,args)

~~

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

Figure 2. The Architecture of the aspect-oriented collaborative virtual environmentframeworkOur main goal is the development of an AOP framework

that manages two different components - functionality, thatin advance we will call components an d aspec t s , as two ba-sic entities that will be at the same level and will maintaintheir identity and indepen dence in all the software develop-ment phases. In order to achieve this goal, the objective isto use the sam e general-purpose language for representing

both functionality and aspects, and use dynam ic weaving tointegrate them during execu tion.We think that the most open and extensible solution isone in which the components and the aspects know noth-ing about each other. The aspects should be independentof the components without explicit references to them, andthe components must be designed and implemented with-out having in mind by which aspects are affected. In ourframework, the components and aspects are two basic enti-ties that interact between them but without an explicit pro-cess of weaving. In order to weave components and aspects,maintaining this independence, some glue mechanism willbe necessary to interconnect them. In the next subsectionwe will present this mecha nism an d the general architectureof our framework.3.1. Framework Architecture

In our framework, functionality and aspects are modeledas separate entities, without any knowledge between them.In order to make this possible, during the execution of thesystem it is necessary to have som e mechanism to establishthe interaction betw een these entities. In the framewo rk wepresent here (Figure 2) this interaction is achieved througha middleware layer that will offer a set of comm on servicesto the frameworks components. O ne of these services is theinterconnection between the components and the aspects.The Aspect-Oriented Collaborative Virtual Environment(AO-CVE) middleware layer will have information aboutthe aspects and the components registered in a service andthe relationship between them. This relationship is thecompone nt-aspect oriented architecture that is expressed interms of the following information:

0 Which aspects must be applied to each componentThe order in which the aspects must be applied.If the aspect is component-oriented or m e t h o doriented. An aspect is component-oriented if it is ap-plied to the entire compon ent. An aspect is method-oriented if it is applied to a method of a com ponent butnot necessarily to every component s methods . Th ismea ns that different aspects can be applied to differentmethods of the same component.If the aspect is an entry aspect or an exit aspec t . An erz-t ry aspec t is an aspect that mus t be evaluated before theexecution of a method in a component. An exit aspec tis an aspect that must be evaluated after the executionof the method (Figure 3) .

We want to point out that although this inform ation willbe norma lly established duri ng the design of the service andprovided to the middleware layer statically whe n the service

100


5/6

AuthenticationMeeting

Persistence

Entry aspect Exit aspect

Figure3. Representationof the entry and exitaspects

is instantiat ed the first time, the middlewa re layer will alsooffer the possibility of m odifying it dynamically at runtime.This issue makes the framework very flexible and adaptablebecause you can add, delete or modify the a rchitecture ofthe system by puttin g different versions of the same aspec tat runtime. This dynamic modification of the architectureallow also the change of the service behavior. A valuablebenefit is that you can ac hieve this without any modificationin the functionality of componen ts.

In Figure 2we have presented a very general approach ofour framework. Now, we are going to describe in depth themiddle ware layer. In the case of virtual environments de-velopment, where the configuration of the environment foreach user, based on the users preferences, is an importantissue to take into account, the middleware layer should ex-plicitly mana ge the different users configuration. In order todeal with this issue, as we present in Figure 4, the middle-ware layer should be divided into two levels. The core AO-CVE Middleware Layer will define all the components andaspects that can be used in the environm ent, with their dif-ferent impleme ntations and composition restrictions, whileth e user-specific AO-CVE middleware layer defines onlythose aspects specifically used for the user it represents.4 Conclusions and Future Work

The work presented in this paper is in its early stage. Ourproposal is a first approach about how to apply the aspect-oriented paradigm to the development of CVE s. Our goal isthe development of a generic framework for the construc-tion of CVEs in a configurable, extensible, sca lable an dadaptable way accord ing to the users preferences.

In order to achieve these goals, we have applied AOPas the design paradigm that promotes the separation intwo differe nt entities of compon ents functiona lity and theproperties that appear in more than one component, finallycombining them at runtime. In a dynamic environmentlike the one we are developing here, it is very importantto assure that the communication and computation over-

execute(component.method.args)I

i !

__----_..-_------__-__.__:AO-CVE Middleware LayerUser-Specific AO-CVE Middleware Layer

load, introduced by the dynamic composition of the enti-ties in the system, does not affect the quality of the ser-vices. Our work here is a first approach and i t is diffi-cult to discuss about performance issues yet. However,we have experience in the development of MultiTEL [ 5 ] ,a distributed dynamic framework, implemented in Java, for; registerFunctionality(functiona1ity) the development of multimedia telecom munication services

I 0 a t t a c h A s ~ e c t m n c t ( f u n c t i o n a l i t ~ ~ a s ~ c t ~ - )I

4

: registerAspect (aspect): registerFunctionality(functiona1ity)i execute(component,method,args)

Core AO-CVE Middleware Layer-; registerAspect(aspect): e attachAspectFunct(functionality,aspect....); over the Web. We have implem ented and evaluat ed sev-era1 multim edia services in MultiTE L with excellent results.More information about MultiTEL can be found in the Web

(http://www.lcc.uma.es/lff/MultiTEL/).In this paper we have presen ted some of the asp ects thatare considered in our framew ork and the main guidelinesfor the development of the component-aspect oriented ar-chitecture of our framework. One of the most importantcontribution s of this work is that due to the compo sitionalcharacte ristics of the model, users can develo p partially-instantiated environments based on components and as-pects, which could be dynam ically instantiated at runtime.

Our future goals are to complete the definition of the as-pects present in CVE and the design and implementationof the aspect-oriented framework. A further goal of ourresearch is to address the integration between other third-

. xecute(component.method,args)I

~ -Figure 4. The AO-CVE middleware layer de-composition

When a component in the framework invokes a methodover other component, the source component does not havean explicit reference to the target component. T he executiongoes through the middleware layer invoking the method ex -ecufe(component,method,args). he middleware layer con-tains all the information needed to check which aspectsmust be a pplied before or after the execution of this metho dan d is in charge of ca lling the evaZ(method,args) or each ofthose aspect in the correct order.

101
http://www.lcc.uma.es/lff/MultiTELhttp://www.lcc.uma.es/lff/MultiTEL


6/6

party collaborative solutions and ou r framework, and builda working prototype.References

[ I ] C. A. Constantinides, A. Bader, and T. H. Elrad. An aspect-oriented design framework for concurrent systems. 4t hInternational Workshop on Componen t-Oriented Program-ming WCO P99 in conjunction with the European Con fer-ence on Object-Oriented Programming ECOOP99, June1999.[2 ] C. A. Constantinides, A. Bader, T. H. Elrad, M. Fayad, andP. Netinant. Designing an aspect-oriented framework inan object-oriented environment. ACM Computing Surveys,March 2000. Object-oriented applicationframeworks. Comm unications of the ACM, 40(lo), October1997.[4 ] M. Fayad, D. Schmidt, and R. Johnson. Building applica-tion frameworks: Object-oriented foundations of frameworkdesign. September 1999.

[5 ] L. Fuentes and J. M. Troya. A av a framework for web-basedmultimedia and collaborative applications. IEEE InrernetComputing, 3(2), MarcMApril 1999.[6 ] L. Fuentes and J. M. Troya. Coordinating distributed compo-nents on the web: an integrated development environment.Software-Practice and Experience, 3 1 ,2001.

[3 ] M. Fayad and D. Schmidt.

[7 ] S. E. Hudson and I. Smith. Techniques for addressing funtia-mental privacy and disruption tradeoffs in awareness supportsystems. Proceedings of the ACM, conference on CSCIVI,1996.[8] R. E. Johnson. Frameworks = (components + patterns).Communications of the ACM, 40(10), October 1997.[9 ] C. Lopes, E. Hilsdale, J. Hugunin, M. Kersten, andG. Kiczales. Illustrations of crosscutting. ECOOP 2000Workshop on Asp ects & Dimensions of Concerns, June 1 1-12 2000.[IO] P. Netinant, C. A. Constantinides, T. H. Elrad , and M. Fayitd.Supporting aspectual decomposition in the design of operat-ing systems. 3rd Object-Oriented and Operating Systems(000s)Workshop, 14th ECOOPOO,June, 12-16 2000.[ I I ] M. Roseman and S . Greenberg. Teamrooms: Networkplaces for collaboration. Proceedings ofACM CSCW, 1996.

[121 H. Shinku ro, T. Tomioka, T. Ohsawa, K. Okada, and Y. Mat-sushita. A virtual office environment based on a shared roomrealizing awareness space and transmitting awareness infor-mation. Proceedings of the 10th annual ACM symp osium onuser interface software and technology, 1997.[131 M . Sohlenkamp and G. Ghwelos. Integrating communica-

tion, cooperation and awareness: The diva virtual office em-vironment. Proceedings of ACM CSCW, 1994.[I41 C. Steinfield, C. Y. Jang, and B . Pfaff. Supporting virtualteam collaboration: The teamscope system. IntemationalACM SIGGROUP Conference on Supporting Group Wixk(GROUP99),1999.

102

Collaborative Virtual Environment Development an Aspect-Oriented Approach

Documents

Transcript of Collaborative Virtual Environment Development an Aspect-Oriented Approach