OHRA: Towards an Open Hypermedia Reference Architecture and a Migration Path for Existing Systems

Stuart Goose

Multimedia and Video Technology Group Siemens Corporate Research Inc. Princeton, NJ, USA sgoose@scr.siemens.com

Multimedia Research Group Department of Electronics and Computer Science University of Southampton UK {ajl, hcd}@ecs.soton.ac.uk

Abstract

The open hypermedia research community recognised that to make progress on defining a protocol to enable third party applications to access open link services, it was necessary to first establish a reference architecture for open hypermedia systems upon which to base discussions. In this paper we argue that there is a need to extend yet further the scope of these requirements. We propose an overall architecture for the integration of existing open hypermedia systems in a distributed and collaborative model, and provide a clear evolution path towards achieving this goal.

1. Introduction

Since 1987, there has been a significant shift towards increasingly open hypermedia systems. Interest in this specific area of hypermedia research inspired a succession of workshops which were staged in Konstanz [2], Edinburgh (OHS 1) [28], Washington D.C. (OHS 2) [27], Southampton (OHS 2.5, 3) [6, 25], and Aarhus (OHS 3.5) [26]. As with any active field of research it can prove difficult to reach a conclusive definition for a given term, but the six point definition of open hypermedia, as espoused by Davis et al [8], is considered to embody the consensus of opinion of the OHS community.

A small working group, co-ordinated by Davis, began work on establishing a protocol for open hypermedia systems (OHS). The initial aim of this protocol was to enable third party applications to access open hypermedia link service functionality in a consistent and standard manner. The first draft of the open hypermedia protocol (OHP) specification [8] appeared as a position paper at the OHS 2 workshop. It was generally acknowledged by the workshop attendees that the field was sufficiently mature for a standard to be defined, and as such the OHP initiative was launched.

At the OHS 2.5 workshop [6] the attendees continued discussions on both the OHP and practical scenarios. The group recognised that it was proving increasingly difficult to make progress on defining OHP without first establishing a reference architecture for open hypermedia systems upon which to base discussions. To date two reference models have been described in the literature. The Dexter Model [15] attempts to provide a standard hypermedia terminology coupled with a formal model of the common abstractions found within contemporary hypermedia systems. A three layer conceptual data model is presented without any suggestion of an architecture for realising the model. The Flag Taxonomy [20] attempts to capture the functionality and interaction of hypermedia systems in such a manner as to aid classification. Although some dissent exists in the research community as to whether Dexter is the appropriate reference model for hypermedia, it provides a principled basis upon which these discussions can take place. The authors of the Flag Taxonomy provide a parallel reference model for open hypermedia.

To establish an inclusive reference architecture for future open hypermedia systems we firmly believe that the following areas need to be satisfactorily addressed:

agreement upon an open specification for location specifiers (LocSpecs) [13].
a reference architecture for an open hypermedia system.
a vision of a globally distributed and collaborative model with a clear evolution path toward this goal.

Preliminary work by Reich [21] and Rutledge et al [23] propose solutions for addressing the first issue of open location specifications. Grønbæk et al [14] provide an initial attempt at the second issue, a reference architecture for an open hypermedia system. They propose a synthesis architecture based around the conceptual layers of the Dexter Model and introduce three protocols for integrating with external entities.

In this paper we address primarily the final objective listed above, and present a model which illustrates how differing open hypermedia systems can be integrated in a manner which provides a powerful, distributed and collaborative architecture. By sub-dividing OHP into four distinct protocols for communication between four core components, hypermedia systems can buy into the reference architecture at the required level, hence providing a migration path.

2. A Protocol Alone is Insufficient

Most systems designers have developed their own proprietary protocols for communicating with their link server, and these protocols are so deeply buried into the system code that in general it would involve a major re-implementation to rewrite the system to adhere to some new, standard protocol. However, the topics of these communications are essentially similar and it should be quite possible to abstract a common set of messages. To alleviate this problem Davis et al [8] suggested that the difference between different system protocols could be resolved if each system produced a protocol shim which would reside between the application and the link server. This solution can be seen in figure 1. Anderson [1] offers a critique of OHP and makes pragmatic recommendations for improving both syntax and semantics.

