1 of 25 11/20/ :14 AM

Transcription

1 1 of 25 11/20/ :14 AM

2 2 of 25 11/20/ :14 AM Journal of Digital Information, Volume 1 Issue 2 Article No. 7, To cite this paper please include the details above in the full reference Themes: Hypermedia systems Peer reviewed paper Printable version available. Towards a Common Reference Architecture for Open Hypermedia Kaj Grønbæk and Uffe Kock Wiil * Computer Science Department, Aarhus University, Denmark kgronbak@daimi.aau.dk, home page * The Danish National Centre for IT Research, Aarhus University ukwiil@cit.dk, home page Key features: References; Table 1; Figures 1, 2, 3, 4, 5 6, 7, 8, 9, 10, 11, 12, 13 Abstract This paper contributes to an ongoing effort on standardizing open hypermedia system architectures and communication interfaces. Open hypermedia systems share the property of being able to provide non-hypermedia applications with hypermedia structuring and navigation capabilities. This support is currently provided in many different ways. To be able to standardize communication interfaces, it is necessary to develop common understanding of the different architectures of existing systems and to develop a common reference architecture for open hypermedia systems. A reference architecture should provide a common language for the design of open hypermedia systems in terms of architectural elements and interfaces. The paper identifies a number of important requirements and characteristics for open hypermedia systems and examines some of the most well known open hypermedia architectures and reference models. The analysis illuminates the commonalties and differences in terminology and architectural elements. The analytical results are used to propose common terminology and a common reference architecture for open hypermedia systems (CoReArc). CoReArc identifies several different architectural elements and communication interfaces for potential interface standardization. Interface standardization may be achieved through a single physical protocol with several suites or topics or through several independent protocols. CoReArc can be used to identify and discuss the different communication interfaces of an open hypermedia system. 1 Introduction Open hypermedia systems (OHSs) address the difficult tasks of providing hypermedia services to computing entities (applications, stores and other Contents 1 Introduction 2 Open hypermedia services and architectural requirements Open hypermedia services and previous work General Requirements for an open hypermedia reference architecture 3 Analysis of open hypermedia system reference models and architectures Flag model Devise hypermedia architecture Shim architecture HyperDisco architecture HOSS architecture

3 3 of 25 11/20/ :14 AM services) in the computing environment. Using the services of an OHS, various computing entities can become hypermedia enabled and provide hypermedia services orthogonal to existing storage and display services. Hypermedia enabling of existing computing entities can potentially be a very complex task. One factor adding to the complexity is the lack of standards in the open hypermedia community. Each OHS defines its own data model, linking protocol (protocol to communicate with hypermedia enabled computing entities), system architecture and hypermedia services. The lack of consensus about what an OHS is has resulted in incompatible systems: a computing entity that has been enabled for one particular OHS cannot be used with other OHSs. It should be noted that openness could also apply to hypermedia data formats. Data formats such as HTML, SGML and HyTime can be considered open in the sense that files of arbitrary types may be referenced or embedded. This notion of openness requires that the rendering machine is open for plugging in rendition modules for the new data formats in question. However, data format openness is not the primary focus of open hypermedia research. The open hypermedia community has formed a working group to address the important standardization issues. The Open Hypermedia System Working Group (OHSWG) [28] formed out of the 2nd Workshop on Open Hypermedia Systems at Hypertext '96 in Washington, DC (March 1996) [40]. The initial goals of the OHSWG were to define open hypermedia systems and to define open link services. The 2.5 OHSWG meeting in Southampton, England (December 1996) [7] showed that it is difficult to discuss scenarios and especially protocols [9] Open hypermedia reference architecture (OHRA) Summary of architecture analysis 4 Proposal for open hypermedia terminology 5 Proposal for a common reference architecture (CoReArc) for open hypermedia Conceptual layers Architectural elements Conceptual interfaces Instantiations 6 Summary Acknowledgements References without having a common consensus on what the concepts and building blocks (architectural elements) of an OHS are. Thus, a third goal defining an open hypermedia reference architecture was added to the OHSWG agenda at the 2.5 OHSWG meeting. The first work addressing the reference architecture issues ([11, 16, 44]) were presented at the 3rd Workshop on Open Hypermedia Systems at Hypertext '97 in Southampton, England (April 1997) [39]. This paper proposes a reference architecture for OHSs. The purpose of the paper is to continue the work towards common concepts, architectural elements and terminology for OHSs. A common consensus on these important issues is essentially a prerequisite for being able to identify (and discuss) the necessary communication interfaces of an OHS. We approach these issues by examining some of the most well known architectures and reference models for OHSs. The analysis is used to illuminate the commonalties and differences in terminology and architectural elements and to propose both common terminology and a common reference architecture for OHSs. We start in Section 2 by identifying a number of services that OHSs must provide and by listing a set of general requirements for an open hypermedia reference architecture. Section 3 examines six different open hypermedia reference models and architectures that has been proposed in the literature and Section 4 examines the use of different terminology in existing open hypermedia models and systems. Based on the discussion in Sections 3 and 4, Section 5 presents a proposal for a common open hypermedia reference architecture. The basic idea is to take the best of existing approaches and propose an architecture that can provide the identified services and fulfil the identified requirements. Section 6 concludes the paper 2 Open hypermedia services and architectural requirements Before discussing and designing a reference architecture for open hypermedia, it must be made clear what it is that the open hypermedia community is trying to achieve. This section sets the context by discussing important services of an OHS and general requirements for an open hypermedia reference architecture.

