WWG: a WideArea Infrastructure for Group Work

1
WWGa Wide-Area Infrastructure for Group
WorkJoan Manuel Marquès (UOC,UPC)Leandro
Navarro (UPC)
2
General objectives

• Allow people to collaborate with other people
  (group members) anywhere, anytime
  (asynchronously)
• Allow members of a group to know what is
  happening in the group
• Immediately if they are connected
• Later on if they are not connected
• Provide group members an easy and efficient
  access to awareness information (events) and to
  group information (objects)

3
Issues

• Multiplicity people may belong to several groups
• Group membership may be relatively small
• (although there may be many groups)
• Awareness group work requires people know what
  others are doing
• Multiple locations, mobility
• Quality of service users are offered the most
  accessible server from all currently available.
• Degree of Connectivity connected or not ...

4
Requirements (I)

• Information must be accessible at any time, with
  reasonable quality.
• location not relevant may be moved or replicated
• Users need objects and events produced by other
  group members.
• Information about group actions must be accurate,
  up-to-date and consistent.
• Scalable large number of groups, participants,
  events, distance...

5
Requirements (II)

• Adaptable to user needs info where is more
  convenient to users. Also availability,
  reliability and good access time.
• Adaptable to system needs load/storage balancing
  and minimize the exchange of information
• Multiple access points people may connect
  through several access points

6

• Now we have the Issues and requirements, but how
  we structure the architecture of WWG?
• ...EVENTS...
• Important separation between notification of an
  action, and the object(s) involved.
• Notifications are distributed as Events
• The central idea in WWG is the distribution of
  events.

7
Events

• When people do work ...
• Every action produces an event (metainformation
  about actions).
• Events belong to a group.
• Events must be offered to all group members, to
  let them be aware of whats going on in the group
  (awareness).
• Events are small.
• ... Therefore, events must be distributed, as
  soon as possible, to every group member.

8
Event distribution

• Events provide maximum (awareness) information
• Events provide sense of immediateness
• (if distributed synchronously)

• In addition...
• Consistency through events
• (e.g. events may indicate which/where is the
  latest version of an object)
• Events may be used to select the best location
  for an object
• (e.g. close to active members, several locations
  replicated)

9
Event dissemination
10
Event dissemination

• Repository. Contains
• Events
• Objects

11

• Existing solutions (e.g. BSCW)
• Centralized
• Events collected in the remote group server

Group A Group B
12
1st feature replication of objets(close to
members) Problems How many replicas?
Where? Events will tell ...
13

• 2nd feature use of agents
• User agents represent users and collect events
• Repository agents distributed storage for
  events and objects
• Problems event distribution

User Agent
Repository Agent
Repository Agent
User Agent
User Agent
14
3rd feature use event dissemination/distribution
agents (meta-information agents)
User Agent
RepositoryAgent
Metainformation Agent
Metainformation Agent
Repository Agent
Metainformation Agent
User Agent
User Agent
15
Components of the Architecture

• User Agents
• (related to people)
• Repository Agents
• (storage of group history events and objets)
• Meta-information Agents
• (event dissemination agents)

16
User Agent

• Represents (stands for) users in the system.
• Is in charge of being notified of all actions
  done by the user.
• Once notified, it interacts with the rest of the
  system to get the action processed and to get the
  event distributed to other group members.
• Also in charge of receiving events about actions
  done by other members of the group and providing
  this information to the user.

17
Repository Agent

• Represents (stands for) storage units
• Handles the storage of information generated in
  the history of groups
• (e.g. documents, discussions, events, users,
  groups, folders)
• Contributes to the availability and the
  accessibility of the information on a potentially
  large scale,
• Information may move or be replicated in
  different storage units depending on the needs of
  every group.

18
Meta-information Agent

• In charge of efficiently distribute events
  generated by the users, repositories and the
  system.
• Functionality
• Passive functionality efficient routing and
  distribution of event information to interested
  agents, filtering, aggregating and transforming
  events
• Active functionality suggesting the best
  meta-information agent for each user agent,
  helping repository agents to decide the best
  location and the number of replicas needed for
  each object.

19
Three level architecture
20
Architecture of the WWG Middleware (I)

• Open infrastructure Application independent,
  extendable protocols
• Internet scale
• Members of a group can be anywhere
• Supports an arbitrary large number of groups
• Membership depends on the kind of task and the
  degree of involvement of the members.
• Synchronous distribution of events Synchronous
  awareness

21
Architecture of the WWG Middleware (II)

• Members of the group share objects
  asynchronously.
• Interaction organized in groups events and
  objects are restricted to the group.