During discussions on OHP at the OHS 2.5 workshop, it soon became apparent that this solution would prove inadequate. Although the protocol shim would enable third party applications to access a link server residing on a remote machine, the rich set of tools (e.g. navigation) that accompany most contemporary hypermedia systems would no longer be available within the user's environment. One solution is for the user to run an X windows server on their machine and thus allow the display of the link service tools to be redirected to their own screen. This is only a partial solution as similar facilities are not available for Microsoft Windows or Macintosh environments that enable applications to have their display redirected to remote machines. It is clear that this is not a problem if the link server(s) being accessed is executing on the user's machine, but a preferable solution would not be limited by such a constraint.

Figure 1: The original OHP architecture

Much research has been conducted and many tools developed to assist with hypermedia authoring [18, 5], the location of relevant documents using content-based retrieval [17, 10] and the subsequent navigation of such resources [4, 9]. The aim of the OHP initiative is to enrich the user's environment by integrating third party applications with existing link services, not to reduce the effectiveness of link services by rendering the functionality of these associated tools inaccessible to the end user. To overcome this deficiency there was general agreement that some form of runtime on the user's machine was necessary, extending the original model to that shown in figure 2. The form and functionality of the runtime was not decided, but one possible approach would be to use a Java virtual machine [11] and develop a framework to allow additional tools and functionality to be dynamically downloaded to the user's machine. It is envisaged that the protocol shim functionality will be incorporated within the runtime component.

Figure 2: Incorporating a client runtime component

Although not a pre-requisite for open hypermedia, the capability of supporting collaborative work was thought by the working group to be of key importance. The group therefore decided that a reference model should not preclude such functionality from being incorporated at a future date. A further requirement identified by the group as being of importance was that of multimedia document/object management. A myriad of both commercial and academic solutions exist for the management of documents and, as such, the reference model needs to be open enough to allow developers to utilise any third party product. Although the exact functionality of each component and the protocols required to connect them were left undefined, it was concluded at the December meeting that the somewhat nebulous model shown in figure 3 would be useful in providing direction for the OHP initiative.

Figure 3: Preliminary reference architecture

It can be seen from this that the initial aims of OHP were too limited in scope, and that for this initiative to encompass and enhance both current and future developments in the field of hypermedia, it was necessary to consider a far more advanced and flexible model.

3. Why Re-invent The Runtime?

A runtime component will act as a mediator between the viewers and the desired link server(s), but, as argued earlier, a minimal implementation would be less than satisfactory for most users. We have identified three distinct approaches to providing a runtime component able to offer the rich set of presentation, authoring, navigation and hypermedia link service tools that accompany many contemporary systems.

3.1. Fresh Runtime Implementation

One solution is to implement the runtime and the entire range of client-side hypermedia tools from scratch. This approach obviously signifies a complete re-invention of the wheel and would, in our opinion, involve an unreasonable amount of effort. The resultant runtime would be, to some degree, platform dependent but only one implementation would be required per platform. Although this approach is unappealing, one significant advantage would be that a consistent user interface could be provided across the platforms, as has been achieved by Netscape, for example.

3.2. Virtual Machine Approach

An alternative approach would be to use a virtual machine, thus allowing a minimal runtime component to be implemented in a byte-code interpreted language, such as Java [11]. This has the advantage of being extremely versatile as the associated client-side hypermedia tools can be dynamically downloaded from the link server and executed locally. In addition to this, the user can incorporate any custom written tools with the runtime to supplement those provided by the link server.

Although this approach offers great flexibility and the potential for a zero administration client, each link server must assume that the runtime component has no local hypermedia tools of its own and should therefore offer to provide them. This again, demands a complete re-invention of the wheel, not once for each platform as with the first approach, but once for each different link server. As each different link server will supply its own client-side hypermedia tools the problem of interface inconsistency is exacerbated. An additional penalty will also be incurred each time a new tool is dynamically downloaded prior to usage.

