Distributed Collaboration

1

• Distributed Collaboration

Dr. Mark T. MayburyExecutive DirectorInformatio
n Technology Division
Technical Solutions that Make a Difference
http//www.mitre.org/resources/centers/it
Organization G060 Project 05AAV061-C1
MITRE
2
Problem

• Rapid establishment of distributed (e.g.,
  headquarters, field office) teams in ever
  changing, complex world
• Growing transnational threats require virtual,
  global, multidisciplinary teams
• Future teams need to be
• secure
• fast and agile - retaskable, coordinated, precise
• decisive in a dynamic, complex, uncertain world
• knowledge superior
• Distributed, Collaborative (synchronous/asynchrono
  us) analysis/decision support

3
Vision for Distributed C4ISR Collaboration
Global, just-in-time information sources and
services
4
Collaboration Key to Information Superiority
Collaboration
MITRE
5
Collaboration Marketplace
TIME
Different and unpredictable Team rooms Collabo
rative writing Workflow
Different but predictable Work shifts Electron
ic mail Computer bulletin boards
Same Meeting facilitation Tele/video/ desktop
conferencing Interactive multicast seminars
Same Different but predictable Different
and unpredictable
PLACE
Source J. Grudin, IEEE Computer, June 1994
6
Marketplace Evolution
MITRE
7
Example Participant Interface MITREs
Collaborative Virtual Workplace (CVW)
Persistent Virtual Space
Shared Whiteboard
Text Chat
People
Shared Data
Audio/Video Conferencing
Shared Virtual Spaces
Private Data
8
Virtual Workspace Virtual Buildings/Floors/Room
s Layout
9
Collaboration Pilots
Digital Army
Intelligence
Collaborative ATM
Expeditionary Air Force
10
Lessons Learned

• Decreased forward footprint (e.g., ROSC vs FAOC)
• Improved processes
• increased situational awareness
• serial to parallel
• decrease time
• more efficient use of resources (e.g.,
  distributed expertise)
• increase quality
• cohesion in mission planning and execution

Virtual Workspace
Physical Workspaces
Physical Workspaces
Tel Aviv
Washington
Tehran
Moscow
11
Collaboration Server Architecture (Services)
Tool
Search
Archive
Context
Process
Security
Directory
Document
Conferencing
Instrumentation
Semantic Collab
Users/Participants/Roles
Event Support
Asymmetric Collaboration
Interactive Multimodal Participants
12
Architecture Direction Distributed
Collaboration Services

• MITRE Status
• Research and piloting efforts with CVW have
  taught us much about how to define the services
  required to implement a collaboration
  architecture
• Performed a decomposition of the services that
  were part of the CVW environment
• Designing and developing / integrating a complete
  suite of collaboration services
• Taking advantage of COTS and de
  facto/standards-based services already available
  or upcoming on the network
• Transferring experiences, lessons and
  architecture concepts to commercial industry

Directory
Security
Conferencing
Document
Context
Process
Search
Archive
Tool
Instrumentation
COTS marketplace does not provide complete
capability
13
OMG Collaboration Services Specification
http//www.objs.com/isig/wg-cscw01.html
14
JFACC Collaboration Services (JCS)

• JCS draws on CVW experience, but is a new
  implementation - reference for OMG collaboration
  services
• Distributed
• Integrated into CORBA services infrastructure
• CVW rooms supplanted by collaboration contexts
• Some components reused
• Multiple CORBA servers
• Java via OrbixWeb
• Would like to investigate OMG Java binding
• Single-threaded
• Client currently a Java application
• Solaris and NT
• Uses Swing as GUI toolkit

15
JCS Seemless Integration into User Experience
16
JCS Context Provides Team With Shared Resources
Conferences Audio, video, text chat, shared
application sessions, etc.
Participants Roster of the team you always
know who is present with you in the
workspace. These people see the same things as
you in this context.
Folders Information and tools critical to the
job.
MITRE
17
JCS Contexts Are Places For Teams To Work
Focal Context The user is focusing on activity
in this workspace. A user can have more than one
focal context at a time, observing all activity
in each.
Peripheral Contexts The user is present in
these workspaces, but isnt paying active
attention to them right now. The user can
quickly switch attention to one or more of these.
MITRE
18
DARPA ICVInstrumentation, Collection,
Evaluation Cycle
Source DARPA ICV
19
Multimedia Logging/Annotation
20
Evaluation MethodologyConnecting Requirements
and Implementation
Types of evaluation System A vs.
requirements System A vs. system B SystemX vs.
system-X Technical reqmts of system A
MITRE
21
Intelligent Multimodal Participants (IMPs)
22
Expert Finder
Integrated Employee Database
Employees Ranked by Mentions
Mentions of Employee in Corporate Communications
Relevant Employee Projects Publications
23
Human vs ExpertFinder

