1. Supporting Heterogeneous Users in Collaborative Virtual Environments using AOP CoopIS 2001 September 5-7, 2001. Trento, Italy M. Pinto, M. Amor, L. Fuentes, J.M. Troya Dpto. de Lenguajes y Ciencias de la Computación E.T.S.I Informática, Universidad de Málaga

2. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 20012/20 Objectives and Motivation Main Objective: How to develop user-configurable Collaborative Virtual Environments (CVE) using Aspect-Oriented Programming (AOP) Motivation: The lack of a standard reference architecture Goals in this paper: Main CVE characteristics Why we use AOP? Relevant aspects in CVEs Our proposal: An AO Virtual Environment Framework Conclusions and Present/Future Work

3. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 20013/20 Collaborative Virtual Environments (CVE) CVE Development CVEs Requirements:  Collaboration with people who are geographically dispersed  Integrated Shared Environment  Different medias: text, graphics, audio, video  Different communication modes: asynchronous, synchronous, unicast, multicast, scheduled, casual CVEs Characteristics: Complex application domain  Awareness: Knowledge about users and artifacts location  Persistence: Make the environment, resources and user configuration persistent.  Access Control: Check access permissions to the resources in the environment  Multiples Views: Different graphical representation  Users Preferences: Environment User specific configuration CVEs Goals:  Construct a system highly configurable according to user preferences and resource restrictions.  High degree of reusability, extensibility, adaptability and scalability.  Short development time

4. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 20014/20 Collaborative Virtual Environments (II) CVE Development Software Technology?

5. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 20015/20 Aspect-Oriented Programming (AOP) Aspects complements the advantages of Component-Oriented Application Frameworks:  More robust, correct and with shorter development time applications  Provide high modularity, reusability, extensibility and inversion of control Aspects try to avoid some disadvantages of frameworks:  Sometimes the framework fails to provide the modularity needed to localize the impact of design and implementation changes, decreasing framework reusability and extensibility.  The main complexity in the development of a framework is the decomposition of the system functionality in components because some properties do not necessarily align with the functional components of the system. Aspects promotes:  Separation of concerns  Less interdependences between components and as a consequence easier extension and reusability. Aspect-Oriented Software Technology

6. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 20016/20 Aspect-Oriented Programming (II) Components: Basic functionality in the application domain Aspects: Properties that cut across different components  security  communication  coordination  awareness  authentication EntitiesComponent-Aspect Weaving Static: Components and aspects are mixed in a intermingled code that is compiled and executed  Allow the use of specific aspect languages  Highly optimized woven code  Difficult to distinguish between aspects and components in the result code Dynamic: Components and aspects integration at runtime.  Use of general-purpose languages  System more adaptable and extensible  Dynamic composition overload

7. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 20017/20 Aspect-Oriented Programming (III) Next Steps: Aspects detection in CVEs  Characteristics showed before (awareness, persistence, …) Aspects and Component Composition Our Proposal: An Aspect-Oriented Framework for the development of CVEs where components and aspects are composed dynamically at runtime through a middleware layer, with different configuration based-on a user profile

8. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 20018/20 Aspects in Collaborative Virtual Environments CVEs are distributed systems Synchronization, Communication, Coordination, Security, Failure handling can be modeled as aspects CVEs specific aspects Awareness, Persistence, Authentication, Multiples Views

9. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 20019/20 Aspects in Collaborative Virtual Environments (II) Awareness: User connections and disconnections User state (available, busy, disconnected...) User location Document modifications (who, when and how) Document versions Persistence: Environment persistence Changes in User Preferences Authentication: Checks logins into the environment Rights to open a tool or a document Rights to go into a room Multiples Views: 2D, 3D or Virtual Reality Combination of colors Using aspects these properties are implemented outside components increasing their reusability and extensibility. In addition, using dynamic composition, aspects behavior can change dynamically at runtime and can be configured differently for each user.

10. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 200110/20 Aspects in Collaborative Virtual Environments (III) Example: Authentication Aspect Access Control without AspectsAccess Control using Aspects

11. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 200111/20 Our Proposal: An AO Virtual Environment Framework Middleware Layer eval(user,room,enter,(login,passwd)) Glue mechanism: Dynamic Weaving at runtime (e.g. JAVA/RMI) CVE Framework (Aspects + Components) UserRoom VESite Components do not know the aspects are affected by. Authent M.View eval(user,room,enter,(login,passwd)) invoke(user,room,enter,(login,passwd)) execute(user,room,enter,(login,passwd)) execute(c1,c2,m,args){ if(output_aspects(c1,m) if(input_aspects(c2,m) invoke(c2,m,args); Components and Aspects are first order independent entities Both are implemented using the same general- purpose language (Java) Aspects do not have explicit references to components

12. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 200112/20 The Virtual Environment Site EnvironmentSite Components Aspects Architectural Constraints UserSite Components’ configuration Aspects’ configuration User specific composition Application Context

13. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 200113/20 Components & Aspects Composition Authentication: The user must have permissions to enter in the room Multiples Views: The room will offer different graphical representation depending on the user profile Awareness: The other members in the CVE must know that the user is in the room

14. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 200114/20 Aspect Application Order Authentication may imply a different representation of the room depending on the user preferences  The Authentication aspect must be applied before the Multiples Views aspect. Components & Aspects Composition (II) Entry Aspect Authentication must be evaluated before the execution of enter() to check if this user has access to the room. Exit Aspect Awareness must be evaluated after the execution of enter() to notify that the user is in the room.

15. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 200115/20 Architectural Description: Component Definition NameInterfaceImplementation privateroomindroomintindroomimpl meetingroommeetroomintmeetroomimpl teacherteacherintteacherimpl studentstudentintstudentimpl documentdocintdocimpl videoconftoolvideoconfintvideoconfimpl Service defined with a Service Description Language (LDS) translation

16. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 200116/20 Architectural Description: Aspect Definition NameInterfaceTypesimplementationdefault persistencepersistenceintenv per_level1 per_level2 per_level1 multipleviewsmultipleviewsintuser 2D 3D virtualreality 2D awarenessawarenessinttype aware_level1 aware_level2 awar_level1 authenticationautenticationintcomp owner_auth, accesslist_auth LDAP_auth

17. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 200117/20 The UserSite Component The UserSite contains CVE User preferences Components & Aspects configuration values CVE application context NameImplementations PersistencePer_level1 AwarenessAwar_level2 Multipleviews2D AuthenticationOwner_auth

18. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 200118/20 Architectural Description: Component-Aspect Composition Rules

19. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 200119/20 Conclusions Our proposal is an approach about how we have applied the aspect- oriented paradigm to the development of CVEs. We have seen some aspects specific of these systems: awareness, persistence, authentication and multiples views, and how can be adapted to user preferences. In this work we have focused in the mechanism to dynamically compose components & aspects. This mechanism allows the construction of configurable, extensible and adaptable CVEs. Due to the compositional characteristics of the model, users can develop partially-instantiated environments based on components and aspects, which could be dynamically instantiated at runtime, depending on user preferences.

20. M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 200120/20 Present and Future Work Complete the definition of the CVE Framework Architecture Complete the implementation of the Middleware Layer Definition of the architecture of the CVE framework Definition of component, aspect and services description languages using XML Implementation of a working prototype: a Virtual Office