A Vision for Open Hypermedia Systems Nürnberg and Leggett

7. Conclusions

Summary of the work. We presented synopses of four scenarios. Our analysis of these scenarios allowed us to derive four implications for the OHSWG reference architecture and protocol work. We concluded that open structural abstractions and semantically meaningful operations were required, reference architecture proposals designed to inform protocol work should exclude external entities, and that naming is a difficult and important issue for the group's work.

Next, we presented a reference architecture proposal based on previous proposals to the group and on our scenario analyses. The key differentiating features of our proposal are the exclusion of entities that do not interact with OHSWG servers and an open layer of link server peers called Sprocs.

We also discussed a proposal for an OHP protocol. In light of the open Sproc layer in our reference architecture proposal, we reconceptualized the OHP as a family of protocols, one per Sproc. This allows a finer-grained notion of OHSWG services. We abstracted purely syntactic issues (how to encode a message into a byte stream) from the issues central to particular Sprocs (what services to provide). Finally, we provided a proposal for the interface to a Sproc that handles simple navigation hypertext. We believe composition and IR Sproc interfaces should also receive attention in the short term from the group.

Finally, we made some comments on the method chosen by the OHSWG to accomplish its goals. We found the scenario based design approach worthwhile. We believe, however, that further architecture work should be decoupled from protocol work.

Observations. We feel that the work of the OHSWG can be characterized as the design of middle-ware for distributed open structure systems. As such, we are faced with the decision of how to proceed. Large-scale attempts by industry-led consortiums are designing and implementing similar middle-ware. CORBA [OMG 1997] and JavaBeans [JavaSoft 1997] are two such examples. Clearly, we want to avoid re-inventing the wheel. To what degree can we use the facilities of existing middle-ware projects? More importantly, what is the true value of OHSWG work when compared to these other projects?

We do not feel it is time to adopt CORBA or JavaBeans as our development platform, despite the similarities in the general aims of the projects. There are problems with these other projects that we will inherit if we adopt these standards. For example, CORBA is fairly heavy-weight and expensive. JavaBeans is still immature. The choice of which of these or other similar component frameworks to use, or whether to develop our own, should be a matter for discussion by the group.

In any event, there is still much to be learned from these projects. The conceptualization of the OHP not so much as a protocol but as a family of interfaces to distributed objects, beans, entities, Sprocs, or general servers is useful. There are many ideas we can borrow concerning issues such as naming, location services, and other important functionality. We should attempt to do only as much work as we need, building on existing applicable work when appropriate, and proposing new solutions when required.

Several existing OHS's provide general development tools for the construction of servers and clients. Oftentimes, however, these tools are not the focus of our academic papers or discussions about our systems. We should make a concerted effort to exchange information about these aspects of our work, considering the potentially large impact these tools could have on the group's work. For example, the HOSS Protocol Definition Compiler described in Section 5 can greatly reduce the time it takes to develop IPC libraries for different protocols. The group could choose to adopt this program as a starting point, concentrating on service definition instead of debating issues of encoding or building IPC libraries by hand. Other systems will have similar tools and methods that will make the group's work easier. We will likely find that after pooling the resources and experiences of the group membership, the design and implementation tasks before us will seem more manageable.

Future Work. The immediate term (1997) goals for the OHSWG should be to endorse a protocol specification for navigation services and a process by which the specification can be altered. Within the next 6-12 months, the group should also agree on specifications for composition and IR services.

There are many possibilities for interesting work in the longer term. We feel that the group should explore the possibility of defining service standards for spatial, taxonomic, literary, and other types of hypertext with their unique forms of structure. We should attempt to transfer this technology to the broader hypertext community as well. Standards concerning common locspec and pspec formats, common naming schemes, and other details not addressed in detail in this paper hold the promise of greater interoperability between the OHSWG representative systems.

Contents

Peter J. Nürnberg, John J. Leggett
HRL, CSDL, Texas A&M
original page URL: http://jodi.ecs.soton.ac.uk/Articles/v01/i02/Nurnberg/concl.html