4 4 of 25 11/20/ :14 AM 2.1 Open hypermedia services and previous work Open hypermedia research pursues the goal of a global unified environment where hypermedia is the central paradigm for structuring information and navigating among pieces of information. In the ideal world, all operating systems support a set of standard open hypermedia structuring and navigation services and all services, applications and stores have been built to use these services [26]. In the real world things are much different: no standards exist, open hypermedia services reside in middleware components rather than the operating systems, and existing services, applications and stores in most cases have not been built to use open hypermedia services. Thus, OHSs must provide a number of services to overcome some of the current "limitations" of the real world. This section lists six types of services (integration, interoperability, structuring, navigation, distribution and collaboration) that are important to OHSs and should be considered key issues when designing a reference architecture. Navigation and structuring are the core services of any OHS. Integration, interoperability and distribution are services that the OHS must provide to operate in the real world. Collaboration is a service that has proven very valuable in previously reported hypermedia work; this includes personal experiences accumulated from the DHM [13] and HyperDisco [41] projects as well as experiences from various other hypermedia projects. In the following, each service is briefly described and relevant and important previous work in the hypermedia field is listed for each service. Integration To overcome that fact that most existing services, applications and stores have not been built to use hypermedia services, OHSs should be capable of integrating (1) existing services such as scripts, programs, software agents and hardware devices such as video cameras, (2) third party applications such as editors, browsers, systems, calendars and spread sheets, and (3) third party stores such as databases, hyperbases, link servers, document management systems, file systems, and CD-ROM's. A number of researchers have made important contributions to the understanding of integration in OHSs: Davis et al. [8] describe various methods and techniques that have been used to integrate existing applications with the Microcosm system. The Microcosm experience suggests six different levels of application integration. Davis et al. [9] present a proposal for a standard open hypermedia protocol (OHP), which allows hypermedia enabled applications to be shared among OHSs. Whitehead [38] presents an architectural framework for integration of applications with OHSs, which collects and extends the integration experience accumulated in the open hypermedia community. Noll and Scacchi [27] describe how the DHT system uses gateways to integrate diverse information repositories (stores) under a common hypermedia model. Interoperability OHSs should provide means to interoperate with other OHSs as well as with integrated applications, stores and services. Interoperability among existing OHSs (that typically runs in isolation and ignorance of other OHSs) is an important step towards a global unified hypermedia environment. An increasing number of open hypermedia researchers are addressing the interoperability issue: Goose et al. [11] propose an overall architecture for interoperation between existing OHSs in a distributed and collaborative model. Nürnberg and Leggett (also part of this special issue) propose a reference architecture that can support an open set of structure models (application domains). Wiil and Whitehead [44] describe an interoperability experiment between Chimera [3] and HyperDisco [41]. A custom-made interoperability protocol allows the HyperDisco tool integrator to interoperate with the Chimera server as if it was a HyperDisco workspace. Chimera [2], DHM [13], Microcosm [5], and the Navigation Manager (NavMan) in HOSS [31] have all been modified in different ways to interoperate with the World Wide Web (WWW) [4]. Structuring OHSs should provide a rich set of hypermedia structuring (authoring) services such as anchors, links, file-wrapper nodes, content nodes, composites, pspecs (presentation specifiers, which specifies how a hypermedia entity should be presented), locspecs (location specifiers, which specifies the location of a hypermedia entity), refspecs (reference specifiers, which specifies the location within a hypermedia entity), spatial hypertext, etc.