3.3. Reusing Existing Hypermedia Systems as Runtimes

A third alternative is to allow any existing hypermedia system to be used as the runtime component. This strategy promotes the wholesale re-use of existing and familiar client-side hypermedia tools, which is an attractive proposition. This approach is also sufficiently open to integrate with and combine the previous two approaches. This would allow both the developer and user complete freedom over their choice of runtime, which by adopting this approach would be their favoured open hypermedia system.

Rather than dictating that each runtime or link server must conform to a rigid specification, this approach is designed to accommodate their differences and allow them to co-exist. Additionally, this approach would allow a hypermedia system with its own set of proprietary viewers to utilise third party remote link service(s). A full definition of the essential components and protocols is required to achieve this.

Allowing a hypermedia system to act as a runtime component within the model means that the hypermedia system can augment locally provided link services with those of a remote link service(s). Interestingly, if a runtime is represented by a hypermedia system with a link service, then there is no reason why the runtime cannot also act as a link service. Conversely, if a link service is represented by a hypermedia system, then there is no reason why the link service cannot also act as a runtime. This blurs the distinction between the two entities as a client runtime can masquerade as a link server and a link server can masquerade as a client runtime. It is by virtue of their dual roles that greater scope for configuration is possible.

The authors strongly advocate this approach as it is the most pragmatic of the three suggestions outlined in this section. This approach appeals to common sense as there exists little reason for discarding years of development when it can be exploited within the model.

4. Expressing Location Specifiers

A crucial part of the OHP [8] was the Location Specifier, or LocSpec [13]. The original design of an OHP LocSpec was reviewed at the OHS 2.5 workshop [6], with the participants universally agreed that it was insufficient for the needs of many hypermedia systems and hence required improvement. Although too detailed a topic to be rigorously addressed here, the reader is referred to Reich [21] and Rutledge et al [23] for a comprehensive treatment of these issues. An archived discussion list contains the most recent arguments and proposals by active members of the open hypermedia research community regarding the specification of LocSpecs. The authors feel that if the approach advocated in this paper is to work effectively then it is imperative that the final definition for a LocSpec be sufficiently open and versatile. Ideally, LocSpecs should be able to represent any anchor types used in any hypermedia system, past present or future. This is a difficult, perhaps impossible goal, but a challenging research topic.

One approach to provide open and versatile LocSpecs would be to adopt a similar technique used by Apple for the Macintosh inter-application communication system. A LocSpec would consist of a set of named, typed fields, each able to contain any form of data. There would be no compulsory fields, but instead an expandable published standard defining "sets" of fields and how they are to be used. As an example, one set may be for the representation of text, and may define fields which contain the text itself, character offset, length, paragraph and word offset, preceding characters, anteceding characters, etc. Another set would be defined to give document specifications. Sets may complement each other, or may contain the same information in different forms. Components receiving a LocSpec would look for their preferred fields first, but may then fall back on more basic forms if those were absent. This would be a highly versatile approach, but careful attention would need to be paid in defining the initial sets and in establishing a mechanism for people to publish their own. This is an area requiring further discussion.

5. An Open Hypermedia Reference Architecture (OHRA)

It has been discussed in previous sections how the OHP initiative has driven the need for a well defined and open architecture while retaining the rich hypermedia environments to which users have become accustomed. Using the model in figure 3 as a starting point, we examine the protocols required to connect the components and then present a reference architecture for open hypermedia. We then review the individual components and discuss their role within the architecture.

5.1. The OHRA Suite of Protocols

Having identified the key components for a reference architecture in figure 3, it is necessary to focus attention on the interfaces that connect them. Rather than having a single, complex protocol that defines the interaction between every component, a more modular approach is to define a protocol which encapsulates the service(s) offered by each architectural component. Another advantage to sub-dividing the protocol is that it allows the developers of each component to have the choice as to which aspects of the reference architecture they wish to adopt. The authors have identified four distinct, but related, protocols. The following sections briefly outline the pattern of interaction that each of the protocols will define.

