Open Hypermedia Systems Working Group

Infrastructure area compendium

1997.10.30

3.0 Infrastructure

Infrastructure

The Infrastructure Area of the OHSWG is concerned with the overall architecture of an open hypermedia system and the generic services of a hypermedia backend. More specifically, infrastructure subgroups consider what kind of architectural support and services are common to (all) open hypermedia application domains.

Common Architectural Support

The goal of the architecture subtask is to develop a general architectural framework that can capture the use of open hypermedia systems in many different application domains. Currently, the following topics have been proposed for investigation:

• open hypermedia reference architecture
• open hypermedia system interoperability
• distribution of architectural components

Common Backend Services

The goal of the services subtask is to develop a general set of domain independent services in the hypermedia backend to be used in many different application domains. Currently, the following topics have been proposed for investigation:

• atomic abstractions (i.e., types of hypermedia objects)
• scripting services
• versioning support
• access control
• transaction support
• notification control
• concurrency control

One infrastructure subgroup was formed at OHS 3.5. This subgroup covers both Architecture and Services. The future plan is to split into several smaller subgroups each focusing on a few issues.

3.1 Architecture and services

The mailing list for this group is called ohs-arch-svcs. To subscribe, mail a message to listproc@csdl.tamu.edu with a message body "sub ohs-arch-svcs <your-name>". Once you are subscribed, you can post to this list by mailing your post to ohs-arch-svcs@csdl.tamu.edu.

Available here is the hypermail archive ordered by thread; date; subject; or, author.

Architecture and Services

As mentioned in the OHSWG Historical Overview a number of decisions were made that directly affected the work in the architecture and services subgroup. This page gives a short overview of the consensus that was reached at OHS 3.5 regarding architecture and services. Figure 1 depicts the specific architecture that was used in the discussions at OHS 3.5.

The architecture defines three layers of functionality:

• The Backend Layer consisting of the Hypermedia Backend, which handles storage and provides the necessary backend services to various Structure Servers.
• The Middleware Layer consisting of an open set of open hypermedia middleware components (Structure Servers) providing different structure services to client applications (Clients).
• The Client Layer consisting of various hypermedia client applications capable of presenting and editing contents and structure.

In addition, the architecture defines two (sets of) interfaces:

• Structure Servers provide different Client Interfaces. One Structure Server could provide a spatial hypertext interface, while another Structure Server could provide a navigational (associative) hypertext interface. The focus at OHS 3.5 was the definition of the navigational interface. Other structure server interfaces will be defined in the future. The Client Interfaces will be based on some component framework (e.g., Java Beans, CORBA or DCOM).
• Structure Servers share one common interface to the Hypermedia Backend, the Backend Interface. Although, this interface was not the focus of the discussions at OHS 3.5, the OHSWG group members felt that future work should define a common Backend Interface. The Backend Interface defines the services of the Hypermedia Backend (i.e., what atomic abstractions are served, what scripting services are available, and what types of versioning support, access control, transaction support, notification control and concurrency control are available).

The architectural diagram in Figure 1 can be interpreted in the following manner. One logical Hypermedia Backend (consisting of several physical server processes) is being shared by three open hypermedia middleware components:

• Structure Server #1 is a spatial hypertext component serving a spatial hypertext model to Client #1 and Client #2. Both clients have been fully integrated and can communicate directly with the spatial hypertext component.
• Structure Server #2 is a navigational hypertext component serving a navigational (associative) hypertext model to Client #3 and Client #4. These clients have not been fully integrated with the navigational component and rely on the services of a hypermedia user interface component to participate in the navigational hypertext service. However, as indicated in the diagram, Client #3 can communicate some requests directly to the navigational hypertext component. A hypermedia user interface component can potentially assist clients in many different ways, e.g., by starting up new clients on the user's machine to display a link endpoint, by providing hypertext user interface services that the client cannot provide itself, or by translating the native communication protocol of the client (e.g., OLE) to the native communication protocol of the navigational hypertext component framework (e.g., CORBA).
• Structure server #3 is a taxonomic hypertext component serving a taxonomic hypertext model to Client #5 and Client #6, which are different kinds of WWW browsers. An applet assists the WWW browsers in much the same way as the hypermedia user interface component assists Client #3 and Client #4.