5 5 of 25 11/20/ :14 AM Although the basic hypermedia concepts are more than 50 years old, researchers are still trying to improve and add to the understanding of hypermedia: The open hypermedia researchers from Texas A&M University are continuously arguing the need for expanding the current view of OHSs from being systems that only handle linking to be systems that can handle general structure processing (e.g., [29], [30] and [31]). The work by Grønbæk and Trigg [15] on extending the Dexter model [19] have added several new hypermedia concepts and services (e.g., locspecs and refspecs) that allows the Dexter model and other similar models to operate in an open hypermedia environment. Some of the latest results in this area include the work on spatial hypertext structuring (e.g., [24]). Navigation OHSs should provide a rich set of hypermedia navigation services such as link traversal, querying, graphical overviews, local and global maps, guided tours, tabletops, fish-eye views, paths, trails, spatial hypertext, etc. Although link traversal is the most used navigation technique in hypermedia systems, many researchers have discovered that link traversal is insufficient and should be combined with other navigational aids. The hypertext overview paper by Conklin [6] identifies a number of navigational issues (e.g., the "lost in hyperspace" problem). Besides Conklin, several hypermedia researchers have made important contributions to this area. The work on some of the classical hypertext systems Intermedia [37], NoteCards [36] and KMS [1] deserves much attention. Spatial hypertext systems (such as Aquanet and VIKI [25]) provide users with spatial affordances for both structuring and navigating information. Some of the latest results in this area include the work on hypermedia design (e.g., [35]). Distribution The OHS itself and the integrated services, applications and stores must be capable of running on different machines in a local area network and across different Internet domains. Distribution is handled by most OHSs (at least on a local area network). The recent trend is to address the issues of Internet distribution: The WWW is the obvious example of a hypermedia system that provides a simple and extensible hypermedia model that successfully has been distributed across the Internet. Many systems interoperate with the WWW to achieve Internet distribution (see "Interoperability" above). A few systems such as HOSS [31] and HyperDisco [41] provide their own approaches to Internet distribution independently of the WWW. Collaboration OHSs should provide support for collaborative authoring of both hypermedia contents and structure. Different modes of collaboration should be supported including asynchronous work (data sharing among a group of authors engaged in individual authoring sessions) and synchronous work (simultaneous sharing and creation of contents and structure by a group of authors engaged in a single shared authoring session). Collaboration in OHSs is to a large extent still unexplored. For example, DHM has collaboration support built into the underlying framework [14], but the practical experience is limited to a single platform (Unix) and does not include the rich set of desktop applications usually being integrated with DHM. Thus, there are still many challenges to meet. Important approaches to collaborative hypermedia systems include the work on SEPIA and DOLPHIN at GMD-IPSI and the work on ABC at University of North Carolina. Research at GMD-IPSI with the SEPIA project [34] and its successor DOLPHIN [17] have over the years contributed with many important aspects and concepts relating to collaboration in hypermedia systems. The ABC matrix provides a hypermedia infrastructure in which existing single user applications can be incorporated with few, if any, changes and used collaboratively [21]. Recent experiments with HyperDisco [41, 42] indicate that much of the accumulated knowledge from collaborative hypermedia systems can be re-used in an open hypermedia environment. XEmacs and other tools have successfully been modified to operate in an open, distributed and collaborative hypermedia environment with techniques similar to those used in earlier experiments with collaboration in monolithic settings [43]. A core set of open hypermedia services could probably be identified, but in general an OHS should be capable of providing as many of these services or as few of these services as desirable. Thus, a reference architecture for OHSs

6 6 of 25 11/20/ :14 AM should reflect the fact that OHSs provide different levels and types of services within the six areas listed above (and potentially other areas as well such as information retrieval). Thus, the above list of services is not considered to be complete. Future research is likely to add additional services to the list. However, the above six services are considered to be important and a reference architecture for open hypermedia should not in any way restrict these (and future) services. 2.2 General requirements for an open hypermedia reference architecture In addition to the already mentioned requirements for hypermedia services, the following general requirements for an open hypermedia reference architecture are believed to be important: Conceptual Architecture A reference architecture should provide a high level of abstraction dealing with concepts, architectural elements and interfaces rather than describing physical processes, protocols and services. Generality A reference architecture should be general enough to be mapped onto several physical implementations of the concepts and architectural elements and comprehensive enough to allow the concepts and architectural elements of existing OHSs to be mapped onto the reference architecture. Simplicity A reference architecture should be simple and easy to understand. There should be few architectural elements and few interfaces between the elements. Extensibility A reference architecture should be extensible with respect to concepts, architectural elements and interfaces. It should be possible to augment the architecture to deal with special cases (e.g., special classes of OHSs) and to include support for new types of (hypermedia) services and requirements not anticipated at the time of inception. The identified general requirements for OHS architectures will be used in Section 3 in the analysis of existing open hypermedia reference models and architectures and the identified open hypermedia services will be discussed again in Section 5 in connection with the proposed common reference architecture for open hypermedia. 3 Analysis of open hypermedia system reference models and architectures Only a few open hypermedia reference models and architectures have been proposed in the literature. This section presents six approaches, the Flag model [46], the DHM architecture [14], the Shim architecture [9], the HyperDisco architecture [41] and its instantiation in the interoperability experiment described in [44], the HOSS architecture [31], and the open hypermedia reference architecture (OHRA) [11] (an updated version of the OHRA paper is also part of this special issue). Each of these six candidates is examined and matched against the four general requirements (Conceptual Architecture, Generality, Simplicity and Extensibility) and important contributions of each approach are identified. The approach taken in the subsequent sections is to use the results of the analysis to develop a reference architecture, which fulfils the requirements. 3.1 The flag model The Flag model [46] modifies and extends the terminology of the Dexter model [19] to deal explicitly with integration and use of existing third party viewers (applications). The main idea is to distinguish between storage aspects and runtime aspects and between structure and contents. These distinctions make the Flag model a general and conceptual reference model, which identifies four functional modules and four protocols in OHSs (see Figure

7 7 of 25 11/20/ :14 AM 1). Figure 1. The Flag model. Viewers use the session manager to manage structures (anchors, links, etc) in documents via the linking protocol. The session manager uses the data model manager to store and retrieve structures via the presentation protocol. The viewers use a storage manager to store and retrieve documents via the storage protocol. Some OHSs provide their own storage manager, which can be accessed directly from the viewers through the storage protocol or indirectly (via the session manager and data model manager modules) through the storage protocol. The Flag classifies OHSs into two categories, link servers, which are those systems that only provide structural storage (e.g., Microcosm [20], Chimera [3] and Multicard [32]) and open hyperbase systems, which can also handle storage of contents (e.g., DHM [13], SP3/HB3 [23], HOSS [31] and HyperDisco [41]). The Flag model makes it explicit that existing viewers can participate in the hypermedia services and store contents in one place (e.g., the file system) via the storage protocol and store structure (and in some cases contents) in the OHS via the linking protocol. Another merit of the Flag model is that it is completely system independent and provides a general and conceptual framework to classify, describe and compare (open) hypermedia systems. This allows the Flag to be used both to specialize hypermedia concepts and terminology (the functional modules and protocols of the Flag can be mapped to several physical implementations) and to generalize architectural elements and hypermedia services (existing hypermedia systems can be described, classified, analyzed and compared in a system independent way using the concepts and terminology of the Flag). The Flag model is not immediately extensible for introduction of new modules and interfaces, but it is open ended in the sense that it does not prescribe the concepts to be used in the individual interfaces and modules. 3.2 The Devise hypermedia architecture Grønbæk et al. [14] present the architecture of the Devise Hypermedia system (DHM), which is a modified and extended Dexter-based [19] layered architecture featuring four conceptual layers: Application Layer, Communication Layer, Runtime Layer, and Storage Layer (Figure 2). The main contribution of this architecture is a mapping of the conceptual layers of DHM (and thus the original Dexter model) to a physical system architecture. The DHM architecture radically alters the sequence of Dexter's conceptual layers: (1) the Within-component Layer is renamed the Application Layer and is moved away from the Storage Layer and (2) a new fourth conceptual layer, the Communication Layer, models communication between the Application Layer and the Runtime Layer. The four