5.1.1. The Viewer Protocol

This protocol has an almost identical purpose to that of the original OHP [8] in that it will enable third party applications to communicate with the runtime component. Additional issues that need to be addressed are:

ratification of the way in which viewers can determine the hypermedia and collaboration services available.
the adoption of a sufficiently open and versatile specification of location specifiers (see section 4).

5.1.2. The Hypermedia Protocol

This protocol will provide an interface for communicating with a link server. This could, for example, take the form of a runtime component making requests to a link service, or one link service making a request to another. Outstanding issues include:

ratification of the way in which link servers advertise the services they offer.
the adoption of a sufficiently versatile specification of location specifiers.
provision of locking for hypermedia objects.

5.1.3. The Collaboration Service Protocol

Although systems such as DHM [12], HyperDisco [29], SP3 [16] and Sepia [24] provide extensive support for collaboration among users, many still do not. By incorporating an additional component, the Collaboration Server, it is hoped that many of the common services necessary to support collaborative working practices can be provided. The role of the Collaboration Server is expanded upon later in this section. Important issues include:

support for tight and loose modes of collaboration.
interaction with Document Management System to provide object locking.
event notification subscription/unsubscription and delivery.
interaction with Link Service and Document Management System to support versioning.

5.1.4. The Document Management Service Protocol

Over recent years standards have begun to emerge to satisfy the requirement for a consistent interface to commercial document management systems. One such initiative is the Open Document Management API (ODMA) [19] promulgated by the Association of Information and Image Management (AIIM). The aim of this standard is to define a common interface to commercial document management systems and thus promote interoperability. This standard also addresses key issues such as heterogeneity, unique and portable document identifiers etc.

As an initial step, initiatives such as ODMA require investigation to examine and question whether or not they are sufficiently rich to support the activities required to deliver open hypermedia. Such an effort is already underway. For example, the ODMA standard has no mention of support for the streaming of multimedia objects. Although DHM [12], HyperDisco [29] and SP3 [16] provide proprietary solutions for document management and version control, further research is necessary to determine the minimum requirements of a document management system for open hypermedia and hence define a standard interface to third party products. Key issues to resolve include:

globally unique and portable document naming scheme.
add, remove, modify documents.
document retrieval.
support for versioning.
document locking.

5.2. The OHRA Components

We used as a foundation the nebulous model (shown in figure 3) from the OHS 2.5 workshop [6] and developed a more mature version. The new model in figure 4 illustrates how the four core components can be connected by the four new protocols introduced earlier in this section. From figure 4, we also show the way in which an existing hypermedia system can serve as a runtime and a link service component within this model, as indicated in section 3. In the following sections we discuss how we see each of the core components fitting into the reference architecture.

Figure 4: The OHRA components

5.2.1. Viewer

Any third party application that respects the Viewer Protocol is able to participate as a viewer in this architecture. This could be a specially modified hypermedia viewer which had been written for an existing system, a third party application with the necessary modifications (e.g. Microsoft Word with custom written macros), or a viewer explicitly developed to be Viewer Protocol compliant. If there is a requirement for multimedia viewers to render in real time streamed continuous media from external document management systems, it is also necessary to support the Document Management Protocol.

5.2.2. Runtime Component

The runtime component can be realised in a number of ways, several of which were enumerated in section 3. A runtime may range from a Java virtual machine with no inherent hypermedia facilities through to a fully fledged open hypermedia system. The minimum requirement of a OHRA runtime is that it must support the Viewer Protocol, if third party viewers are employed. If access to remote link services are required then the Hypermedia Protocol must also be supported, but to take full advantage of the architecture a runtime should support the entire protocol suite.

Provision must also be made for a mechanism with which a user can select and connect to one or more link servers and collaboration servers. While connected to multiple link and collaboration servers an additional mechanism must be in place for specifying which particular server(s) a request is intended for.