• The group may be presented to users as a group
  workspace.
• Some events predefined. Applications may extend
  existing events or define new application events.

22
Human-WWG Interaction

• Ways to articulate interaction between an user
  agent and humans (as WWG is an application
  independent infrastructure)
• Applications interact with the WWG user agent
• Collecting and propagating events generated while
  people is using the WWG enabled application
• Notify the user actions done by other members of
  the group
• Some WWG enabled applications may externalize the
  presentation of awareness information.
• May be useful when a person is not currently
  using an application. The shell or group browser
  would use externalized code to present awareness
  information about changes on those application
  specific objects.
• (e.g. a group editor, a shared calendar)
• The WWG user agent provides a group browser
• (a shell application for basic presentation and
  manipulation of objects, events, group awareness).

23
Modes of operation (user agent)

• Inspired by the IMAP models of operation
• Online operations done locally and propagated at
  the same time.
• Disconnected operations accumulated in logs in
  both sides, synchronization at reconnection.
• Offline operations done locally, eventually
  propagated ...

24
Events. Experience at UOC shows that ...

• UOC (Open University of Catalunya) is a distance
  university through a Virtual Campus
• 3 semesters
• 2 different subjects. They had done activities or
  developed a software collaboratively
• Coordination of 9 tutors
• Tool used BSCW
• 23.566 events were generated
• 80 informative events (read event only
  generated once)
• 20 modify-state events
• From those, only 2.2 could cause conflict
• When a person belongs to several groups or the
  members of his groups are very active, he gets
  many events and can be easily overloaded

25
Event classification

• User-actions events
• generated by the application or the user agent
  for each user action. (e.g. read, create, delete,
  copy, paste, undelete, etc. documents or
  messages).
• Inferred events
• Are particular interpretations about how the
  group is evolving.
• The user agent (or a client application) has
  information about the group and the actions done
  by the local user. With all that information,
  like an external observer, the user agent infers
  new events.
• Are perceptions. They are neither true nor false.
• Inferred events are useful when members of a
  group are very active or a member belongs to many
  groups. In those situations, the members will
  receive a lot of events and can be easily
  overloaded. (e.g. A tutor supervising 10 groups
  doing a project a member of this group is not
  working all members of that group seem to be
  working).

26
Another way to classify events (I)

• Conflict events inform that a conflict has
  occurred or the events that tries to solve the
  conflict.
• Modify-state events produced after an action
  that modifies the global estate of the system
  (e.g. a new document, a delete action, a change
  of location, etc.).
• Informative events inform about actions that
  dont modify the global state of the system.
  (e.g. read document, inferred events).

27
Another way to classify events (II)
28
Improving event dissemination

• Many events can be generated, even thought they
  are small. Some techniques should be applied to
  ensure that the system is not overflowed (
  scalable)
• Aggregation e.g. when 10 actions occur in an
  object, a unique event indicating that 10 actions
  occurred is sent
• Grouping send in the same message events that
  goes to the same destination
• Delaying when a lot of events are generated,
  postpone the sending a little while

29
Our present focus

• At this stage of work, our focus is on event
  distribution.
• In our current prototype, the object
  upload/download has been done with WebDAV
• The object replication is not yet supported by
  our prototype

30
Validation prototype simulation

• A prototype implementation in Java is in
  development
• Protocols implemented as an extension of HTTP and
  WebDAV
• Event propagation infrastructure Siena (java)
• Unicast distribution of events on a hierarchical
  tree
• Server (meta-information agent repository
  agent) as an extension of the Tomcat server
• Meta-information agent and repository agent in
  one single process
• Client Java Swing user interface
• Events are XML documents (parsed with Xerces
  (SAX))
• Information and first version available at
  http//www.upcnet.es/?acm1
• A simulator is being implemented
• To prove the scalability of WWG
• As a way to easy refine and essay the WWG
  architecture and protocols

31
(No Transcript)
32
(No Transcript)
33
Conclusions

• WWG is intended to support collaboration among
  people pertaining to groups in wide-area
  networks.
• WWG infrastructure will provide support for the
  construction and integration of collaborative
  applications.
• The WWG infrastructure may be
• Useful to extend existing centralized systems
  (e.g. BSCW) that give support for small to medium
  scale groups.
• an important improvement for groups now using
  primitive tools not adapted to collaborative
  learning such as mailing lists or Usenet News.
• Initial work shows the viability of WWG, but work
  is under way to demonstrate and optimize their
  scalability.
• Also evaluate how awareness is supported,
  describe the operations, and get feedback from
  real use.

34
Thank you !Questions?