8 8 of 25 11/20/ :14 AM conceptual layers are mapped to three physical layers of communicating processes (application, hypermedia service process and hypermedia database server). This physical architecture is not fixed - variants are possible: (1) the hypermedia database server may be just a library included in the hypermedia service process running as a single process, (2) the DHM browser application may be an integral part of the hypermedia service instead of being a separate process, and (3) the distribution of the processes among server hosts and user workstations may differ. The Application Layer encompasses end-user applications integrated with the hypermedia system, and may include text, graphical and video applications as well as hypermedia browsers. An application handles a specific type of data object, e.g., text objects. The data objects may be stored by the applications in separate files outside the hypermedia database server or the applications may take advantage of the hypermedia database server storage facility. The data objects manipulated by these applications belong to the Dexter Within-component Layer. However, [14] interprets the conceptual Within-component Layer somewhat wider than the original Dexter model, because it is not limited to just passive data. The internal manipulation of the data objects is viewed as operations on the data objects but mediated by the dedicated application. Thus, an application's functionality belong to the Application Layer and not the Runtime Layer as proposed by the original Dexter model. The applications' hypermedia functionality only exists through communication with the corresponding Runtime Layer. An application represents the contents for a specific type of component by supporting a protocol for communication with the hypermedia service process. The Communication Layer is responsible for the communication between the hypermedia service process and the applications. This layer implements the DHM protocol via the inter-application communication facility available on a given platform. The Communication Layer is physically realized in two places: through macros or plug-in modules in the applications and as classes and objects in the hypermedia service process. The Runtime Layer implements the core hypermedia behavior specified by the generic classes of the Runtime Layer. The runtime classes are physically implemented within the hypermedia service process, which is responsible for handling links, anchors and components at runtime. The hypermedia service process communicates with the applications on the one hand and the hypermedia database server on the other hand. The Storage Layer consists of two elements: the database schema implementing the extended Dexter Storage classes, and the physical hypermedia database system storing the objects. The Storage Layer is similar to the Communication Layer, being physically located in two different places in an implemented system. The hypermedia database server provides permanent physical storage for the hypermedia objects. The objects being stored are instances of classes specialized from the generic classes implementing the Dexter Storage Layer concepts. Depending on the type of database chosen, the Storage Layer classes may be represented in several ways. Figure 2 shows a DHM scenario, where two users with their own applications are connected to multiple hypermedia databases and multiple document managers possibly distributed on several hosts in a network. The architectural elements of DHM and integrated applications are shown relative to the proposed conceptual layers of the architecture.

9 9 of 25 11/20/ :14 AM Figure 2. The layered DHM architecture inspired by the Dexter model. A strength of this architectural model is the combination of a diagram for the actual relationships among architectural elements of a specific system configuration and conceptual layers. A different system configuration can be mapped to exactly the same conceptual layers thus illuminating the specific differences in the configuration. While Figure 2 depicts a system configuration with ordinary desktop applications and a document management system typically running on a shared file system, Figure 3 presents another OHS configuration mapped onto the same conceptual layers in a consistent fashion. Another strength is that both an application / hypermedia service protocol and a hypermedia service / hypermedia database protocol are identified. Figure 3. The DHM WWW integration mapped to conceptual layers. The main strength of this architecture model is the generality and simplicity of the conceptual layers and the notation, which can be mapped to many existing OHSs such as Microcosm [20], HyperDisco [41], and HOSS [31]. As an example the mapping of Microcosm architectural elements onto conceptual layers may look like the following: Viewer to Application Layer, OHP to Communication Layer, Filter Manager to Runtime Layer, and Link bases to Storage Layer. One weakness of the DHM architecture is the potential ambiguity in whether only architectural elements of the OHS or also the integrated applications are mapped to the conceptual layers. This ambiguity comes to the surface when locating the contents of components managed by the applications. Should the contents be mapped to the (physical) Storage Layer or to the Application Layer? The Application Layer is an extension of the original Dexter

