HyperDisco: An Object-Oriented Hypermedia Framework
for Flexible Software System Integration
Ue Kock Wiil
Dept. of Computer Science, Aalborg University
Fr. Bajers Vej 7E, 9220 Aalborg , Denmark
Email: [email protected]
Abstract
Software development environments are examples of complex computer applications characterized by het-erogeneity; they are composed of diverse information repositories, user interfaces, services and tools. This paper presents an approach for providing hypermedia linking services as a means for integration in these heterogeneous settings. The overall goal of the Hyper-Disco project is to provide a hypermedia framework for exible software system integration. The basic idea in this approach is to allow dierent tools to be inte-grated in the hypermedia framework at dierent tool-dependent levels. Instead of providing a single model of integration that all tools must adhere to, we allow each tool to have its own specialized model of inte-gration and its own specialized protocol for accessing the hypermedia services. This paper describes the ap-proach (focusing on integration and modeling aspects) and presents a prototype which supports it. Prelimi-nary experience with the HyperDisco prototype and its relationship to other systems is described.
Keywords: Hypermedia framework, linking
ser-vices, software development environments, software system integration, modeling, openness, extensibility, rapid prototyping.
1 Introduction
Software development environments (SDEs) are ex-amples of complex software systems that are used to develop, maintain and display a diverse collection of highly interrelated artifacts [1, 13]. Artifacts in a SDE may, for example, include multiple versions of require-ments specications, designs, prototypes, code, test information, scripts, documentation, etc. The con-nections between these software artifacts are many and complex. Establishing and exploring these con-nections are major tasks of development, program un-derstanding and maintenance.
It has been suggested and demonstrated that hy-permedia [4] is an excellent technology for capturing, sharing, visualizing and navigating relations in com-plex software systems [2, 3, 5, 7, 8]. Providing hyper-media facilities in a SDE allows a software engineer to freely associate artifacts without regard to the type of those artifacts or where they are stored. These rela-tionships can then be accessed at a later time through a convenient user interface which allows the software
engineer to easily navigate them. While some excel-lent work has taken place in this area [10, 17, 18, 21], no single system to date has eectively addressed all the technical challenges posed by these heterogeneous settings. We believe that the following characteris-tics are among the most important for a hypermedia framework for exible software system integration [1, 14, 15, 16, 25].
Multiuser, scalability, distribution and heterogene-ity. Complex software systems are characterized by many users and tools distributed across dierent ma-chines connected through a computer network. There-fore, the hypermedia framework should be able to ef-fectively handle: (1) a large number of simultaneous users and tools, (2) a large amount of storage in terms of bytes and artifacts, (3) users, tools and processes distributed across machines in a network, and (4) het-erogeneity in terms of multiple hardware platforms, programming languages, networking protocols, data models and information repositories.
Openness and extensibility. Complex software sys-tems contain a wide variety of tools. Dierent kinds of editors and viewers are used for dierent types of artifacts. It is unlikely that users will give up their favorite tools in exchange for hypermedia functional-ity [1, 6, 9, 16]. Therefore, the hypermedia framework should be open (based on published, well-dened in-terfaces and protocols) to allow both new and existing tools to be integrated. The capabilities of a software system must constantly grow and expand. It should be possible to extend the software system (and the hy-permedia framework) to absorb new tools and ideas as the technology improves, for example, to handle a new type of artifact in the system.
Interoperability and collaboration. The tools and capabilities of a software system cannot stand in paral-lel isolation and ignorance of each other. Rather, they must be able to readily share data and results with each other. Their progress must aect, and be aected by, each other's activities. Some software systems sup-port collaboration among a group of users working on a common task. The hypermedia framework should support both interoperability among tools and collab-oration among users. Ideally all editors and viewers in a software system should be able to use hypermedia services and respond to hypermedia events.
systems, performance is of great importance in com-plex software systems. Users will expect rapid re-sponse to requests for services that they regard as straightforward, and can be expected to be impatient for response, even to requests for services that they know to entail considerable processing. Thus, the hy-permedia framework should not add considerable pro-cessing overhead to operations of the software system and should make eective use of hardware resources such as disk space, CPU time and network capacity.
Easy to use. If a hypermedia framework is to sup-port users, then it most not itself become an obstacle. Users must nd it easy to understand what capabilities the framework oers, and how to use them eectively. A typical user of the hypermedia framework is a soft-ware engineer or some other highly skilled computer literate.The above description of overall characteristics out-lines a set of more specic technical requirements for a hypermedia framework for exible software system integration. This paper describes a set of concepts which satisfy the set of requirements, and a proto-type which implements the described concepts. We focus on integration and modeling aspects of the hy-permedia framework. Other important facilities such as support for collaborative work groups and multiple versions of shared artifacts will not be presented in this paper. Instead, we refer to [23] for details on how HyperDisco can be used to address these issues. The remainder of the paper is organized as follows. The next three sections present the concepts, a prototype implementation of the concepts in an object-oriented hypermedia framework, and preliminary experiences with the prototype. We then conclude and describe our future plans.
2 Concepts
The overall goal of the HyperDisco project is to provide a hypermedia framework for exible software system integration. Given the overall goal of the eort, we believe that the following concepts can help achieve the goal.
2.1 Layered Hypermedia Framework
The hypermedia framework consists of two distinct layers as depicted in Figure 1. The data model (stor-age) layer provides tool independent services. The in-tegration model (runtime) layer provides tool depen-dent services. By separating tool independepen-dent services from tool dependent services, we allow dierent inte-gration models to share the same basic data model.
Both the integration model and the data model layer provides a set of general-purpose built-in ser-vices (a library of reusable object-oriented software routines). In the data model layer, the built-in classes provide tool independent hypermedia storage services such as storage and retrieval of hypermedia objects (e.g., nodes, links and anchors). In the integration model layer, the built-in classes provide a basic hy-permedia integration model including a exible com-munication protocol. These classes can be extended and tailored using multiple inheritance to provide spe-cialized integration and storage support for individual tools.
Data model layer Integration model layer
Basic classes
Hypermedia Framework
Basic classes
Data model classes Integration model classes
Figure 1: The layered hypermedia framework. Inte-gration support for participating tools is provided in the integration model layer and storage support is pro-vided in the data model layer inheriting from the basic classes.
2.2 Data Model Layer
The hypermedia framework provides an extensible object-oriented data model with a set of general hyper-media object types: Anchor, Node, Link and Compos-ite (Figure 2). New (sub)types can be added to match specic storage requirements of participating tools. In this way, participating tools can extend and tailor the data model by adding new messages and specializing existing messages.
All instances of the data model (anchors, links, nodes and composites) have a unique object identi-er (OID). Anchors (inspired by Dextidenti-er [9, 11, 14]) simply contain a value that species some location, region, item, or substructure within a component. If the anchor value is empty, the anchor refers to an en-tire component. The smallest sharable unit in the model is an attribute. Components are collections of attributes. Some attributes are always present in components and additional attributes can be attached dynamically. Default component attributes are a list of anchor OIDs and additional information such as owner, time created and last updated. Components and anchors can have attached scripts. Scripts are a way of extending the behavior of instances [20].
The data model supports a node subtype for each media type (text, graphics, video, voice, etc.) sup-ported by the framework. For instance, the text node subtype provides specic operations to deal with tex-tual artifacts. Adding a new media type to the plat-form involves the creation of a node subtype and spec-ication of at least one editor / viewer tool that can display the media type. To allow integration of mono-lithic tools, nodes can be used as data wrappers [9] or
Object Concurrency Control Notification Control Query & Search Access Control Component Basic classes Anchor
Node Composite Link
Version Control
Data model classes
Figure 2: Built-in data model classes. The Component class inherits facilities from ve basic classes: Concur-rency Control, Notication Control, Version Control, Access Control and Query & Search. The Anchor class is a subclass of Query & Search class.
proxhy objects [12]. Instead of storing the contents, a data wrapper node stores a reference to the actual location of the contents. This allows links to be an-chored to les in the Unix le system.
The Link class supports a very general multi-headed (n-n) link. Links have a direction, but can be traversed in both directions. Links maintain two lists of endpoints (to and from). A link endpoint can be one of three types: static, dynamic (computed) or dangling. A static endpoint contains an anchor / com-ponent OID pair, a dynamic endpoint contains a script evaluating to an anchor / component OID pair, and a dangling endpoint is simply empty.
The Composite class supports a general aggregation mechanism. Composites are unstructured collections (sets) of other components referenced by their OID. Composites are either static or dynamic (computed). A static composite contains a list of component OIDs, while a dynamic composite contains a script (query) evaluating to a list of component OIDs.
2.3 Integration Model Layer
The basic built-in integration model supports two types of hypermedia objects, Anchor and Link (Figure 3). The Anchor class provides operations to create, update and delete endpoints in artifacts. The Link class provides operations to create, update, delete and follow links.
Participating tools can extend and tailor the inte-gration model and communication protocol by adding new (sub)types and new messages and specializing ex-isting messages in the Anchor and Link class. This means that tools can agree on their own models for in-creased (or dein-creased) integration and participation in hypermedia services. Communication between partic-ipating tools and the hypermedia framework is based on a generic object-oriented message passing mecha-nism:
(send object message . arguments)
Basic classes Object
Anchor Link
Integration model classes
Figure 3: Built-in integration model classes. The in-tegration model layer provides an extensible minimal integration model consisting of anchors and links.
Thus, the integration model layer provides a exi-ble communication protocol supporting an extensiexi-ble set of hypermedia services, rather than a xed set of services.
2.4 Levels of Integration
The hypermedia framework should be able to pro-vide hypermedia linking services for both tools that have been created to be used with the framework and, more interestingly, tools that have been created inde-pendently of the framework. This requires that dier-ent tools can be integrated to participate in the hyper-media services at dierent levels. To illustrate this, we describe three levels of integration: full, partial and no integration.
Full integration
At this level of integration, tools use the hypermedia framework to store all its ar-tifacts in dierent node types. Arar-tifacts managed by the tools can serve as endpoints of references (links). Anchors allow pieces of data within arti-facts to serve as endpoints for links. When navi-gating a reference to an artifact, the hypermedia framework launches the appropriate tool display-ing the artifact. If an anchor connects the link to a particular piece of information in the artifact, this piece of information is highlighted in the tool.Partial integration
Like full integration, except that at this level of integration, tools use the hy-permedia framework to provide anchors and links to connect (pieces of) artifacts which are stored elsewhere in the computing environment, e.g., in the le system. The fact that anchors and links are stored separately and superimposed on the artifacts by the tools, makes it possible to link into artifacts stored on read-only media such as CD-ROM.No integration
At this level of integration, tools store its artifacts elsewhere. Artifacts managed by non-integrated tools can only have incoming links; it is not possible to follow links from these artifacts. Anchors, if provided, can only refer to an artifact as a whole, not to a particular piece of data within the artifact. When navigating a ref-erence to an artifact managed by a non-integrated tool, the hypermedia framework launches the tool displaying the artifact. No hypermedia services are available when working with this tool.The hypermedia framework must support all lev-els of integration ranging from full over partial to no integration to allow all manner of existing and future tools to be integrated. Depending on the level of in-tegration, the hypermedia framework places certain requirements on tools to be able to use the hyper-media services. Requirements on tools ranges from no requirements (no integration), over the ability to com-municate with the hypermedia framework (e.g, using sockets) and exchange anchor identiers1(partial
inte-gration) to the situation where the tool relies 100% on the services of the hypermedia framework (full integra-tion). A fully integrated tool must be able to commu-nicate storage requests to the hypermedia framework and respond to hypermedia events.
2.5 Integration Method
Integration of tools in the hypermedia framework will generally require the followings steps: analyzing the tool to determine the degree of openness in the tool, determining an appropriate level and model of integration for the tool, and specializing the built-in functionality of the hypermedia framework to support the chosen level and model of integration. The lat-ter task is divided into two subtasks: specializing the integration model and specializing the data model of the hypermedia framework to provide the necessary services.
3 Hyperdisco Prototype
In this section, we present a brief overview of Hy-perDisco, a prototype implementation of an object-oriented hypermedia framework based on the de-scribed concepts. A more detailed technical descrip-tion of the HyperDisco prototype is provided in [23]. We will briey describe the system architecture and the individual architectural components providing the data model and integration model layers. HyperDisco is implemented using the Hyperform hypermedia sys-tem development environment [24, 26].
The HyperDisco system architecture is composed of a distributed hypermedia database (hyperbase) man-agement system, tool integrators and participating tools as depicted in Figure 4. The tool integrator im-plements the integration model layer (Figure 3) and the hypermedia database implements the data model layer (Figure 2) of the hypermedia framework. The ar-chitecture can be scaled from a single tool integrator / hyperbase pair to multiple, distributed tool integra-tors and hyperbases.
The tool integrator is the central component of the architecture supporting multiple integration models allowing distributed heterogeneous tools to participate in hypermedia services. The tool integrator controls access and operation of a multi-hyperbase manage-ment system and implemanage-ments all the necessary runtime support for participating tools such as distribution of
1What exactly is exchanged depends on the chosen model of
integration. The model must specify a way to uniquely identify the appropriate link in a follow-link request. Depending on the model, the tool could, for instance, communicate an OID of the selected anchor or an anchor value / le name pair to allow the hypermedia framework to determine what link to follow.
Hypermedia database Tool integrator Tool Hypermedia database Tool integrator Tool Tool Tool Tool Hypermedia database
Figure 4: The HyperDisco system architecture. Tool integrators provide the integration model layer and hypermedia databases provide the data model layer of the hypermedia framework.
events from the hyperbases and storage, manipula-tion and retrieval of linking and anchoring informa-tion from the hyperbases. Tool integrators also allow participating tools (connected to the same tool inte-grator) to share hypermedia structures and to com-municate using an event-based mechanism.
Both the tool integrator and the hypermedia database component is based on an internal computa-tional engine that provides an object-oriented exten-sion language which allows the built-in services to be extended and tailored dynamically at runtime. New (versions of) classes are created by composing and sending a message to the component containing a de-scription of the class. Thus, the integration model and data model can be customized at runtime allowing tools to be integrated on the y in a rapid prototyping manner.
4 Experiences and Related Work
This section presents two tests that have been per-formed with the HyperDisco prototype as a proof of concept. Two existing tools were integrated in the hy-permedia framework to test dierent specializations of the integration model and dierent levels of integra-tion. Based on the tests, preliminary experiences with the HyperDisco framework are presented. We then compare HyperDisco to related work.
4.1 Test 1: Anchor Link Integration
Model
This test uses an integration model composed by anchor and link abstractions as depicted in Figure 5. We have integrated the GNU Emacs text editor [22] and Idraw drawing tool at dierent levels of integra-tion. Emacs is partially integrated and Idraw provides no integration with the HyperDisco framework. An-chors are made responsible for maintaining informa-tion on where the artifact is stored, what applicainforma-tion can display the artifact, and what particular piece of data within the artifact (if any) is used as endpoint for the hypermedia link. Links in the model are simply used to connect anchors. The following example illus-trates the communication (message passing) necessary to follow a link from Emacs to Idraw.
[email protected] InterViews drawing editor
−−−Emacs: test.txt (Text)
sketch.ps test.txt sketch.ps value: link component #1608 anchor #431 anchor #142 application: emacs value: hypermedia link file: ~/HyperDisco/test.txt
from: 431 to: 142
application: idraw
file: ~/HyperDisco/sketch.ps
Buffers File Edit Help
This is an example of a text file which have a hypermedia link to an Idraw sketch. The user can follow the link by selecting the marked word.
Figure 5: Principles and abstractions in the Anchor Link integration model.
Example:
Follow a link from Emacs to Idraw By selecting the anchor value "hypermedia link", the user indicates that she wishes to follow the link associated with the anchor. Emacs looks up the an-chor value in an internal anan-chor table and gets hold of the belonging anchor OID (#431). Emacs sends afollow-link
message to the link class in the tool integrator component with the anchor OID as ar-gument: (send integration-model-link-class follow-link 431). Thefollow-link
method sends a message to the hypermedia database requesting the anchor asso-ciated with anchor #431: (send data-model-link-class get-anchor 431). Theget-anchor
method locates the link associated with anchor #431 (by querying the database), which turns out to be link #1608. Then theget-anchor
method reads the associated anchor OID (#142) and reads and returns the entire anchor object (#142) to the calling method (follow-link
). Based on the attribute values of the anchor object (#142), thefollow-link
method can start the Idraw application displaying the relevant le. Thefollow-link
operation is now completed.Implementation of the Anchor Link integration model in the HyperDisco framework involved special-ization of the built-in Anchor and Link class at the integration model layer and the built-in Anchor and Link class at the data model layer to provide the neces-sary services (attributes and methods). It was, for in-stance, necessary to extend the data model Link class with a
get-anchor
method and the data model An-chor class with additional attributes (application and le).This integration model requires that Emacs as a partially integrated tool is capable of managing an anchor table data structure and communicating with
the HyperDisco framework via sockets. The contents of the anchor table is retrieved from the hypermedia framework when a le is loaded. The model places no requirements on Idraw as a non-integrated tool.
4.2 Test 2: Data Wrapper Node
Integra-tion Model
The second test uses a more complicated integra-tion model with node, link and anchor abstracintegra-tions (Figure 6). Again, we have integrated the Emacs ed-itor and Idraw drawing tool at dierent levels of in-tegration. Like before, Emacs is partially integrated and Idraw provides no integration with the Hyper-Disco framework. Anchors simply hold information on what particular piece of data in the artifact (in any) is used as link endpoint. Nodes are now made responsi-ble for maintaining information on where the artifact is stored, what application can display the artifact, and which anchors are associated with the artifact. Links are used to connect node / anchor pairs. The following example illustrates a
follow-link
operation from Emacs to Idraw.Example:
Follow a link from Emacs to Idraw By selecting the anchor value "hypermedia link", the user indicates that she wishes to follow the link as-sociated with the anchor. Emacs sends afollow-link
message to the link class in the tool integrator compo-nent with the application name, le name and anchor value as arguments: (send integration-model-link-class follow-link "emacs" "/user/kock/HyperDisco/test.txt" "hypermedia link"). Thefollow-link
method sends a message to the hypermedia database request-ing the node associated with the selected an-chor value: (send data-model-link-class get-node "emacs" "/user/kock/HyperDisco/test.txt" "hyperme-dia link"). Theget-node
method locates the node[email protected] InterViews drawing editor
−−−Emacs: test.txt (Text)
sketch.ps test.txt sketch.ps application: emacs file: ~/HyperDisco/test.txt application: idraw file: ~/HyperDisco/sketch.ps
node component #1287 node component #542 anchor #349 value: anchors: 417 anchor #417 from: (1287,349) to: (542,417) link component #1077 anchors: 349
Buffers File Edit Help
value: hypermedia link
This is an example of a text file which have a hypermedia link to an Idraw sketch. The user can follow the link by selecting the marked word.
Figure 6: Principles and abstractions in the Data Wrapper Node integration model. (#1287) and anchor (#349) of the selected anchor
value by querying the database. Based on the an-chor and node OID's, the
get-node
method locates the link (#1077) by query. Finally, theget-node
method reads the node OID (#542) in the link and, reads and returns the entire node object to thefollow-link
method. Based on attribute values, thefollow-link
method starts the Idraw application displaying the le.Implementation of the Data Wrapper Node inte-gration model in the HyperDisco framework involved adding a Node class and specialization of the built-in Anchor and Link class (integration model layer) and specialization of the built-in Node, Anchor and Link classes (data model layer). For instance, a text node subclass was created to support textual artifacts (in this case text les in Emacs).
This integration model places fewer requirements on Emacs as a partially integrated tool. Emacs must simply be able to communicate with the HyperDisco framework via a socket protocol. Like before, no re-quirements are placed on Idraw as a non-integrated tool.
4.3 Experiences
Experiences achieved in the described two and other tests with the HyperDisco framework fall into several categories. Due to the overall focus of this paper, we will only present experiences that relate to integration and modeling aspects.
Existing versus new tools
. In the two tests, we have only dealt with integration of existing tools, since this is the most dicult type of integration, and prob-ably also the most realistic, based on the assumption that users will not give up their favorite tools in ex-change for hypermedia functionality. Developing new tools with hypermedia functionality is a matter of in-cluding support for this functionality in the design and development process, for example, by including a dedi-cated library in the tool making use of the hypermedia framework services.Integration models
. The HyperDisco prototype supports dierent models of integration. We have showed how Emacs can be partially integrated in two dierent ways to use hypermedia services. The pre-sented models dier in the way basic hypermedia ab-stractions are composed to support hypermedia link-ing and in the way tools communicate with the frame-work. Both models allow participating tools to store artifacts elsewhere in the computing environment. Ar-tifacts are not altered by the operations of the hyper-media framework, since anchors and links are superim-posed on artifacts at runtime. Both models therefore allow references into read-only media.Integration models are developed by specializing the built-in classes in the integration model layer and data model layer of the framework. The HyperDisco prototype allows new integration models to be shaped and new tools to be integrated at runtime, thus sup-porting a rapid prototyping approach to tool integra-tion. This feature makes it is easy to experiment
with alternating integration models and communica-tion protocols to determine the best way to integrate individual tools or a set of coherent tools in the frame-work.
Levels of integration
. The HyperDisco proto-type allows tools to be integrated at dierent levels of integration depending on the nature of the tool. Tests have dealt with integration of three types of existing tools: extensible, semi-extensible and closed. Fully ex-tensible tools (such as Emacs) can be integrated with the hypermedia framework at any level of integration. Semi-extensible tools (e.g. tools providing a limited macro denition capability) can in many cases be par-tially integrated. It is dicult (but not impossible) to integrate closed tools (such as Idraw) in the hyper-media framework. No matter how closed a tool is, it will always be possible to follow links to artifacts man-aged by the tool. The problems arise when we wish to follow links from artifacts managed by closed tools.Dierent levels of integration in the hypermedia framework places dierent requirements on the tool. As a minimum, a tool must be able to communicate with the hypermedia framework to make use of the hypermedia linking capabilities. Depending on the level and model of integration, tools must meet ad-ditional requirements such as the ability to maintain an internal anchor table, to receive and respond to hypermedia events and to store its artifacts in the hy-permedia database. In addition to these requirements, tools supporting hypermedia linking must in some way make these facilities available to the user through a user-friendly interface. The user should be able to lo-cate anchors and follow links to related artifacts and to create, share and delete relations in a natural way. The tests showed that dierent integration mod-els place dierent requirements on tools in order to be partially integrated in the hypermedia framework. Results indicate that models that place more require-ments on the tools rely less on queries in the hyperme-dia database, for example, the fact that Emacs in the rst test is able to communicate the anchor OID to the integration link class saves two complex queries in the hypermedia database (in a
follow-link
operation) compared to how things are done in the second test.4.4 Related Work
An increasing number of hypermedia systems and frameworks are designed as open systems allowing ex-isting and future tools to be integrated to make use of the hypermedia linking services. The most promi-nent open hypermedia systems and frameworks in-clude Texas A&M University's Proxhy [12] and SP3 [14], Sun's Link Service [19], Euroclid's Multicard [20], University of Southampton's Microcosm [6], Aarhus University's DeVise Hypermedia (DHM) [9] and Uni-versity of California, Irvine's Chimera [1].
Existing open hypermedia systems and frameworks can be divided into two categories. The rst cate-gory (DHM and SP3) includes a hypermedia database supporting a full hypermedia data model capable of providing storage of all artifacts as well as providing storage of hypermedia linking information for partici-pating tools. The latter category (Microcosm, Proxhy,
Multicard, Chimera and Link Service) makes the as-sumption that participating tools use other informa-tion repositories to store their artifacts and only use the hypermedia database to store hypermedia link-ing information. HyperDisco belongs to the rst cat-egory. HyperDisco provides a full hypermedia data model and allows tools to participate in the hyperme-dia services at various levels depending on the tool.
Most other open hypermedia frameworks share the basic assumption made in the HyperDisco project, that providing support for integration of existing tools is the appropriate approach, rather than to develop a new set of tools providing hypermedia services. The work on Microcosm and DHM has shown that many closed tools can be integrated with an open hyperme-dia framework and provide links both to and, more in-terestingly, from artifacts managed by the tools. The work has also shown that is it not possible to inte-grate closed tools in a general way. Each tool must be carefully analyzed and, depending on its nature, integrated in its own special way.
HyperDisco diers from other open hypermedia frameworks by allowing the integration model to be specialized dynamically. Participating tools can dy-namically extend and tailor the integration model and communication protocol by adding new messages and specializing existing messages and integration model objects. This means that tools can agree on their own models for increased (or decreased) integration and participation in the hypermedia services. Other systems provide a single integration model and com-munication protocol. Tools are integrated at dierent levels in these systems by using more or less of the xed set of operations in the communication protocol.
5 Conclusions
The overall goal of the HyperDisco project is to provide a hypermedia framework for exible software system integration. HyperDisco takes a particular ap-proach in attaining its goal, namely to provide an extensible application independent hypermedia ser-vice within an open, distributed architectural setting. The basic concept is that extensibility at both the data model and integration model levels combined with carefully designed broadly applicable generality at both levels can facilitate exibility and tailorability system wide. We believe that this notion is a reason-able and workreason-able foundation for a hypermedia frame-work. The HyperDisco prototype provide us with a testbed allowing us to examine the validity of the pro-posed concepts. Preliminary experiences indicate that HyperDisco provides a useful framework for exible software system integration. Future tests and exper-iments will further assess the integration capabilities and try to locate potential problems and bottlenecks in the HyperDisco prototype.
5.1 Current Status and Future Plans
The HyperDisco prototype operates in Unix envi-ronments and is presently hosted on Sun Sparcsta-tions. Currently, we have integrated a small (but steadily growing) set of tools and data formats to as-sess the integration capabilities of the framework. We
have found the prototype suitable to conduct various tests and experiments addressing the many important characteristics of hypermedia frameworks discussed in the Introduction. This paper has focused on open-ness, extensibility, integration and modeling capabil-ities of the prototype. Other tests have focused on multiuser, distribution, interoperability and collabo-ration aspects as well [23]. Future tests and experi-ments will address the important issues of scalability, heterogeneity, performance and eciency.
References
[1] K. M. Anderson, R. N. Taylor, and E. J. Whitehead. Chimera: Hypertext for heterogeneous software envi-ronments. InProceedings of ECHT '94, pages 94{107, Edinburgh, Scotland, Sept. 1994. ACM.
[2] J. Bigelow. Hypertext and CASE. IEEE Software, 5(2):23{27, Mar. 1988.
[3] J. Bigelow and V. Riley. Manipulating source code in Dynamic Design. InProceedings of Hypertext '87, pages 397{408, Chapel Hill, NC, Nov. 1987. ACM. [4] J. Conklin. Hypertext: An introduction and survey.
IEEE Computer, 20(9):17{41, Sept. 1987.
[5] M. L. Creech, D. F. Freeze, and M. L. Griss. Using hypertext in selecting reusable software components. InProceedings of Hypertext '91, pages 25{38, San An-tonio, TX, Dec. 1991. ACM.
[6] H. Davis, W. Hall, I. Heath, G. Hill, and R. Wilkins. Towards an integrated information environment with open hypermedia systems. In Proceedings of ECHT '92, pages 181{190, Milan, Italy, Dec. 1992. ACM. [7] N. M. Delisle and M. D. Schwartz. Neptune: A
hy-pertext system for CAD applications. InProceedings of SIGMOD '86, pages 132{143, Washington, D.C., May 1986. ACM.
[8] P. K. Garg and W. Scacchi. A hypertext system for software life cycle documents. IEEE Software, 7(3):90{99, May 1990.
[9] K. Grnbk and R. H. Trigg. Design issues for a Dexter-based hypermedia system. Communications of the ACM, 37(2):40{49, Feb. 1994.
[10] F. G. Halasz. Reections on NoteCards: Seven issues for the next generation of hypermedia systems. Com-munications of the ACM, 31(7):836{852, July 1988. [11] F. G. Halasz and M. D. Schwartz. The Dexter
hyper-text reference model. Communications of the ACM, 37(2):30{39, Feb. 1994.
[12] C. J. Kacmar and J. J. Leggett. Proxhy: A process-oriented extensible hypertext architecture. ACM Transactions on Information Systems, 9(4):399{419, Oct. 1991.
[13] R. Kadia. Issues in building a exible software devel-opment environment: Lessons learned from the Arca-dia project. In Proceedings of SIGSOFT '92, Wash-ington, D.C., Dec. 1992. ACM.
[14] J. J. Leggett and J. L. Schnase. Viewing Dexter with open eyes.Communications of the ACM, 37(2):76{86, Feb. 1994.
[15] J. J. Leggett, J. L. Schnase, J. B. Smith, and E. A. Fox, editors. Final report of the NSF workshop on hyperbase systems, Washington, D.C., October 15-16, 1992. Department of Computer Science Technical Report TAMU-HRL-93-002, Texas A&M University, June 1993.
[16] K. C. Malcolm, S. E. Poltrock, and D. Schuler. Indus-trial strength hypermedia: Requirements for a large engineering enterprise. In Proceedings of Hypertext '91, pages 13{24, San Antonio, TX, Dec. 1991. ACM. [17] N. Meyrowitz. The missing link: Why we're all doing hypertext wrong. In E. Barrett, editor, The Society of Text: Hypertext, Hypermedia, and the Social Con-struction of Information, pages 107{114, 1989. The MIT Press.
[18] J. Noll and W. Scacchi. Integrating diverse informa-tion repositories: A distributed hypertext approach.
IEEE Computer, 24(12):38{45, Dec. 1991.
[19] A. Pearl. Sun's link service: A protocol for open link-ing. InProceedings of Hypertext '89, pages 137{146, Pittsburgh, PA, Nov. 1989. ACM.
[20] A. Rizk and L. Sauter. Multicard: An open hyperme-dia system. InProceedings of ECHT '92, pages 4{10, Milan, Italy, Dec. 1992. ACM.
[21] J. B. Smith and F. D. Smith. ABC: A hypermedia system for artifact-based collaboration. In Proceed-ings of Hypertext '91, pages 179{192, San Antonio, TX, Dec. 1991. ACM.
[22] R. M. Stallman. Emacs: The extensible, customiz-able, self-documenting display editor. In D. R. Barstow, H. E. Shrobe, and E. Sandewall, editors, In-teractive Programming Environments, pages 300{325, 1984. McGraw-Hill.
[23] U. K. Wiil and J. J. Leggett. The HyperDisco ap-proach to open hypermedia systems and seamless in-tegration of information. Submitted toHypertext '96, 1995. Available through the rst author.
[24] U. K. Wiil and J. J. Leggett. Hyperform: A hyper-media system development environment. Submitted toACM Transaction on Information Systems, 1995. Available through the rst author.
[25] U. K. Wiil and J. J. Leggett. Concurrency control in collaborative hypertext systems. InProceedings of Hypertext '93, pages 14{24, Seattle, WA, Nov. 1993. ACM.
[26] U. K. Wiil and J. J. Leggett. Hyperform: Using ex-tensibility to develop dynamic, open and distributed hypertext systems. InProceedings of ECHT '92, pages 251{261, Milan, Italy, Dec. 1992. ACM.
