EXTERNAL MODULES

Not all collaboration modules can be added to existing single-user layers or new pseudo-layers. It may also be necessary to create new external modules that do not belong in the protocol tree, for several reasons (Figure 9.11):

  
Figure 9.11: Reasons for adding external modules.

• Session Management: In a collaborative system, session management modules are needed to create/delete the protocol tree of an application when a session with an application is started/terminated. In the single-user case, the operating system is responsible for creating/deleting interactive sessions, but in the multiuser case, special, possibly application-specific, protocols are necessary for session management [RG96]. Since these protocols create/delete protocol trees, they cannot be implemented within the tree itself, and thus must be provided by external modules.

• Centralization: Replicated collaboration-aware layers may need to communicate with central modules to keep central resources such as locks or ensure global ordering of messages communicated among these layers. These modules can be implemented in the stem of the protocol tree, which is the approach taken in Suite. However, this approach cannot be taken if the architecture is fully replicated or if it cannot have any collaboration-aware stem layers. In these cases, the central modules must be external to the protocol tree.

• Site-Specific Processing: Centralized collaboration-aware layers may need to communicate with modules that must be located at a particular site for efficiency or other reasons. Examples of such modules are those that access files, devices, or processes at a particular site or keep information about the active users or sessions at a site. These modules can be implemented in collaboration-aware branch layers at that site if such layers exist; otherwise they must be modules external to the protocol tree. Systems that distribute replicas create a site-specific server for creating and terminating processes at that site. Similarly, Suite creates an audio server at each site to access the audio devices at that site [RMS93].

• Collaboration and Interaction Independence: For modularity reasons, it may be desirable to separate the processing of interaction and collaboration events. As mentioned before, pseudo-layers can be used to increase this separation since such layers are responsible only for transmitting interaction events and not for transforming them. However, these layers have the performance disadvantages mentioned before and support limited separation since they must process both kinds of events. Similarly, within a layer, encapsulation may be used to separate the interaction-aware and collaboration-aware objects. An approach providing more separation is to process collaboration events in external modules, which can be shared by multiple layers and branches.

• Inter Branch Independence: It is also useful to reduce the awareness a branch has about branches created for other users. Reduced inter-branch awareness increases the modularity of the system, and more important, reduces the cost of connecting a branch to other branches. If every branch kept track of every other branch it may need to communicate with, then branch awareness and interaction awareness would be implemented by the same layers, and more important, a branch would need to be informed each time a new branch is created that may need to communicate with it.

  It may be more attractive to implement one or more (possibly replicated) external message servers [Rei90], responsible for linking the replicated branches. A message server receives message patterns from information clients indicating the kind of messages they are interested in receiving, and announcements from information servers announcing events in which information clients may be interested. The message server forwards an announcement from an information server to all information clients who have registered an interest in the announcement. This is essentially the approach taken in [BMT89]. A message server leads to more modularity and reduced connection cost, but increases the ``hop count'' of inter-branch messages, that is, increases the number of modules responsible for processing inter-branch messages. The increased hop count is a serious problem if the message server is centralized and the branches are distributed, since the message server can become a central bottleneck. On the other hand, as mentioned before, a central agent such may be necessary in any case to implement global ordering of distributed operations.

In many of the cases above, we have not defined the specifics of how the external modules are connected to each other, threaded, distributed, or replicated. These issues can be resolved in the same way they were resolved for the original modules. In fact, it is possible to create a hierarchy of replicated, distributed, concurrent external modules. For instance,

GroupKit creates a central registrar that acts as a connection point and name server, with replicated local session managers at all sites deciding the policy for how people enter into groupware sessions.