10 10 of 25 11/20/ :14 AM Within-Component Layer also covering the display and editing behavior coupled to the contents of components. As a consequence of this, the document management system in Figure 2 as well as the WWW server in Figure 3 are placed in the Application Layer. This choice may not seem immediately obvious since both document managers and WWW servers represent storage. This ambiguity is avoided in the Flag model (Section 3.1) where both the document management system and the WWW server would map onto the storage manager module The shim architecture Davis et al. [9] propose an architecture that supports reuse of third party application extension modules across different OHSs. The idea is that specific applications should be extended to communicate with a hypermedia service via a standardized protocol called OHP (Open Hypermedia Protocol). Having integrated applications this way, so-called shims should be implemented to fit the standardized OHP to proprietary protocols implemented by say DHM and Microcosm. This approach would then emancipate the OHP community for writing a lot of nearly identical extension modules for the applications to be integrated with each OHS. The idea is depicted in Figure 4. Third party applications are standard software packages developed without built-in hypermedia functionality. The Communication Protocol Shim is responsible for translating the logical protocol operation invoked from say the Application to the specific network protocol (NP) which will be understood by the Link Service. An example of such translation could be a Microsoft Windows application using the DDE to communicate the OHP operations to the shim which translates them into TCP/IP communication which is understood by the Unix based link service. The Hypertext Protocol Shim is responsible for mapping the OHP messages send by the third party application to the specific operations of the Link Service not yet providing native support for OHP. Finally, the Link Service is both responsible for runtime resolving of links given some selection from an application and for creating, storing, and retrieving links from physical storage.

11 11 of 25 11/20/ :14 AM Figure 4. The Shim architecture (reprinted from [9] with permission). The strength of the Shim architecture is the fitting of different open hypermedia protocols to support reuse of third party application tailoring modules with many different OHSs. It does a nice job in this respect, and it does not attempt to cover the rest of the hypermedia system architecture for instance database interfaces and the like. An implementation of OHP shims for the existing OHSs would make a clear improvement of interoperability among OHSs and tailored applications. A weakness of the Shim architecture proposal is that it is limited in generality in the sense that it focuses closely on the fitting of different open hypermedia protocols. Moreover, a critical question may be raised to this approach: What are the long-term prospects of shims if the OHP is standardized? If all OHSs agree on the same OHP and the OHP becomes widely accepted, there is no need for the extra overhead involved in developing a Shim module and in translating from OHP to a proprietary protocol. The shim approach may however still be necessary in situations, where an OHS have to support many different carrier communication protocols such as TCP/IP, DDE and AppleEvent. In this situation the Shim may take responsibility for translating from the abstract OHP to the actual carrier communication protocol on a given platform. It may also be the case that an application or an OHS on one platform needs to use different carrier protocols at the same time, e.g., TCP/IP and DDE on Microsoft Windows. 3.4 The HyperDisco architecture The HyperDisco architecture (Figure 5) consists of three levels: tools consisting of both hypermedia tools and integrated third party applications, tool integrators and workspaces [41]. Tool integrators provide the hypermedia services to tools and act as session managers coordinating users' access to multiple workspaces. A workspace provides both hypermedia database and document management system services. These architectural elements may exist in many-to-many relationships and may be distributed on wide area or local area networks. Figure 5. The HyperDisco architecture. A recent experiment which integrated the Chimera server to operate as a HyperDisco workspace [44] made use of a so-called wrapper to integrate an external store (in this case the Chimera server) to interoperate with HyperDisco. Wrappers are small program modules that encapsulate external applications and stores into a module that behaves according to given protocols. Originally, wrappers were only used to integrate third party applications with the HyperDisco system, but the wrapper approach has proven to work for external stores as well. The results from the

12 12 of 25 11/20/ :14 AM experiment were generalized into a proposal for a general OHS architecture, which can be considered a specific instantiation of the HyperDisco architecture. Figure 6 shows this general OHS architecture in a scenario where an OHS supports integration of both external applications and external stores. The OHS consists of one or more native OHS Applications, one or more OHS Session Managers and one or more native OHS Stores. Figure 6. A general OHS architecture derived from the HyperDisco - Chimera interoperability experiment. The architecture is a specific instantiation of the HyperDisco architecture. Wrappers are used to enable external applications and external stores to conform to the OHS protocols. The OHS Session Manager is similar to the tool integrator. Thus, the OHS Session Manager provides hypermedia services to both external and native OHS applications. An OHS Application is an application that directly supports the OHS Presentation Protocol. Likewise, an OHS store is a store that directly supports the OHS Storage Protocol. The model in Figure 6 assumes that the OHS Session Manager is capable of using the standard Presentation Protocol and the standard Storage Protocol. This could be achieved by additional wrappers as in the Shim architecture (Section 3.3) or by adopting the OHS Session Manager to conform to the standards. The main strength of the proposed general OHS architecture is the introduction of a second open hypermedia protocol (the Storage Protocol) and a second type of wrapper (the Storage Wrapper) handling integration of external stores such as databases, file systems, and special-purpose storage managers. Thus, integration of third party stores is handled in the same manner as integration of third party applications. The result is a simple and general model with few protocols and few types of architectural elements. The HyperDisco architecture shares the weakness with the DHM architecture that it is not made explicit where the content is stored if not stored in the workspace by means of the hypermedia database. 3.5 The HOSS architecture N?rnberg et al. [31] present an approach to supporting hypermedia at the operating system level. This includes a layered architecture denoted HOSS (Hypermedia Operating System Services). The HOSS architecture is depicted in Figure 7; the boxes correspond to processes. HOSS does not name the layers explicitly, but layers map to similar layers in the HyperDisco and DHM architectures. The top level processes represent general applications and two types of specific hypermedia applications. The second level, the Sprocs (Structure Processes) represent the different hypermedia services provided in terms of the different structures being managed. The third level, the HBprocs