5.2.3. Link Service

The sole requirement for a link service to participate in this architecture is that the Hypermedia Service Protocol must be supported. If the link service is to indulge collaborative hypermedia activities then it must cater for the Collaboration Protocol. For users to create versioned links to documents residing on external document management systems, it is also necessary for the link service to support the Document Management Protocol.

5.2.4. Collaboration Server

The Collaboration Server supplants the Session Manager component in figure 3. It exists to advertise and maintain collaborative workspaces and to provide a range of collaboration services to users. It is by no means mandatory for any component in the architecture to support the Collaboration Protocol, but it has been included to support those entities that require such services. The main advantage of divorcing the Hypermedia Protocol from the Collaboration Protocol is to give the developers of runtime and link server components a choice as to whether or not they wish to provide support for collaborative activities.

We envisage that a user would connect to one or more Collaboration Servers to create and/or select group workspaces in which to operate. These workspaces would allow multiple users to rendezvous and collaborate over multiple link servers and document management systems. Collaboration services could be offered to the user through an additional menu available on the viewer (as with DHM), or in some other fashion consistent with the way in which link services are offered.

It may be the case that support for collaboration in contemporary hypermedia systems is buried in the many layers of the architecture. From figure 4, it may appear that we are advocating the development of a brand new module responsible only for collaboration, but there is no reason why an existing collaborative hypermedia system cannot be adapted to comply with OHRA. All that is required is for the system to expose the appropriate functionality and adhere to the Collaboration Protocol. A partial tailoring would allow runtime components to collaborate only upon its link server, whereas a complete tailoring would allow runtime components to use its collaboration services across a variety of independent link servers.

Preliminary research has been conducted by Wiil and Whitehead [30] which examines the interoperability issues involved when connecting two open hypermedia systems that each offer collaboration support. The results are promising, but demonstrate that this is a complex requirement and further work is necessary in order to generalise these early findings.

5.2.5. Document Management System

Although the role of a document management system is well understood, the best way of providing an open suite of services for use in a networked environment has yet to be agreed upon. Many hypermedia systems have their own proprietary document management systems. Microcosm [7] has a Document Management System (DMS), while DHM, HyperDisco and SP3 provide additional hyperbase functionality for managing documents.

As with the Collaboration Server, there is no reason why the proprietary document management systems that accompany most open hypermedia systems cannot be adapted to comply with OHRA. Again, it requires the developers to expose the appropriate functionality and adhere to the Document Management Protocol.

6. OHRA Interoperability Scenario

In figure 5 we seek to demonstrate the way in which contemporary open hypermedia systems could be mapped to OHRA.

Figure 5: Illustrating integration with OHRA

6.1. Runtime Layers

6.1.1. Microcosm

This is a full Microcosm hypermedia application in its own right, with its own proprietary linkbases, documents and viewers. It is fully OHRA compliant, and as such supports the Viewer, Hypermedia, Collaboration and Document Management Protocols. It is thus able to use Viewer Protocol enabled third party viewers in addition to its own. The diagram shows that it is making use of enabled World Wide Web (WWW) [3] and Microsoft Word viewers as well as its proprietary video viewer. Through the Hypermedia Protocol, Microcosm can access the Multicard Link Service [22] and the services available in the DHM session. In addition, Microcosm advertises its own link querying, navigational and creation services to the other runtime components, which in this case are the DHM and the Virtual Machine Runtime (a). Via the Collaboration Server and the Collaboration Protocol a joint session with the Virtual Machine Runtime (a) and the DHM session can be held.

Microcosm can also use external data management systems to obtain data and documents not immediately available to it by supporting the Document Management Protocol. In this case, it can access both Documentum and the Internet Gateway. The former is an example of a commercial document storage and retrieval system, and the latter can interface with multiple Internet resources on behalf of a client.

6.1.2. DHM