• Comparison to 20 human resource managers
• Agreement in top 5 IDed experts
• Precision correctly IDed experts / IDed
• Recall correctly IDed experts/ actual
  experts

24
MITRE Corporate Collaboration Council
Over the last three years MITRE has dedicated
over 100 technical staff per year to helping the
Government utilize collaborative technologies

• Build cross FFRDC partnerships
• Coordinate development and tech transfer
  initiatives
• Transfer lessons across our Intelligence and DoD
  sponsors

MITRE
25
Collaboration Services Strategy
Community Collaboration Organization
MITRE
26
Backup
27
Context (1 of 2)

• Contexts are the persistent, objective focal
  point for organizing and containing activities,
  people/agents, information/data, and
  applications.
• They also provide the integration point for
• Conferences
• Instrumentation
• Context-specific capabilities
• Security
• Foundation for collaboration metaphor
• End-user experience metaphor?

28
Context (2 of 2)

• Contexts maintain
• A list of Participants
• A ConferenceManager for conferences
• A Folder of user-published objects
• Contexts may relate to
• Plan nodes (objectives)
• Process
• Organization (logistics cell)
• Functional area
• Individual users (private offices)
• Reimplement room/building metaphor
• Ability to join a context is regulated by
  Role-based access controls

29
Context Directory

• Maintains the searchable directory of Contexts
• Creates locally-hosted Contexts
• Registers Contexts hosted elsewhere

30
Role

• Participants present a set of Roles they are
  representing in a Context or Conference
• Roles are both informational and used for access
  control
• A tree rooted at all users relates all roles
• Access control by name via personal roles
• Credentials are used to authenticate the proposed
  use of a Role

31
Context
Context
Participant
Context Member
Folder
CollabRole
Conference
Credential
32
Context Distribution

• Design allows Contexts to be hosted on distinct
  physical machines
• If a Context will primarily be used on a
  particular LAN, it can be moved there
• Reduce network bandwidth, improve latency
• Still available to outside users
• Suggested that centers of excellence may leave
  contexts available during day-to-day use
• Will be attempted in phase 2
• Context Server design could be replicated
• Not necessary for distributed demo
• Will be investigated as time and priority permits

33
What do Contexts and Roles do for me?

• Contexts provide a workspace management tool
• Switch between sets of tools, data and
  collaborators by switching contexts
• Facilitates discovery of people and useful
  information for users working similar problems
• Roles control access to tools and data
• but also provide cues to which visualizations
  are appropriate for a particular users task
• Role will be related to eventual security
  architecture
• To be effective, Role and Context information
  must be propagated throughout the JFACC system
• User interface across the system needs this
• Back-end tools may need Role/Credential
  information to decide access

34
Participant

• Models a user of the system
• Human user or software agent
• Independent of location/connection
• Contains information required to visually present
  the Participant (name, rank, email address)
• Has a set of Roles known to be available
• Lists Contexts currently a member of

35
Participant Directory

• Searchable directory of Participants
• By role
• By name
• By search language (soon)
• Maintains availability information
• Delivers pages or instant messages to
  Participants and Roles
• Could easily fall back to email/pager/ for
  disconnected Participants
• Is this the authoritative directory service for
  users in the JFACC system?

36
Participant
Participant
CollabRole
Credential
Human Participant
Software Participant
37
Conference

• A Conference is a single-medium collaboration
• Provides
• A roster of Participants and their Roles in the
  Conference
• Media type and suggested application
• Access control
• A ConferenceManager organizes and manages
  Conferences inside of a Context

38
Conference
Context
Conference Manager
Participant
Conference
Node Controller
Conference Participant
...
CollabRole
Credential
Schema Conference
Data Conference
Mcast Conference
39
Conference design

• Conference is designed as an interface
• JCS supports third-party integration of sessional
  collaboration systems against the Conference API
• Conference objects may be hosted anywhere on the
  network
• Network impact dependent on Conference
  implementation
• For example, chatter Conferences typically
  contain a message exploder collocated with the
  Conference object
• Audio/video conferences as MulticastConference
  communicate peer-to-peer

40
Conference implementations

• TextConference implements basic chat capabilities
• MulticastConference models multicast streaming
  media conferences
• vat (audio), nv (video), wb (whiteboard)
• Allows heterogeneous clients for a media type
• DataConference provides a simple generic event
  distribution mechanism with support for roster
  and late join
• Suggested base for application developers
• SDK includes Java-oriented API

41
C2SchemaConference (under development)

• Supports synchronous collaboration on C2Schema
  objects
• Users work on tentative draft objects to be
  eventually relinked to plan
• Provides field-level change notification
• An additional application-specific channel allows
  broadcast of view-specific events (scrolling
  around map, presentation change)
• Current implementation uses CORBA DII
• FineC2 support in design phase