13 13 of 25 11/20/ :14 AM (HyperBase Processes) represents the storage of objects and associations. The lowest level represents the hosting operating system itself. Figure 7. The HOSS architecture (reprinted from [31] with permission). HOSS is a general conceptual architecture. The main strength of the HOSS architecture is the proposal for having multiple heterogeneous services (Sprocs) operating in parallel. The HOSS architecture thus proposes a broader spectrum of hypermedia services than just linking. Since the individual Sprocs provides different structures and services they also provide different protocols to the applications at the top level. A weakness in HOSS is that there is no distinction between structure and content storage. Since all HOSS objects are viewed as structural elements, the HOSS architecture specifies no explicit non-structural (content) storage. 3.6 Open hypermedia reference architecture (OHRA) Goose et al. [11] specify three areas that should be thoroughly investigated before a comprehensive reference architecture for future hypermedia systems can be defined: Specification of location specifiers. A reference architecture for OHSs. A vision of a globally distributed and collaborative model with a clear evolution path from existing OHSs

14 14 of 25 11/20/ :14 AM towards this goal. OHRA is primarily an attempt to address the third issue. OHRA provides a model that illustrates how different OHSs can be integrated in a manner, which allows them to interoperate in a distributed and collaborative working environment (see Figure 4 in the OHRA paper also in this special issue). OHRA introduces five components: viewer, runtime, link service, collaboration server and document management system and four protocols: viewer, collaborative, hypermedia and document management. The main strength of the OHRA proposal is that it sets focus on interoperability among OHSs. OHRA extends the view of OHSs to cover that the OHSs should themselves be open for integration. To facilitate such interoperability, OHRA introduces a distributed and collaborative model, which allows existing OHSs to interoperate at different levels using different protocols. A weakness of OHRA is, however, that it seems to be more appropriate for the link server type of OHSs, which have no (or limited) support for collaboration and document management per se. In contrast to most of the hypermedia systems supporting some notion of collaboration, such as KMS [1], Intermedia [37], HyperDisco [41], DHM [14], OHRA proposes a separate architectural element that has collaboration support as its only responsibility. It is not clear from the proposal how the division of labor would be among a hyperbase with collaboration support and the collaboration server. Although the authors explicitly mention that it is possible to integrate open hyperbase type systems, it is not clear how this type of system can interoperate with other OHSs using the OHRA model. The scenario provided in [11] does not deal with these matters. Another weakness of OHRA is that it is conceptually unclear what the distinctions between the different elements of the architecture are. Both the "Runtime" and "Link service" architectural elements appear in several different roles in the architecture (e.g., the Runtime in some situations covers entire systems including storage and in some situations its only a behavioral element in a system). This provides an argument to view OHRA as a proposal for implementing interoperability rather than as a reference architecture to be used for conceptual distinctions. 3.7 Summary of architecture analysis Table 1 summarizes the main strengths and weaknesses of the six candidate open hypermedia architectures and models analyzed in the previous sections. Strengths Weaknesses Flag DHM/Dexter Shim HyperDisco HOSS - emphasizes distinction between content and structure storage - supports mapping of different systems to conceptual layers - fits heterogeneous open hypermedia and communication protocols to each others - introduces an external storage protocol and storage wrappers - introduces the concept of multiple heterogeneous hypermedia services - not open for addition of new types of modules and interfaces - potential ambiguity in placing content storage in the architecture - limited scope - shims become obsolete when standardized OHP is agreed upon - same as DHM and HOSS - same as DHM and HyperDisco