The DHM session has a similar role to that of Microcosm. In this case DHM is interacting with two viewers: a Viewer Protocol aware version of Microsoft Word and a proprietary image viewer. In addition, it is connected to the HyperDisco Link Service but not via a Collaboration Server. Only the Hypermedia Protocol is required to support this activity.

6.1.3. Virtual Machine Runtime

Two Virtual Machine runtime components are show in figure 5. Virtual Machine (a) runtime is connected to two viewers: a WWW viewer and a standard text viewer. As it supports the Viewer, Hypermedia, Collaboration and Document Management Protocols, this runtime is able to maintain collaborative sessions with Microcosm and DHM and access the Microcosm, DHM and Multicard link services. Virtual Machine (b) runtime is interacting with a Microsoft Word viewer and is connected solely to the HyperDisco link service in a non-collaborative fashion. A runtime component in this position need only support the Viewer Protocol and the Hypermedia Protocol.

6.2. Link Servers

6.2.1. Multicard Link Service

Acting purely as a link server, the Multicard Link Service supports the Hypermedia Protocol, and as such, may advertise a set of creation and querying services which can be made use of by the Microcosm, DHM and Virtual Machine (a) runtime components. In addition, the Multicard Link Service supports the Collaboration Protocol allowing the Collaboration Server to request locks on link and document records etc. It also supports the Document Management Protocol allowing it to query documents external to it (in this example, through an Internet Gateway).

6.2.2. HyperDisco

In figure 5 the HyperDisco Link Service supports the Hypermedia Protocol and provides these services to the DHM and Virtual Machine (b) runtime components.

6.3. Collaboration Server

The Collaborative Server in figure 5 manages the collaborative sessions currently active between the Microcosm, DHM and Virtual Machine (a) runtime components and the Multicard Link Server. In addition to managing these sessions, the Collaboration Server negotiates locking requests with the respective component(s), and forwards event notification messages onto users and groups of users.

6.4. Document Management Systems

6.4.1. Documentum

This represents a version of a commercial document management system that is Document Management Protocol enabled. On request such a version will provide storage, retrieval, modification and document locking services.

6.4.2. Internet Gateway

A useful additional component would be a multi-protocol internet gateway process that could masquerade as a Document Management System to OHRA components. Such a process might resolves URLs on request, or download and forward the relevant documents from their servers on request. In simple terms, if an OHRA component requires a document from an Internet resource such as the WWW, a gateway process such as this can fulfil the request.

7. Conclusion

This paper sets out to provide a reference architecture for the integration of differing open hypermedia systems in a powerful, distributed and collaborative framework. Three alternative strategies for achieving this end are described. The strategy favoured by the authors accommodates the two alternative approaches, but aims to reduce the amount of work required for compliance by advocating the entire reuse of existing open hypermedia systems. This allows users to continue to enjoy the rich functionality of existing and familiar client-side hypermedia tools available within their chosen hypermedia system, while providing access to distributed link services and document management systems through an optional collaboration service.

The authors took the stance that rather than enforcing each runtime or link service wishing to participate to conform to a given specification, it would be preferable to accommodate the differences and allow them to co-exist. In this paper we have merely sought to identify the essential components and the associated protocols required for this philosophy to be realised. Without a clear agreement on the second objective listed above this may prove difficult as not all systems will be able to support all concepts and facilities resident in other systems.

Although the Open Hypermedia Systems research community has reached general agreement on the core responsibilities of each of the components of the architecture outlined in the paper, it is clear that further discussion would be necessary for these to be ratified. Without prior agreement upon the clear roles of the architectural components, a unilateral attempt at defining any of the four protocols identified by the authors would be non-productive, and as such these remain undefined. We now look to the wider research community for support and detailed discussion on refinements to the reference architecture and how it can be transformed into a framework for the global integration of open hypermedia systems. If a reference architecture can help guide the way towards the global integration of open hypermedia systems, then the research community can look forward to exploring emerging technologies, such as CORBA and mobile autonomous agents, and their potential for easing the non-trivial task of distributed information management.