Supporting Heterogeneous Users in Collaborative Virtual Environments using AOP CoopIS 2001 September...

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. TroyaDpto. de Lenguajes y Ciencias de la Computación

E.T.S.I Informática, Universidad de Málaga

M. Pinto, M. Amor, L. Fuentes, J.M. Troya CoopIS 2001 2/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 architectureGoals in this paper:

Main CVE characteristicsWhy we use AOP?Relevant aspects in CVEsOur proposal: An AO Virtual Environment FrameworkConclusions and Present/Future Work


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


Collaborative Virtual Environments (II)

CVE Development

Software Technology?


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


Aspect-Oriented Programming (II)

Components: Basic functionality in the application domain

Aspects: Properties that cut across different components

security

communication

coordination

awareness

authentication

Entities Component-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


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


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 Persistence Authentication Awareness Multiples Views

User

Room

Document

Tool


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.


Aspects in Collaborative Virtual Environments (III)

Example: Authentication Aspect

open()

enter()

login()

initiate()

open() if access(user,doc) //access possible else //access not possible

enter() if access(user,room) //access possible else //access not possible login() if access(user,env) //access possible else //access not possible

initiate() if access(user,mtool) //access possible else //access not possible

open()

enter()

login()

initiate()

if access(user,target_comp){ invoke(target_comp,method ) else //access not possible }

authentication aspect

Access Control without Aspects

Access Control using Aspects


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)

User Room

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


The Virtual Environment Site

EnvironmentSiteComponentsAspectsArchitectural Constraints

UserSiteComponents’ configurationAspects’ configurationUser specific compositionApplication Context


Components & Aspects Composition

enter()

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


Aspect Application OrderAuthentication 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)

Authentication

Multiples Views

Awareness

enter()

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.


Architectural Description:Component Definition

Name Interface Implementation

privateroom indroomint indroomimpl

meetingroom meetroomint meetroomimpl

teacher teacherint teacherimpl

student studentint studentimpl

document docint docimpl

videoconftool videoconfint videoconfimpl

Service defined with a Service Description Language (LDS)

translationtranslation


Architectural Description:Aspect Definition

Name Interface Types implementation default

persistence persistenceint envper_level1per_level2

per_level1

multipleviewsmultipleviewsint

user2D3Dvirtualreality

2D

awareness awarenessint typeaware_level1aware_level2

awar_level1

authenticationautenticationint

compowner_auth,accesslist_auth LDAP_auth

LDAP_auth


The UserSite Component

The UserSite containsCVE User preferences

Components & Aspects configuration values

CVE application contextName Implementatio

ns

Persistence Per_level1

Awareness Awar_level2

Multipleviews 2D

Authentication Owner_auth


Architectural Description:Component-Aspect Composition Rules

Component Type Methods Aspect Order Input enter authentication.multipleview PrivateRoom

meetingRoom output all {persistence,awareness} input Teacher

student output Change_state Multiplesviews.{persistence, awareness} Input Open,modify,create Authentication Document Output Close {persistence,awareness}

Middleware Layer

enter()

execute(user,room,enter,{login,passwd})

execute(c1,c2,m,args){ if (entry_aspects(c1,c2,m)) invoke(c2,m,args); exit_aspects(c1,c2,m);

invoke(room,enter,{login,passwd})

1

2

3

eval(enter,{login,passwd})

4

5

6

7

Authentication

MultipleView

Awareness

C1 C2

m()

m()


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.


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

Supporting Heterogeneous Users in Collaborative Virtual Environments using AOP CoopIS 2001 September...

Documents

Transcript of Supporting Heterogeneous Users in Collaborative Virtual Environments using AOP CoopIS 2001 September...