15 15 of 25 11/20/ :14 AM OHRA - focus on interoperability among different open hypermedia systems - not a conceptual reference architecture - complicated model Table 1. Summary of strengths and weaknesses of the analyzed open hypermedia architectures and models. The analysis summarized in Table 1 can help identify the main weaknesses to overcome and the main strengths to build on. We propose to make a synthesis of the following aspects of the analyzed architectures: Define a general and simple conceptual layering (inspired by DHM/Dexter, HyperDisco and HOSS) Clarify the placement of content storage (inspired by the Flag model) Let the interfaces between architectural elements handle the heterogeneity of platforms and "on the wire" communication protocols (inspired by the Shim architecture) Provide support for multiple heterogeneous hypermedia services and structures (inspired by the HOSS architecture). We see these four guidelines as the conclusion from the analysis, and in Section 5 we present a proposal for a common reference architecture which fulfils these guidelines. Before presenting this proposal a similar analysis will be made of the terminology used in open hypermedia architectures and models in order to propose common terminology for open hypermedia architecture discussions. 4 Proposal for open hypermedia terminology A reference architecture should be based on a consistent terminology. Based on the previous analysis and an analysis of systems described in [3, 9, 14, 19, 20, 26, 31, 38, 41, 46], a great diversity in terminology is revealed. Currently the OHS community uses a rich variety of different terms for essentially the same elements of the architectures. In the following, a term for each architectural element is proposed and the different terms used in the literature for essentially the same architectural element are enumerated. The term Content Handler is proposed to describe the architectural elements of an OHS that supports viewing and editing of the actual data contents for the hypermedia structures. In the above systems and models content handlers are called: viewers, third party applications, participating applications, editors, applications, tools, metadata managers, hsh,... The term Hypermedia Service is proposed to denote the architectural element that handles the hypermedia structures at runtime. In the above systems and models this element is called: link service, runtime, tool integrator, session manager, hypermedia service, sproc,... The term Structure Database is proposed to denote the architectural element responsible for persistent storage of hypermedia structures. In the above systems and models this element is called: storage, link service, structure server, filter, OODB, HBMS, hyperbase, hyperbase system, workspace, data model manager, collaboration server, HBprocs, association set manager,... The term Interface is proposed to denote the connection between the hypermedia service and other architectural elements. In the above systems and models this is called: shim, protocol, wrapper, gateway, proxy, shell, communication translator,... To adopt a common reference architecture for open hypermedia, the open hypermedia community needs to agree on a consistent set of concepts, which provide a common understanding of the elements of the architecture. The choice of hypermedia data and process models such as Dexter and others should be orthogonal to the reference architecture.

16 16 of 25 11/20/ :14 AM Although the above terminology seems quite diverse, there is much commonality in the functionality of the different elements across existing OHSs. In fact, there seems to be no serious obstacle - based on the examined systems - to just choose and define a term corresponding to each of the above elements. The common concepts introduced above will be used in the proposed reference architecture described in the following section. 5 Proposal for a common reference architecture for open hypermedia This section presents a proposal for a Common Reference Architecture for open hypermedia (called CoReArc) as a synthesis of the important features of the examined architectures and reference models. The presentation will focus on the conceptual layers, architectural elements and interfaces of CoReArc. It will be explained how the four guidelines described in the "Summary of Architecture Analysis" (Section 3.7) have influenced the proposal. Moreover, a few examples of instantiations of the architecture are provided. 5.1 CoReArc conceptual layers CoReArc is a layered architecture in the line of DHM/Dexter, HyperDisco and HOSS (see Figure 8). Figure 8. A diagrammatic view of CoReArc. The decisions made regarding the number of layers, the naming of layers, and the division of labor between the layers is an attempt to take the best ideas of the six analyzed architectures and models. CoReArc provides three conceptual layers: The Content Layer covers the elements of the architecture that handles storage and retrieval of contents and editing and presentation of contents. The Service Layer covers the elements of the architecture that provides hypermedia services to architectural elements of the Content Layer. The Structure Layer covers the elements of the architecture that handles storage and retrieval of hypermedia structures. Especially the first and second guidelines of Section 3.7 have influenced the conceptual layers of CoReArc. The first guideline led to a general and simple three layer architecture. The second guideline led to a clear distinction between

