Collaboration for ARL
A PET White Paper
D. Bernholdt, S. Browne, W. Furmanski, L. Jackson, C. Scott, M.
Skreiner
Geoffrey Fox (Editor)
fox@csit.fsu.edu
School for Computational Science and Information Technology
And Department of Computer Science
Florida State University
Dirac Science Library
Tallahassee
Florida 32306-4130
Summary
We describe the motivation and promise for web-based collaborative technology to help both administrative and research activities at ARL. We discuss cultural, managerial and technical issues and anticipate ways to address them. We define an overall framework of a collaborative portal and describe its architecture. We describe both general approaches to collaboration (shared display and shared web access page) and the more specialized tools for particular problems. One needs to share database, computer and instrument access. We define and put into context some suggested PET projects. These cover near term activities using existing tools to gather experience and sharpen requirements as well targeted activities aimed at particular ARL needs.
1: Vision
ARL is typical of many organizations -- a federation of many (10) divisions, each of which is geographically distributed. This characteristic is further accentuated if you include the users of HPC facilities, which are spread over the nation. Forming an effective One ARL faces challenges on many fronts -- cultural, managerial and perhaps least of all technological. One ARL also can be helped or hindered by such old fashioned issues as the availability of suitable office space in modern buildings. This white paper addresses the technological implementation of One ARL, and anticipates ways to identify and resolve cultural and managerial issues. Precisely we look at modern and evolving collaboration technology and ask how it can aid the integration of the different parts and people in ARL and the groups it serves. We do this separately for technical (research/computational) and administrative collaboration.
2: Overview and
Collaborative Framework
2.1: Working with the
Internet Technology Cauldron
Collaboration technology of course includes such time-honored tools such as the telephone (synchronous) or mail and e-mail (asynchronous). Here we will focus on Internet based systems that exploit Web and distributed object technologies. Collaboration is then sharing electronic (digital) objects and the richness of this field just reflects the wealth of different objects and the different ways of sharing them. Later we distinguish administrative and technical collaboration, which differ in the nature of the object to be shared and possibly in the required sharing modes. In discussing this field, one must choose a distributed object model – CORBA [23], Java in various forms [21,22,26], Web Pages [24,25], HLA [20] are all possible choices as described in [1,2]. Although all these frameworks are in principle interchangeable, it is not yet clear which will have the most powerful collaboration service. Also one expects that commercial sources will eventually provide powerful collaborative environments -- it is not clear at this stage whether the education and training community, mobile system support, DMSO's modeling and simulation [20], or commercial Intranets [19] will lead to the generally adopted collaboration infrastructure. Maybe even the rather controversial but innovative ideas of Gnutella [17] and Napster [18] will prove to be most popular way of sharing information (an essential aspect of asynchronous collaboration). Programs such as Napster, Gnutella and Freenet allow Internet users to search each other’s PCs for music, video or any other kind of information, and then trade those files for free. However although associated with a particular type of object (MP3 music) and disregard for artist’s intellectual property rights, this approach to file sharing can be applied to any type of object and with any desired respect for ownership.
Each of these object-web communities has somewhat different natural technologies and architectures. However one cannot wait for these decisions to be made for sure; rather we must understand the uncertainties and use existing systems or build capabilities that provide the needed functionality now and as much as possible preserve any investment required of the users. In this regard, careful use of XML to define all the objects and services in any approach is highly recommended. Further any approach can have a complete architecture but should be built and deployed as well defined modules, which can then be linked to current or emerging components from other sources. A few years ago, systems like Habanero [10], NetworkPlace [27] or TangoInteractive [11] could aim at relatively "complete" systems; now this seems impossible. One must deploy or build modest components in a modular fashion. The Persistent Virtual Spaces (PVS) project introduced in Section 5.5, builds on previous NCSA work including Habanero and the DARPA “Integrated Synchronous And Asynchronous Collaboration” (ISAAC) project [33] and is designed in this manner as a suite of modules.
In this white paper we adopt an approach that in modern parlance is called an administrative/training/technical portal. We view a portal as “just” a web interface to a particular application area. A portal employs a modern distributed object framework and uses it to support distributed application specific objects and services with the two interfaces defined below. We adopt a layered approach with one set of capabilities common to all portals and then specialize to different applications.
2.2: Requirements for
the Collaboration Service
Internet Collaboration is formally the service that shares digital objects. At a very high level, the requirements for this service are clear. One needs at least to provide digital analogues for linking distributed resources and people to perform the same type of functions performed in a conventional local environment. Administrative requirements are usually associated with functions such as include staff meetings, briefings, standing committees and focussed applications such as those for finance, personnel, operations and training. Technical collaboration is associated with functions such as the requirement to support computational activities, visualization and the peer-to-peer interaction characteristics of research. There is of course not a clear division between administrative and technical collaboration but rather a gray dividing line – in particular any function of administrative collaboration (meetings, shared database access) is also useful on the technical side. On the other hand, capabilities like collaborative computational steering are only needed by technical collaboration.
The work life of an individual is complex, multi-faceted, and multi-tasked. Further, when teams are formed (e.g., to address larger or more complex problems, or to reduce time-to-completion), inter-personal/inter-organizational communications introduce additional varieties of coordination problems. In attempting to use the Internet to better utilize scarce personnel resources, additional communication problems arise from various effects of distance (e.g., time zones), and from limitations in current commodity computing technologies (e.g., capturing expressiveness and emotion when filtered through keyboard/mouse/screen interfaces). These are all difficult issues for any collaboration system.
Experience has shown that one not only needs synchronous and asynchronous collaboration but also a good integration. The asynchronous mode allows a busy scientist on travel to catch up on the recorded session of a synchronous group meeting. Similarly the sleepy student who missed or skipped class, can review the archived lesson. This integration also provides fault-tolerance as a participant whose connection was cut off due to network or computer problems can use the archive in near real time to catch up. ISAAC addressed these points by using multiple contact mechanisms such as e-mailing transaction summaries hourly to a pager address, and producing a summary web page that includes embedded image thumbnails and links to shared documents. These and other measures were introduced in an attempt to mitigate recurrent scheduling problems that frequently preclude simultaneous attendance by all the members of a team.
One of our difficulties is that especially for technical collaboration, the requirements for collaboration can be implemented in many different ways that trade-off ease of use, performance, and functionality. This is inevitable; the Internet is providing distributed systems of very different capability from what is available today; we must expect substantial experimentation to find out what are the key capabilities and correct implementation of collaboration services. Unfortunately if we provide a system that is too powerful, the users may declare the interface too complex and not use it. A simple interface may on the other hand be rejected for insufficient functionality. Collaborative systems are competing with well-understood and highly optimized approaches; unless we get it just right, users will revert to the old way. As one simple example, audio-video conferencing seemed likely to take off some 5 years ago. Many people tried this but returned to conference telephone calls, which were more reliable and convenient. NPAC has analyzed some of these issues in detail for collaborative computing and visualization in [3]. Deploying what we have today in a carefully monitored fashion can greatly help improve our understanding of what the user needs and what they will accept.
Administrative collaboration has possibly one advantage shared with training systems -- namely one can usually arrange relatively structured environments with clear identification of the person "holding the floor" and scheduled timing. Further we have had reasonable success with distance education and have some understanding of the successful implementation for this collaborative application. Technical collaboration is spontaneous and includes brainstorming sessions which both interactivity and the ability to see the "whites of your eyes" is important. Note that the T&E community has stated a need for real-time and near-real-time processing capability in their computations and this must be reflected in the collaborative support. Technical collaboration needs these enhanced versions of basic services plus particular capabilities such as collaboration computing. We have heard from several CTA's about the interest of their customers and the PET team itself in collaborative systems. So, for example, NCSA IMT and CSM groups are now working with the Propulsion group at Patuxent River Naval Air Station to put together an integrated CAE system that starts with a portal and includes production level collaborative capabilities.
There are many sociological lessons learned and the following are some of those cited:
· Communication/collaboration practices vary in the extreme, by community (professional or local team) and by individual.
· Complex social and political factors bear on the communication/collaboration practices of a group, and on any attempts to shift those practices.
· User communities should not be assumed to be building their own tools. A given deployment project should explicitly plan to develop, customize, or acquire the tools necessary for a successful deployment in the target community.
· Deployment into a user community requires very significant levels of support (e.g., training, help desk, rapid bug fixes, assistance with customization, providing server operating services and other SysAdmin-like assistance).
· General-purpose, crosscutting tools (e.g., whiteboards, document collection management facilities, and workflow management tools) are widely reusable.
· A very great many aspects resulting from collaborative tool use have not been thought through at an organizational or societal level. Factors such as privacy issues in the reuse of recorded interactions, ownership of jointly originated ideas, and observing new forms of communications discipline are nascent in most organizations.
· The technology for connectedness is generally ahead of our ability to effectively use it. This lag in use reflects both the effort needed to build and deploy tools as well as the uncertainties in knowing what to implement. The technologies are moving on to progressively higher fidelity transmissions and expanded modalities. As technology progresses, the barriers to user acceptance inevitably lessen. Time and technology progress is on our side!
These and other metaprinciples need to be borne in mind as we develop a collaboration strategy for One ARL.
4: Distance Education
Technology and Computer Science ResearchWe will build
education specific portals as a set of special services on top of this
framework. These must support the special collaborative needs of education and
special services such as assessment, performance (grading) support, annotation. There are also distinctive
“educational objects” – quizzes, homework, glossaries as well as the curriculum
pages with appropriate hierarchical structure [18]. These will need special XML
support and here we will adopt local standards as necessary and evolve these as
international community efforts (such as IMS [26] and the IEEE Learning
Technology Standards Committee [25]) mature. We will of course pay attention to
support for key capabilities such as displaying mathematics on the Web [21] and
standards for graphics (Java3D, VML, X3D etc.). This distributed object based
distributed system will be designed to support curriculum material built in any
web authoring system and specified either statically or dynamically (from a
database). This simple statement is not easy to satisfy, as it requires
unification of services such as those for customization, collaboration and
events. This is a key research area as such unified services are essential for
the basic strategy of allowing components from multiple academic and commercial
sources. A simpler version of this challenge is well-defined XML interfaces to
allow interoperability of data streams.
We expect commercial portal technology to support
user customization of the environment and we have already indicated that the
base service (event logging) is expected to be useful both in assessment and
individualization of the learning environment. This includes two types of
capabilities. Firstly the capability, probably XML based, to pick and use the
components shown on a particular web-page (portal). We have designed a simple
“portalML” to describe layout and source of page components and further their
collaborative structure [20]. We expect this XML syntax to be a reasonable
start but that we will switch to community standards as they become accepted.
More interesting than this powerful but straightforward XML specification of
dynamic pages, is the methodology for tracking user interactions with the user
environment. As discussed in the Syracuse theses of Lee and Sen [30,43], this
can be done server side when it reduces to the classic analysis of Web Server
accesses logs. More interesting is the tracking of client side events where the
challenge is basically datamining user relevant information. We will on one
hand build in support for this as part of our event service and research
extensions of the simple analyses in the two theses to automatically derive
user profile and learning assessment information. This client side event
information can be used to support universal access as described by Fox and
Gilman from the Wisconsin Trace center [19].
Our web-based virtual university approach implies
that collaboration is a service that shares web-based distributed objects [41].
Previous systems have tended to support either synchronous or asynchronous
collaboration modes but based on our current experience, we will unify them for
this proposal. Initial synchronous deliveries have has some success using
systems like Microsoft NetMeeting, NCSA’s Habanero [23] and Syracuse’s
TangoInteractive [47]. However the new requirements imply we will not use these
but rather build collaboration on the event service of our base (Ninja or
equivalent) framework. We will allow
this to support either synchronous delivery or event archiving and later
delivery of a session. Session control will be implemented in XML using the
generalized portalML described above [20]. We have found that developing shared
animations (for education) is too difficult in current systems like
TangoInteractive, which only easily support complex collaboration-aware
applications. We will use VNC [51] or equivalent technology to allow both
shared display and collaboration-unaware applications, which are less flexible
but much easier to author. One important research issue will be the techniques
needed to provide this unified approach to collaboration.
2.3 Collaborative Portals and their Interfaces
We have suggested that the concept of a collaborative portal
is a useful organizing principle. This includes and generalizes existing
collaboration approaches, which we briefly review below. For administration the
portal is the web-based interface to the One
ARL Intranet; on the other hand for training the portal gives a virtual
university while for technical collaboration the portal supports a web-based
research environment. A general portal provides access to distributed objects
and services on them; collaborative portals support the sharing of these
objects.
Above we have emphasized the
importance of adopting well-defined interfaces implemented in terms of XML. We
express this in terms of a 3-tier architecture with client, server and backend
resource and the two interfaces, as shown in Fig. 1. This approach has been
adapted successfully in the Gateway Web based computing project [ http://www.osc.edu/~kenf/theGateway/
and http://www.npac.syr.edu/users/haupt/WebFlow/]
with the use of two interfaces separating the user (portalML) and system object view (resourceML) and insulating both the user interface and repository
resources from the changing server infrastructure. The explicit definition of
two interfaces seems a useful innovation although most activities (such as ADL
[31] and IMS [32] in the education arena) adopt just a single interface
suggested by a client-server model. As a simple example from the relational
database field (administrative portal), resourceML would define the table
structure used to classify the data while portalML would support user queries
in SQL.
The
general properties of any portal include storing, accessing and searching for
distributed objects (which of course include web pages) in a repository.
Further we have general services such as security and collaboration. Further
general portal capabilities include layout (of the rendered objects on a page),
provision of metadata, universal access, user customization and performance
(through use of mirror or proxy servers).
This appears to be a complex daunting agenda but fortunately many of the capabilities are provided by the new generation of Internet infrastructure such as the new browsers (Internet Explorer 5 and Netscape 6). These in particular have satisfactory support for the World-Wide-Web Consortium W3C document object model and XML, which allows more powerful web-based interfaces than those in systems like TangoInteractive. We believe that an important capability shown in fig. 2 is an event service that allows one to receive and send time-stamped tagged messages. These events define the state of each portal page and can be used to support user customization by saving the event queue. The event queue is designed as a distributed (XML) database to support guarantees of robust delivery and performance through replication of shared events. This idea was pioneered in ISAAC and has been extended here to federate all portal events – whether they are part of a collaborative function or recording particular client or server actions.
Previous collaboration systems have tended to support either synchronous or asynchronous collaboration modes, but based on our current experience we believe that both modes of collaboration must be provided in an integrated fashion. The ISAAC/PVS system from NCSA was a pioneer in this regard [33] and combined a number of just-released technologies from the Java community in attempts to erase or mitigate boundaries between the different ways of collaborating for several tools and support systems. For example, synchronous actions were summarized to static web pages for viewing without the ISAAC software suite, and deposition of documents through e-mail attachments resulted in immediate availability of those documents to synchronous participants.
Synchronous collaboration has had significant success in training using systems like Microsoft NetMeeting, and Syracuse’s TangoInteractive. However the new requirements suggest that one can conveniently build collaboration in terms of the event service of our base distributed object framework. We will allow this to support either synchronous delivery or event archiving and later delivery of a session. This will support latecomers to a session, totally asynchronous access or users recovering from a crash using saved events. Session control can also be implemented in XML using the generalized portalML defined above. Although the main PET experience with collaboration for education and training has been synchronous [4,5], it is worth noting that the dominant commercial activities such as Blackboard, Lotus LearningSpace and WebCT have stressed asynchronous tools.
We have found (see discussion in [3]) that developing shared animations (for education) is very difficult in current systems like TangoInteractive [11] and Habanero [12], which only easily support complex collaboration-aware applications. We believe that in future systems, one must provide both the flexible shared event (TangoInteractive) model and the shared display (as in Virtual Network Computing VNC [8,9] or NetMeeting) and collaboration-unaware applications, which are less powerful but much easier to author. It is particularly important at this time to leave all the options open to the user; we need to find what works without biasing the user by prejudging and only implementing a single limiting collaboration model.
Above we have suggested that collaboration is likely to leverage services provided by the broader community access (the event service is needed to support e-mail, pagers, digital voice-mail etc. . However there are alternative implementations. In sec. 5.4, Furmanski suggests that DMSO's RTI could also provide the base infrastructure. In sec. 5.5 NCSA recommends rapid deployment and hands-on use of a number of technologies NCSA has previously developed along these lines.
3: Administrative
Collaboration
We have noted that training and administration both require similar capability for supporting structured collaboration -- meetings, briefings and classes at prescribed times and with a clear "master of ceremonies". There is a set of base capabilities provided in most collaborative systems:
1) Chat Rooms
2) White Boards
3) Attention getting or "raised hand" in an education vernacular
4) Audio-Video Conferencing
5) Shared "content" including shared Web browser and shared Microsoft Word
These are considered to be primitive capabilities, common to many conferencing systems as stated. Management meetings can be highly unstructured and as such require much more.
One continual area of challenge is the variable quality in digital audio and video conferencing. Higher speed in networking and improving quality of service will address some of the difficulties. At the high end, the "Access Grid" [12] from Argonne and NCSA is an attractive system. It provides high quality audio and video with multiple shared streams. It typically is used in central locations with large displays and has recently been extended to desktop systems. This is elaborated in sec. 5.5 with a proposed testbed between ARL’s Aberdeen and Adelphi sites.
There are also many available commercial products to support desktop audio-video conferencing. One interesting approach is RealAudio/Video [13], which is the dominant multimedia format on the Internet and has the important feature of supporting in the same file, multiple resolutions and compression schemes (and hence different quality and bandwidth choices). Curiously this technology has not been formally targeted at audio-video conferencing although North Carolina State has successfully used it in this way for education [28]. RealNetworks' technology [13,28] uses a larger buffer size, which is less sensitive to the lack of quality of service on today’s Internet. However the buffering which can be as large as 10 seconds, makes it difficult to support interactive conversations. However we have noted in our classes between Jackson State University (JSU) and Syracuse [4,5] that we could use this approach without any penalty when the teacher is lecturing and interacting with the class through the chat rooms rather than the audio channel. This accounts for well over 95% of the time of a typical lecture and such a strategy would be more reliable than the current approach used in TangoInteractive. Note that the current classroom version of Tango2 actually does not allow two-way use of Buena Vista -- the audio-video conferencing subsystem -- and so could certainly use RealAudio/Video without loss of capability.
A key capability of administrative collaboration is the support of shared information stored in a database. This can be supported quite straightforwardly as long as one builds the administrative portal in the architecture of figs. 1 and 2. Then the database is accessed from a Web browser and sharing the Web Page implies that one also shares the backend information. Here we are a sharing the portalML specification of the user request (typically from an HTML or Java form). This does require a shared browser that shares not just the page URL but also events in the page. This was successfully implemented as the "JavaScript Shared Browser" for TangoInteractive. The adoption of the W3C Document Object Model will make this easier in the future. The proposed project of Furmanski in section 5.4 uses HLA/RTI infrastructure to share access to an Oracle database.
4: Technical
Collaboration
Technical collaboration can use asynchronously the basic Web capabilities (publish-subscribe) for sharing -- one person posts information and others access this later on. This is supported then by any project, which provides distributed access to technical resources. Synchronous collaboration is harder but builds on the core capabilities described already in section 3. One must add to these the special capabilities needed for any resource you wish to share and we have discussed these in detail for collaborative computing in ref. [3] while the general architecture of collaborative visualization is nicely discussed in refs [6] and [7]. Many functions are involved in computing and each of these is candidate for technical collaboration support. We can divide computational science into 6 areas.
1) Producing and analyzing data from a program
2) Controlling invocation of a program and “steering” of it (real-time interactions with running program)
3) Debugging and other functions involving either multiple computer users or users and consultants discussing program and its execution in real-time
4) Designing and writing software used in program
5) Brainstorming and other discussions of science (knowledge) where computing was (partially) involved
6) Writing and revising technical papers and proposals associated with a computation
The activities 4) to 6) are very important and closely related to the capabilities described for administrative collaboration in sec. 3. For instance 4) (Designing and building software collaboratively) is a specialized version of general shared document preparation as also is 6). Area 5) is a highly unstructured (and therefore difficult to implement) version of the “general programming problem”. A special and easier version of 5) is support of briefings of formal discussions between distant participants. 1) 2) and 3) are related and ref. [3] describes two cases in detail – collaborative visualization and the much simpler collaborative program invocation. The research literature largely focuses on collaborative visualization, which brings out many but not all the issues. At NPAC, we developed [3] a rather sophisticated collaborative program invocation system aimed at the NCSA Biology Workbench [29] – a very popular computing portal. The area 3) is sort of half way between these examples (as one is sharing computer control and output) and the shared document editing problem. One could be discussing the shared output of a computer program while the geographically separated participants (in this case often just 2 people – a puzzled user and consultant) jointly edit the mistaken program and its control. Collaborative steering is also some sort of combination between invocation and visualization. Here we find multiple researchers sharing and discussing the output of a program (collaborative visualization) and then controlling its evolution by changing parameters (a variant of collaborative program invocation).
Fig. 3: Collaborative Portal for Mesh Generation
An example suggested by Joe Thompson that is related to 2) and 3), is a “remote collaborative mesh generation facility” shown in fig. 3. It is well known to be quite difficult to generate appropriate meshes to support the solution of partial differential equations in complex geometries. The combination of a user, some interactive meshing program and if necessary a (remote) consultant seems an attractive approach. Here the human in the loop is necessary, as currently no fully automatic mesh generator is reliable. The human support is likely to be remote because mesh generation expertise is only present in a few organizations. Again the considerations of collaborative visualization and program invocation can be combined to address this interesting application.
We have used the phrase collaborative visualization loosely above; more
completely we can consider both collaborative visualization and data analysis.
In a typical large-scale application, one would produce data with a back-end
(supercomputer) simulation and then analyze the implications of this
computation. This analysis would include visualization but more generally it is
“data-mining”; extraction of information from data produced by the simulation.
This datamining could involve invocation of statistics package; matrix routines
etc. In general datamining – just like visualization – can be performed server
side, client side or any combination of these. As discussed below, this can
lead to many different collaborative schemes. The server-side application is
usually invoked just once; the client-side programs would be replicated for
each user. This replicated code can run independently, in lock step or in any
collaborative mode between these extremes. Note that independent client
programs accessing the same back-end simulation data is a very reasonable
collaboration model.
There are (at least two) general ways of sharing resources which can be used without any special customization. First, suppose one user is visualizing a particular simulation, filling in a form defining access or browsing a particular program in a file. Then any or all of those windows can be shared (see users B and C in fig. 4) using technology such as shared X [30] or VNC (http://www.uk.research.att.com/vnc/) [8] which share the display on one machine with any number of others. In this case there is only one instance of the activity to be displayed and the rendered result and possibly the user actions (mouse-clicks or keyboard actions) are shared. No changes are needed to the application that is shared. However this is a "lock-step" or rather inflexible model. Each user cannot for instance separately zoom or rotate a shared image.
The second general sharing mechanism (see users A and B in fig. 4 with vertical dotted lines between event adapters) is that already described for databases in section 3. Any resource is accessed by the user (in the architecture of fig. 1) from the client which is typically a Web page. This page defines what object is accessed and any parameters necessary to define its actions in detail. By sharing this client side Web Page, the user implicitly shares the back-end resource. This approach does allow more customization than VNC as one can adjust parameters separately on each client after sharing the basic specification. The core technology is a shared browser supporting the W3C DOM described in sec. 3. In this approach described in detail in section 4 of ref. [3], one has not one invocation of the shared resource as for VNC but typically one for each client -- this is how one provides the additional flexibility. We have built under TangoInteractive optimized systems of this type for a web-linked database and although we did not do any special sharing except for the client, we did build in powerful caching capability into the server so that multiple clients requesting identical or similar database access could do this efficiently.
These general techniques can be supplemented by optimized subsystems where the object sharing is supported by the middle-tier server or backend resource. The above figure 4 illustrates that this model is intrinsically complex as one can implement the sharing at any point on the visualization pipeline. All components to the right of the sharing point in the figure are replicated between the users and hence can be separately customized for each user. Hence the different sharing implementations illustrate our point in sec 2.2, that whereas the high-level requirement (share the output of simulations) is clear, its implementation is not!
Syracuse University built a collaborative visualization prototype SV2 [3] for ERDC using TangoInteractive where the visualization server controlled the sharing. NCSA has also shown how his can be used to share between very different devices -- CAVE and a workstation for instance. ARL's DICE has been re-engineered to support the general architecture of fig. 1 and is a natural candidate to support collaborative visualization.
5:Specific Projects
5.1: Overview and
Collaborative Portals
In the above we have essentially proposed the use of the concept of a collaborative portal to unify support of administrative and technical collaboration. This is the basis of collaboration proposals (ARL-CY5-IC4 and ARL-CY5-IC5) from the Florida State Team and implies that one structure both information and computer access as Web portals. These are summarized in section 5.6. There are four other specific projects from other PET members, which were summarized below and are given in detail later in this section.
In section 5.2, Morgan State proposes shared 3D video streams where the high bandwidth requirements clearly warrant an optimized implementation. Technology like VNC could not keep up with such dynamic displays. In section 5.3, Tennessee notes the value of shared software libraries such as Netlib and propose to investigate how one can enhance the use of these systems with perhaps experts available "on demand" to help users navigate through the many choices offered by such large repositories. In the final proposed project of sec. 5.4, Furmanski takes a computational tool -- the composition WebFlow tool used in Gateway and allows this to be used collaboratively. This would enable both collaborative computational steering and shared design of modular programs. In section 5.5, we present the NCSA PET team’s proposal to deploy both the Access Grid and PVS collaborative system.
Further information on collaborative portals can be found at: http://www.new-npac.org/users/fox/documents/generalportalmay00/
5.2: Collaborative
Visualization with 3D Video (Craig
Scott)
5.2.1: Overview
This suggestion as a
part of the Aberdeen/Adephi collaborative initiative is directed at including
the necessary technology to visualize collaborative information using stereo
video streams. This may impact those ARMY programs that have needs to convey
spatial information as a part of test and evaluation. Examples are tank,
helicopter, C3 control consoles and viewing of live fire exercises. At present,
standards involving 3D video steams are weakly supported in the US and more
strongly supported (or being worked on in Europe and Japan. Especially
noteworthy is the inclusion of this capability in MPEG4, which has yet to be
implemented in present commercial products. This makes a stereo video stream an
attractive subject for DOD to develop and implement in a showcase collaborative
session such as the one suggested during our mid year review.
The mere transmission
of quality standard video is sometimes problematic as experienced during recent
MBONE and TANGO experiments in synchronous conferencing. A robust compression
approach is needed to handle the doubling (or more) of information required for
stereo viewing. Video stream players have been demonstrated using MPEG2 and RLE
encoding, however these implementations focus on merely compressing both
perspectives instead of using the almost identical information contained in the
left and right views. The object model used in MPEG4 is ideally suited for
stereo implementation. There is also a need to implement a compact object based
stereo animation format for 3D graphic content.
5.2.2:
Suggested PET Focused Project
One application is the CHSSI CSM-3 where the
investigator has expressed an interest in viewing simulations in stereo. In
addition to viewing simulation results, high-speed stereo video streams are
used to verify the simulation results. This area examines the interaction
between projectiles and target materials. Most ballistics in general would
benefit from this approach especially when the results are shared from a
realistic perspective viewing.
5.2.3:
Key advantages of project
This approach requires high performance
networking, computing and graphics technologies to make it work by leveraging
and integrating existing technologies.
It leads to more accurate visualization of
ballistics, ergonometrics, live fire exercises and vehicle dynamics.
5.2.4:
Useful Links
http://staff.vscht.cz/~husakm/stereompg.html
http://wwwam.HHI.DE/mpeg-video/standards/mpeg-4.htm
5.3: Collaborative Use of Software Libraries (S. Browne)
Collaboration among researchers is encouraged
when a particular research community develops and maintains a common resource
repository. Members of the community can then both contribute to and draw on
the available resources. These resources can consist of software, tools,
technical reports and/or scientific data. High quality resources can be
provided if the community takes responsibility for peer review of contributed
resources. An example of where this concept has worked particularly well is the
Netlib software repository, which is
contributed to and maintained by researchers in the numerical analysis
community. By making research mathematical software freely available to the
community, Netlib encourages sharing
of research results and allows researchers to benefit from the work of others
and avoid reinventing the wheel. It will be interesting to see how new
web-based collaborative technologies can further encourage this type of
community-based collaboration, e.g., by encouraging more synchronous and
interactive collaboration.
5.4: Collaborative
Whiteboard and Graph Editor (W.
Furmanski)
We propose here some specific near term steps that quantify and elaborate the concept of Technical Collaboration towards Simulation-based Acquisition (SBA) - as outlined by Andy Mark during the PET ARL Year 4 Project Review. In our Year 5 work package "FMS Support for SBA", we proposed two focused efforts:
1) Integrating DICE with Oracle 8i; and
2) WebFlow/UML as a skeleton PSE for FMS+IMT integration towards SBA.
These two tasks are related through the common CORBA middleware: Oracle Application Server in DICE project, and JWORB (or other light-weight Java/CORBA ORB such as ORBacus used by Gateway) in WebFlow/UML project. We also proposed to illustrate the WebFlow/UML use for AVS-style visualization support on top of DICE+Oracle.
As our contribution to the Technical Collaboration White Paper, we propose to develop a Collaboratory UML Editor by linking WebFlow/UML over JWORB with our Object Web RTI (OWRTI) that acts as plug-and-play software bus for WebHLA simulations. We observe here that RTI can be viewed as real-time synchronous or asynchronous (or more generally - time-managed) collaboratory server. In such a model, both human and synthetic (such as simulation or agent) modules are mapped on HLA federates, and the collaboratory sessions and channels are under control of the routing spaces, handled by the Data Distribution Management Service of RTI. Unlike several other possible collaboratory frameworks, the one proposed here directly exposes the 'technical collaboration' aspects by treating humans and the simulations they interact with in a uniform, HLA-compliant fashion. Since HLA does not impose any specific messaging format, we can use here any XML stream that is adequate to a particular application domain and collaboratory style. The resulting Collaboratory UML Editor can be viewed as a distributed whiteboard that allows for shared design, composition, run-time steering and monitoring of visually edited collaboratory applications. In view of our proposed Year 5 focused projects, a natural initial application domain for our editor could be provided by Collaboratory DICE Visualization over Oracle 8i based repository of composable modules and a suitably selected, CTA-dependent set of HPC simulation backends. In our FMS Year 5 tasks, we propose to use SPEEDES but it could be replaced by other engines coming from other CTAs that already use DICE and would benefit from Oracle, Visual Composition and Technical Collaboration support.
5.5: Persistent Virtual Spaces: PVS (Larry Jackson, Mike Skreiner)
The NCSA PET team proposes a specific, near-term project to implement a
collaborative capability that will provide the opportunity to understand better
what is needed and what users will accept. They propose starting with the
scientists and engineers and later move to using the collaboration capabilities
in management meetings. This proposal,
described in the ARL PET CY5 Proposal titled, ARL IMT Persistent Virtual Spaces
(PVS): Emerging Collaborative Technology, is summarized in the following.
As discussed and supported at the April meeting by the IC group, we should immediately set up a testbed based on the Alliance Access Grid videoteleconferencing approach. As a second thrust, NCSA proposes deploying collaboration capabilities from the ISAAC project, which was developed with DARPA funding from the original Habanero system. NCSA’s capstone “Persistent Virtual Spaces” (PVS) project was developed, integrating over a decade of lessons learned and software from a number of prior collaboration technology projects ranging from CAVE immersive visualizations to laptop administrative tools. This approach is relevant for both administrative and technical collaboration. Some key features include:
● The PET Proposal defines a PVS testbed implementation to support hands-on trials between ARL Aberdeen and ARL Adelphi, or other sites. In addition to state-of-the-art hardware facilities, the software suite (the ISAAC/Habanero complex, VNC, JavaMail, Jigsaw, Java RMI, object data bases, Jini-based watchers event service/universal event record and reply mechanism, et al) provides facilities to share/transmit documents and tool output images. These facilities have been developed in recognition of the synchronous and asynchronous communication needs of distributed teams operating under a "standing committee" -like model, where team membership can vary over time, but long-duration shared access is needed. The “standing committee” model, with its mix of synchronous and asynchronous collaborative interactions, was explored in depth in the NCSA/DARPA ISAAC project, and will be examined by ARL staff in “real” work situations.
● The commodity-computing, small-footprint, enhanced quality videoteleconference support hardware suite, a descendant of NCSA's initial "Access Grid" work, was successfully demonstrated to NCSA’s Private Sector Program corporations in April 2000, and is ready today to be deployed in a fully operational testbed.
● This highly capable testbed will give ARL PET a window into requirements for effective use by DoD technologists (e.g., in support of data intensive analysis and visualizations), and managers and administrators (e.g., in support of decision making and policy negotiation in highly equivocal/abstract situations).
● This testbed will also serve in staff training, and in identifying, refining, and prototyping further system/tool developments.
.
Implementation of this testbed will enable ARL to demonstrate collaboration to the HPCMO and other potential customers immediately. It will enable technologist and administrator user teams to practice collaboration, and articulate requirements that will drive further refinements of this system.
5.6 Technical (CY5-IC4) and Administrative Collaboration
(CY5-IC5) (Geoffrey Fox)
These proposals embody the basic approach described in sections 1 through 4. They include the IC support of the Access Grid testbed discussed above in section 5.5. To this they add a second commercial audio-video conferencing testbed based on RealNetworks technology. These capabilities are supplemented by targeted tools, which explore key requirements in both the technical and administrative domains. These will be combined in a set of experiments with HPCMP users and ARL MSRC/PET personnel and summarized in end of year reports. Training will be developed and given in tools.
The technical collaboration has particular focus on collaborative visualization involving the DICE framework as well as key tools including a shared browser. Scientific and engineering applications require both shared maps (GIS) and mathematics. In the latter case we deploy emerging tools using MathML.
The administrative collaboration effort includes shared mailing list and document repositories. For the latter we include the current project and technical report database developed by Moses. This effort naturally links with the discussions last year of the Intranet (IOE) Environment for ARL. One needs innovative modern information systems to support in order to be able support the collaborative requirements.
References
1) Introducing a New Paradigm for Computational Earth Science – A web-object-based approach to Earthquake Simulations, Geoffrey Fox, Ken Hurst, Andrea Donnellan, and Jay Parker to be published in a book to be published by American Geophysical Union, http://www.new-npac.org/users/fox/documents/gempapermarch00
2) Portals for Web-based Education and Computational Science, Geoffrey C. Fox, ERDC Technical Report May 2000, http://www.new-npac.org/users/fox/documents/generalportalmay00/erdcportal.html.
3) Overview of Collaborative Computing and Some NPAC Experience, Geoffrey C. Fox and Jianxiang Jin, ERDC Technical Report May 2000, http://www.new-npac.org/users/fox/documents/collabcompmay00/collabviz.html
4) Bernholdt D.E., Fox G.C., Malluhi Q., Markowski R., McCracken N., Mitra D., Podgorny M., Scavo T., Synchronous Learning at a Distance: Experiences with Tango, Proceeedings of SC98 Orlando, IEEE. http://www.npac.syr.edu/projects/training/Papers/sc98/
5) Fox G.C., From Computational Science to Internetics: Integration of Science with Computer Science, Chapter in a book dedicated to John Rice of Purdue (to be published). http://www.npac.syr.edu/users/gcf/internetics2/
6) Collaborative Visualization; Jason Wood; Leeds University PhD Thesis, February 1998. http://www.scs.leeds.ac.uk/kwb/publications95.htm#Love:98; http://cself27.leeds.ac.uk:8010/jason/Thesis/; http://cself27.leeds.ac.uk:8010/jason/html/books.html
7) Roussev V., A Reference Architecture for Distributed Collaborative Applications, technical report from Univ. North Carolina Collaboration Bus Project, 1999 http://www.cs.unc.edu/~dewan/cb.html
8) VNC or Virtual Network Computing at http://www.uk.research.att.com/vnc/.
9) Virtual Network Computing, Tristan Richardson, Quentin Stafford-Fraser, Kenneth R. Wood & Andy Hopper, IEEE Internet Computing, Vol.2 No.1, Jan/Feb 1998 pp33-38.
10) Habanero Home Page at NCSA - http://havefun.ncsa.uiuc.edu/habanero/
11) TangoInteractive Collaboration System home page http://www.npac.syr.edu/tango
12) Argonne National Laboratory NCSA Alliance Access Grid Digital Conferencing System, http://www-fp.mcs.anl.gov/fl/accessgrid/default.htm
13) RealNetworks provider of Internet Multimedia Technology and “Portals to such material” http://www.realnetworks.com
14) Blackboard Inc is a major provider of (asynchronous) collaborative education technologies. http://www.blackboard.com/
15) Lotus(IBM) LearningSpace http://www.learningspace.com.
16) WebCT: Major commercial web-based course authoring system: http://www.webct.com/
17) Gnutella: Counter Culture distributed information system http://gnutella.nerdherd.net
18) Napster MP3 Distributed shared file system http://www.napster.com
19) E-Speak project at Hewlett-Packard, http://www.e-speak.hp.com/
20) HLA or High Level Architecture from Distributed Modeling and Simulation Office DMSO at http://www.dmso.mil/portals/hla.html
21) iPlanet e-commerce software from Sun Microsystems, http://www.sun.com/software/iplanet/
22) Ninja project at University of Berkeley, http://ninja.cs.berkeley.edu/
23) Object Management Group (CORBA) at http://www.omg.org/
24) Simple Object Access Protocol http://www.develop.com/soap/
25) W3C Document Object Model http://www.w3.org/DOM/
26) Jini remote object technology at http://www.sun.com/jini/overview/index.html
27) netLearningPlace building on netWorkPlace from NCSA http://www.ncsa.uiuc.edu/Edu/ITG/netLearningPlace/
28) Web Learning System from North Carolina State University, http://renoir.csc.ncsu.edu/WLS/
29) The Biology Workbench Home Page from NCSA Illinois and the University of San Diego. http://biology.ncsa.uiuc.edu/.
30) XMX Shared X Windows Multiplexor, http://www.cs.brown.edu/software/xmx/.
31) ADL SCORM: Sharable Courseware Object Reference Model, http://www.adlnet.org/ADL-TWG/documents.htm
32) IMS (Instructional Management System) Project from Educause, http://www.imsproject.org/
33) Integrated Synchronous And Asynchronous Collaboration (ISAAC) http://www.ncsa.uiuc.edu/SDG/Projects/ISAAC/