Open Hypermedia Systems Working Group

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.