17 17 of 25 11/20/ :14 AM storage of contents and storage of structure by having a Content Layer and a Structure Layer. 5.2 CoReArc architectural elements As shown in Figure 8, the central architectural element in CoReArc is the Hypermedia Service, which potentially can communicate with a number of architectural elements at all three layers through an open set of interfaces. The basic CoReArc diagram only depicts two other architectural elements (the Content Handler and the Structure Database and two interfaces connecting them to the Hypermedia Service (CHI and SDBI respectively). However, different instantiations of CoReArc will result in additional architectural elements and interfaces as illustrated in Section 5.4. We envision the following division of labor between the basic architectural elements. The Hypermedia Service provides one or more of the services described in Section 2.1: navigation, structuring, integration, collaboration and interoperability. (Distribution is a feature of the entire architecture allowing architectural elements to be duplicated and run in parallel on different machines.) The Hypermedia Service will rely on the functionality of the Structure Database to provide the navigation, structuring and collaboration services. Integration and interoperability services will reside solely in the Hypermedia Service and will allow Content Handlers and other architectural elements to access the navigation, structuring and collaboration services. To accommodate the fourth guideline of Section 3.7, many Hypermedia Service instances can run in parallel and provide different types of structuring, navigation and collaboration services to other architectural elements through an open set of interfaces. Content handlers are in principle arbitrary applications that (in most cases) are not designed to be hypermedia applications. In order for Content Handlers to participate in an OHS, they need to be tailorable and support extensions regarding communication to Hypermedia Service, user interface to invoke hypermedia operations, and access to locspec information for selections made in the contents being handled. 5.3 CoReArc conceptual interfaces Communication can take place in potentially many different places in the architecture. Communication interfaces are represented by a connection symbol between different architectural elements (lines with a double bar symbol on them). One could think of these interfaces as CORBA IDL interfaces. The interfaces represent peer-to-peer communication. This notation allows implementations either based on shims or interface modules in the architectural elements. Two main conceptual interfaces are proposed in CoReArc, the Content Handler Interface (CHI) and the Structure DataBase Interface (SDBI). New types of services are envisioned in the future, which will lead to additional conceptual interfaces. Thus, there are a couple of dashed double bars, which are currently not connected to any architectural element. Among the types of integration that are expected to require new conceptual interfaces are document management systems, agents, and other hypermedia services. Thus, we envision a number of additional conceptual interfaces that can be useful in different settings such as the Document Manager Interface (DMI), the Agent Interface (AI), and the Hypermedia Service Interoperability Interface (HSII). These conceptual interfaces will be examined in Section 5.4. One might object to the apparent complication of all of these conceptual interfaces, but the objective of this proposal is to make analytical distinctions between the different types of communications needed. The actual implementation of the conceptual interfaces should be similar to the idea of topics in DDE for Microsoft Windows or suites in Apples AppleEvent. The above conceptual interfaces may even themselves be divided into sub-suites, e.g., the CHI may have a core suite to handle linking and more advanced suites to handle composites [12, 18] and

18 18 of 25 11/20/ :14 AM collaboration. The conceptual interfaces can thus be folded into a single physical protocol with common methods for initialization, error handling, etc. Conceptual interfaces are logical definitions that may be communicated via many different kinds of on-the-wire protocols such as DDE, TCP/IP, CORBA, or Java RMI. A contribution from the Shim architecture is the proposal for having a specific module (the Shim) being responsible for translating between logical protocols and different types of on-the-wire protocols (the third guideline from Section 3.7). However, some of the standard component framework distribution mechanisms provide such protocol translations for free. Thus, it does not have to be a specific element in the hypermedia architecture. 5.4 CoReArc instantiations The architecture diagram presented in Figure 8 is abstract and has a number of open points for adding new types of interfaces for systems. Moreover, it does not explicitly show how collaboration, distribution and interoperability is handled. This section concretizes these aspects by instantiating the abstract architecture into scenarios with specific systems and specific architectural elements involved. Document Management System Integration A common kind of system to integrate with OHSs are standard document management systems such as Documentum and DocuPlex, which are used in many large enterprises to manage logical identification and access to documents [14, 20]. With our distinction between content and hypermedia structure, document management systems belong to the Content Layer (see Figure 9), since they manage only the documents that are structured by the hypermedia service. Figure 9. Scenario with standard document management system. Document management systems are different from typical viewer or editor types of content handlers, since they do not display or edit the content they only manage location independent identification, users' access and sometimes versioning of documents. We, thus, anticipate the specification of a new Document Management Interface (DMI), which contains operations to retrieve documents by Id, assign Ids to new documents, version existing documents, etc.

19 19 of 25 11/20/ :14 AM Agent Integration Agent technology [45] is becoming more common as means to filter information for users, e.g., on the Internet. Agents may learn from the user's search and browsing behavior and construct personal user profile structures that can be used to actively retrieve or filter relevant information for the user. Currently, agents are usually applied to textual contents or attributes assigned to contents. However, we foresee that agent technology will develop to search and filter based on the hypermedia structures themselves as well. Thus, we anticipate the specification of a new Agent Interface (AI). Moreover, we see agents as mainly a behavioral aspect of a hypermedia system and user profiles as a kind of structure, thus agents are placed at the Service Layer with their profiles at the Structure Layer (see Figure 10) Figure 10. Scenario with agents. The AI is different from both the CHI and the SDBI, since it is mainly handling aspects such as assigning weights to or filtering structures being browsed or searched. The common way of communicating with agents is through a standardized language called KQML [10], which determines a need for a special agent interface [22, 33]. Collaboration, Distribution and Interoperability Scenarios While it is easy to identify the specific architectural elements that handles integration, structuring and navigation services, distribution, interoperability and collaboration aspects are hard to express explicitly in a general architecture diagram. Interoperability is depicted implicitly in that each Hypermedia Service may communicate with other Hypermedia Services. The Hypermedia Service and Structure Database provide collaboration support, depending on the actual division of responsibilities among these two elements in a specific system. Distribution is depicted implicitly in that each Hypermedia Service may communicate with multiple Structure Databases and Content Handlers. Distribution, collaboration and interoperability is best illustrated by means of scenarios showing the actual configuration of instances of architectural elements in a specific use situation. Two different scenarios embodying CoReArc elements will be discussed.

20 20 of 25 11/20/ :14 AM Figure 11. Scenario for collaboration among users applying different Hypermedia Services. Figure 11 depicts a scenario with two Hypermedia Services. Hypermedia Service 1 (HS1) manages a single user and hypermedia Service 2 (HS2) manages two users. HS1 and HS2 are both currently accessing two distributed Structure Database processes - one of these is shared (SDB2). Applying the collaboration suites of the interface, this setting supports asynchronous collaboration on the shared structures stored in SDB2 among users a, b and c. The communication via HSII directly between HS1 and HS2 may be used to enter into mutual sessions [14] or tightly coupled modes [34] of collaboration between users of HS1 and HS2. Although this scenario does not describe an existing integration of systems, it would be a good description of an integration of DHM [14] (as HS1) and HyperDisco [41] (as HS2) where the SDBI has been standardized such that DHM hypermedia databases and HyperDisco workspaces can be accessed as a common distributed Structure Database system by both Hypermedia Services. Thus, CoReArc can be instantiated to illuminate both distribution, interoperability and collaboration aspects. Figure 12. Scenario with the same user applies different hypermedia services simultaneously.