Integrating Infrastructure: Enabling Large-Scale Client Integration

Integrating Infrastructure: Enabling Large-Scale Client Integration Kenneth M. Anderson, Christian Och, Roger King, Richard M. Osborne Department of Computer Science University of Colorado, Boulder Boulder, CO 80309-0430, USA Tel: 1-303-492-6003

E-mail: {kena, och, roger, rick}@cs.colorado.edu ABSTRACT

services within applications that may not have been designed with hypermedia in mind. Open hypermedia services are provided by open hypermedia systems (OHSs),

The open hypermedia community has addressed issues of client integration—providing hypermedia services in thirdparty applications—over the past decade. As a result, a set of models and techniques has emerged to guide developers in the task of integrating hypermedia services into their applications. We argue that the logical next step for the open hypermedia community is to develop techniques for integrating massive numbers of clients in tandem. Our approach consists of integrating existing infrastructure mechanisms that are already used by numerous applications. We believe that integrating an underlying infrastructure can provide a basic level of hypermedia functionality to client applications while reducing the level of effort required of application developers. We present issues encountered in performing client-integration-in-the-large, discuss an experimental prototype of a specific infrastructure integration, and describe related work in this area.

so the task of integration involves 1) establishing a communication channel between an application to be integrated (or target application) and an open hypermedia system, and 2) modifying the user-interface of the target application to indicate to a user that hypermedia services are available. The hypermedia community has developed a wide range of hypermedia services; a list of “basic” services typically includes the ability to create and manage anchors, the ability to create, manage, and traverse links, a history mechanism of past traversals, and path mechanisms such as guided tours. Our concern in this paper is with the scope, or focus, of the techniques developed so far to achieve client integration [9, 32, 34]. In particular, these techniques focus on integrating one client at a time. We argue that one result of this focus has been the development of only a small set of open hypermedia clients. Client integration requires a non-trivial amount of development effort and thus far only motivated developers (typically OHS developers) have been willing to undertake the effort to achieve an integration. Compounding this problem is the fact that, until recently, each integration was for a specific open hypermedia system only.

KEYWORDS: open hypermedia, client-integration-in-thelarge, infrastructure integration INTRODUCTION

Open hypermedia [27] is a ten year old approach to the general problem of information organization. It allows users to establish relationships over heterogeneous sets of data managed by an open set of applications, and to rapidly navigate those relationships at run-time. Open hypermedia is characterized by two features that distinguish it from other approaches to information organization: externally managed/stored relationships, and third-party application integration. This paper explores issues and presents new research related to the second characteristic.

To address this restriction, the open hypermedia community developed the Open Hypermedia Protocol (OHP) [8] to allow clients to access hypermedia services from more than one OHS. This achievement has increased the utility of any single integration; now it is time for the open hypermedia community to focus its attention on the first problem, i.e. reducing the amount of development effort required to achieve an integration. We argue that a general solution to this problem will drastically increase the number of open hypermedia clients.

Third-party application integration (also known as client integration) is the task of providing open hypermedia

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Hypertext 2000, San Antonio, TX. Copyright 2000 ACM 1-58113-227-1/00/0005…$5.00

In particular, we believe that the focus of client integration techniques should scale up to methods that integrate large sets of clients in tandem. We believe that one approach for achieving this increase in scale is to integrate infrastructure mechanisms that are already used by a large set of applications and to provide open hypermedia services to these applications via the integrated infrastructure. We refer

57 1

infrastructure to provide the ability to create anchors and or traverse links on behalf of its client applications.

to this approach of integrating infrastructure as clientintegration-in-the-large. Example infrastructure mech-anisms that may be suitable for integration with open hypermedia systems include user-interface toolkits [1], databases, workflow systems, groupware toolkits, and file systems.1

The issue of user-interface consistency involves the difficulty encountered in making the user interface to open hypermedia services uniform across all integrated applications. Uniformity is difficult to achieve since open hypermedia systems do not have control of the user interfaces of their client applications [33]. As such, application developers can make different choices with respect to how anchors are created and how links are traversed in their applications. This inconsistency makes it difficult for end-users to remember how to access open hypermedia services across applications [28]. With respect to our goal of integrating infrastructure, our hypothesis is that such integrations will help to address the issue of consistency and make it easier to achieve uniformity. The reason for this stance is that an integrated infrastructure can ensure that all hypermedia services that it provides make use of common user interfaces and interaction styles across all client applications. The work presented in this paper and the experience of some related work discussed below lends weight to the validity of this hypothesis.

In this paper, we examine the issues encountered in addressing client-integration-in-the-large and discuss one possible approach to achieving infrastructure integration. Our observations are grounded in an experimental integration with a middleware system designed to support applications accessing information stored in multiple databases. The rest of the paper is organized as follows. We first discuss the significant body of related work in the area of client integration and try to cull the important lessons learned. We then describe our approach and issues related to clientintegration-in-the-large. We next discuss our experimental prototype, and then present our conclusions. RELATED WORK

The topic of client integration has a significant body of literature to support the creation of new techniques. We discuss a wide range of related work in this section covering such topics as client integration models and homogeneous and heterogeneous integration techniques. We also present our view on how client-integration-in-the-large relates to the newly emerging field of structural computing.

Davis, et al. Davis, Knight, and Hall present a model of client integration in [9] that consists of six categories for classifying the types of integrations faced by application developers. The categories consist of the following (in increasing order of generality): tailor-made viewers, source code adaptation, object-oriented reuse, application interface level adaptation, shims (e.g. wrappers), and launch-only viewers. The level of hypermedia sophistication that each category can provide is highest with tailor-made viewers decreasing along the spectrum until launch-only viewers are reached. Launch-only integrations, of course, provide no hypermedia services at all.

Models of Client Integration

There are several models of client integration that have been developed by the open hypermedia community. We briefly discuss the models presented by Davis, et al. [9], Wiil [34], and Whitehead [32]. However, we first present some foundational issues identified by Amy Pearl during her work on Sun’s Link Service [28]. Although we focus on some of Pearl’s issues, we should note that her work—indeed all open hypermedia work—has roots in a talk presented by Norman Meyrowitz that was later published in [21].

Wiil. In his work on HyperDisco [34], Wiil presents a simple

model of client integration using a notion of “completeness.” In this model, a client can be fully-integrated, partially integrated, or not integrated. A fully-integrated client is provided the highest level of service by HyperDisco in areas such as concurrency control, notifications, versioning, access permissions, and search and query services. Partiallyintegrated clients can access basic hypermedia services but receive little or no support for the areas listed above. Nonintegrated clients, of course, receive no services from HyperDisco but may be launched by HyperDisco as the result of a link traversal. It should be noted that HyperDisco provides a component called the tool integrator (that first appeared in Hyperform [36]) that eases the development of partially-integrated applications and provides a foundation for incrementally raising these clients to a fully-integrated status.

Client Integration Issues. Amy Pearl identified the following issues that impact all technical approaches to providing open hypermedia services to client applications: linkable objects, user interface consistency, link maintenance, versioning support, handling structureless documents, and issues of distribution. Many of these issues have been addressed in subsequent work on open hypermedia (for instance, see [9, 14, 15, 17, 18, 35]), however for our purposes we wish to highlight the first two.

The issue of linkable objects is that in order for a client to participate in an open hypermedia system, it must have some form of information that can be linked. With respect to our goal of integrating infrastructure, this issue may imply a litmus test as to what types of infrastructure are amenable to integration with an open hypermedia system. In particular, the infrastructure must provide some type of service or structure to third-party applications that can act as linkable objects. Otherwise, there would be no way for the

Whitehead. Whitehead provides a detailed model of client

integration in [32]. Whitehead’s model also uses a notion of completeness but goes beyond the other models to define explicitly the characteristics of a “complete” integration. In particular, his model consists of containers, communicators, and artists.

1 In fact, we know of one developer who is examining open hypermedia issues at the file system level.

58

technique takes advantage of a service of the X windowing system which allows the Matrix to detect when an application creates a window and presents it on screen. Upon detecting this event, the Matrix creates a window that acts as a parent to the window created by the application. As a result, all events that are sent to the application must go through the Matrix’s window first. This allows the Matrix to capture particular events and process them without the awareness of the underlying application. As such, the Matrix is able to add basic support for anchor and link manipulation to all applications that use the X windowing system for their user interface. In actuality, the support for these capabilities is not entirely automatic, however the Matrix is designed to keep the applicationspecific code required to use the Matrix’s hypermedia capabilities at a minimum. See [19] for details.

Containers are used to group other elements and to represent client applications. Communicators are used to establish and maintain communications between two programs using a specific protocol. There is a particular type of communicator called a translator that represents a common element in client integrations: one which translates an application’s native communication protocol into the protocol used by an open hypermedia system. Finally, artists are used to represent an application’s capabilities with respect to presenting and manipulating objects of its domain, with respect to presenting and manipulating anchors, and with respect to accessing link traversal services. The first capability is provided by a native artist, while the second and third are provided by anchor and link artists respectively. With these elements, Whitehead characterizes a complete integration as one in which the client contains at least one instance each of a native, anchor, and link artist, and has a communicator for the hypermedia system’s native protocol. In addition, the client may need a translator to communicate effectively with this communicator. The benefits of Whitehead’s model is that a client can be characterized as to its state before an integration effort (for instance, it may not have anchor and link artists) and the desired state after the integration. The difference between these two states can serve as a rough characterization of the amount of development effort the integration will require to be achieved. Whitehead completes the model by describing three “common” integration architectures: launch-only, wrapper, and custom. These architectures share similar characteristics with the categories of the two models above. However, Whitehead noted that often developers take advantage of a combination of these architectures within a single integration to achieve a higher level of hypermedia functionality that would be otherwise difficult to achieve using only one of them.

It should be noted that Kacmar uses a similar technique in Freckles [20], a system designed to support the rapid prototyping of hypermedia services within client applications. Instead of integrating hypermedia services into a particular windowing system, Freckles integrates a particular windowing manager. This is a somewhat more general technique, since windowing managers are often able to work with more than one windowing system. However, this technique should still be considered homogeneous, since windowing managers are often restricted to just one platform or operating system. Microcosm’s Universal Viewer. The Microcosm Universal

Viewer [9] is a program that exploits services of Microsoft Windows to provide hypermedia services within nonhypermedia applications. A user maintains a list of applications that require the use of the universal viewer, and the universal viewer monitors events that indicate when one of these applications is launched. When this occurs, the universal viewer attaches itself to the application and adds a new menu to the application’s menu bar that provides access to Microcosm’s hypermedia services.

Discussion. The three models above help formalize the

open hypermedia community’s knowledge of client integration techniques. However, each of these models focuses on integrating only one client at a time. Our goal with client-integration-in-the-large is to develop models and techniques that enable the integration of multiple clients at once. However, the above models do provide utility for our work in integrating infrastructure. For instance, an integrated infrastructure must contain analogs of Whitehead’s anchor and link artists.

An integration technique can be considered homogeneous when it takes advantage of some characteristic of a particular computing environment. Typically, it is difficult to reuse such a technique across computing platforms since the characteristic that enables the integration technique is unique to its platform of origin.

The universal viewer must be configured for each monitored application to know how to communicate with the application in order to ask it to retrieve the current selection, provide access to the selection, and finally, how to ask the application to locate and display destination anchors. Since the underlying application is unaware that it is interacting with a hypermedia system, typically a macro of some sort is associated with each of the universal viewer’s menu items that allows the application to do the correct thing. Thus, the universal viewer is dependent on the existence of operating system services that allow it to attach a menu to an application’s menu bar and to control an application via a script or macro. Nonetheless, the universal viewer with these mechanisms is able to provide hypermedia services equivalent to Wiil’s partially integrated-applications even though the applications themselves would be classified by Wiil as non-integrated.

ABC’s Matrix. The ABC open hypermedia system [30]

Toolkit Integrations. Several systems make use of a

contains a component known as the Matrix [19] that employs a homogeneous integration technique to incorporate a wide range of third-party applications. The

technique referred to as object-oriented reuse by Davis, et al., in providing hypermedia services to third-party applications. In this technique, hypermedia concepts and

Homogeneous Integration Techniques

59

application’s internal structures and services such that the wrapper is able to enable the creation and manipulation of anchors, is able to provide access to link traversal services, and is able to respond to link traversal events such that destination anchors can be displayed. Some wrappers can be quite powerful. For instance, HyperDisco’s tool integrator can wrap applications and provide advanced services such as application data caching and collaboration capabilities for the target application [34]. While the tool integrator can play the role of a wrapper, it can also be used as the basis for custom client integrations, discussed next.

services are provided by an object-oriented framework that developers subclass when constructing their applications. Examples of using this technique include HOT [29], Intermedia, [37], and Garrido and Rossi’s SmallTalk-based toolkit [12]. This technique is homogeneous in the fact that a particular toolkit must be used in order to receive hypermedia services. In addition, the technique is quite limiting since the hypermedia services are only provided over the application’s content; links between applications are not supported. Both DHM [14] and HyperDisco [34] address this limitation by providing object-oriented toolkits that derive their hypermedia services from an underlying open hypermedia system.

Custom. Custom integrations occur when an application is designed to provide hypermedia services from the start of its life cycle. In such cases, a developer makes use of an OHS’s application program interface (API) directly within the client application. The existence of the OHP now allows developers to create custom clients that work across multiple open hypermedia systems. Note: Whitehead presents several examples of launch-only, wrapper, and custom integrations in [32].

Discussion. Homogeneous techniques are quite powerful

because they exploit characteristics of a particular computing environment. Furthermore, it is easy to apply the technique ubiquitously, thus enabling the integration of multiple clients at once. These characteristic offer insight into the power of achieving client-integration-in-the-large, however we would like to integrate infrastructure services using techniques that are not homogeneous but instead can be applied across heterogeneous environments.

World Wide Web Client Integration Techniques. Several

techniques have been developed to provide open hypermedia services to Web-based clients. A taxonomy of integrations is presented by Anderson in [2] and expanded by Bouvin in [6]. Standard techniques include the use of Web proxies or the use of Javascript, Web Browser plugins, and/or Java applets. For instance, the Distributed Link Service [7] makes use of the former technique to provide access to the hypermedia services of Microcosm [16]. Both DHM [13] and Chimera [2] are examples of systems that employed the latter set of techniques. Finally, Bouvin is developing a generic framework [6] that eases the development of integrating hypermedia services into Webbased clients, building on the lessons learned of the work above. These techniques can be considered heterogeneous since they often can be employed across different Web browsers and different computing environments.

Heterogeneous Integration Techniques

An integration technique can be considered heterogeneous when it can be applied across multiple computing environments. That is, these techniques make use of generic mechanisms or employ platform-independent steps to achieve the integration of hypermedia services into client applications. Launch-Only. The client integration models above all had a

category of client where the application remains unaware of the open hypermedia system. One generic technique for integrating these applications into an open hypermedia system is to enable links to point at content or documents managed by the unaware application. Then, when a link traversal arrives at such a document, the open hypermedia system makes use of operating system services to launch the unaware application such that the document is displayed. For instance, the original version of Chimera [4] made use of a process invoker which relied upon Unix’s fork command to achieve this functionality. The downside of this technique is that while it can enable the display of an unaware client’s documents, no hypermedia services are provided over this content. Despite this lack of functionality, this integration technique is generally considered valuable by the open hypermedia community. In fact, the open hypermedia community formalized this position by requiring that all applications that make use of the OHP [8], at a minimum, be capable of launch-only functionality.

Toolkit Integration Technique. The first author provides an early example of infrastructure integration with his toolkit integration technique [1]. In this particular context, toolkit refers to user-interface toolkits that are used by applications to create and manage their user interface (UI). Anderson presents a heterogeneous technique that can be used to integrate hypermedia services into a UI toolkit independent of the target UI toolkit or target open hypermedia system. (In fact, Anderson makes use of a component called the “abstract hypermedia interface” within this technique in order to achieve independence from any particular open hypermedia system. Today, the OHP [8] can be used to play the role of this component.)

The basic idea of the toolkit integration technique is to create a set of user interface widgets that provide open hypermedia services on behalf of their host applications. Thus, a hypermedia-aware scrollbar can be used to associate anchors with particular positions of its thumb. If a link traversal ends at one of the scrollbar’s anchors, it can

Wrapper. A wrapper integration consists of a small

executable program that knows how to communicate with a target application and an open hypermedia system. The target application must provide some form of external interface by which the wrapper can control its behavior. In addition, this interface must provide sufficient access to the

60

attention will be paid to creating “structure-aware” applications than attempting to add structure-awareness to existing applications. It should be noted that in the structural computing paradigm, open hypermedia is just a particular set of structural abstractions and services, no different from any other application domain.

jump to the associated thumb position, and, as a side effect, cause the application to display the content that was associated with the thumb position at the time the anchor was created. This is similar to work performed at Texas A&M in integrating hypermedia services into the text widget of the Athena UI toolkit [10]. The primary difference is that Anderson’s work explored the integration of hypermedia services into all of a toolkit’s widgets, not just the text widget. Anderson was motivated by Engelbart’s notion of “every object addressable” [11] that he used in NLS/Augment to make every item of a text document (down to a character) be able to serve as both the source and destination of a link traversal. The toolkit integration technique is therefore an attempt to provide pervasive hypermedia services in a graphical environment.

With respect to client-integration-in-the-large, structural computing is focusing on the development of new infrastructure that provide structure services to third-party applications. The argument of this paper is that there is still utility to be gained from integrating hypermedia services into existing infrastructures that may then in turn provide hypermedia functionality for their client applications. Since a structural computing infrastructure will most likely build on top of existing infrastructure layers, a conflict may occur if one of the foundational layers is integrated with an open hypermedia system. This points to the need for the ability to deactivate the provision of open hypermedia services by the integrated infrastructure on a per-client or global basis.

The technique’s architecture consists of a set of extended widgets and a set of common hypermedia services that these widgets employ to provide hypermedia functionality for their host applications. The extended widgets are in essence an instance of the wrapper technique since they act as intermediaries between an open hypermedia system and a client application. However, they share characteristics of the custom integration technique since they are tightly integrated into a client application and do not run in a separate executable process. Anderson reports on the use of the technique in integrating hypermedia services into multiple toolkits and multiple applications on top of these toolkits in [3]. The work reported in this paper builds on Anderson’s experience in integrating hypermedia services into UI toolkits to increase the understanding of issues that arise in infrastructure integration.

ISSUES OF CLIENT-INTEGRATION-IN-THE-LARGE

In this section, we present our approach to clientintegration-in-the-large and discuss issues encountered when attempting to support it. Our past work in infrastructure integration [1] has led to some important observations about relevant characteristics of the entire process of infrastructure integration. In order to be a suitable integration target, an infrastructure should have the ability to convey the results of its actions to a user. This is important since our goal with the integration is to provide hypermedia services of some kind to end-users. For navigational services, having an interface by which anchors can be created and links can be traversed is crucial. However, some integrations may focus support on nonnavigational services. For instance, an integration with a database system may focus on automatically generating links over the content stored within it. These links would then be made available to a user when viewing the content in their native (and hopefully integrated) applications.

Heterogeneous integration techniques, as demonstrated by the toolkit integration technique, serve as an important basis for achieving client-integration-in-thelarge. That is, these techniques should be used to integrate infrastructure mechanisms that in turn integrate large numbers of client applications without relying on the characteristics of a particular computing environment.

Discussion.

Another important characteristic is that the infrastructure’s core functionality is not compromised by performing the integration. That is, the infrastructure must continue to function normally after the integration even in the case when the integrated open hypermedia system is taken offline. Our goal is to augment the existing infrastructure with hypermedia services, not to make it dependent on them. Hand in hand with this characteristic is that clients of the infrastructure should be able to remain unaware of the integration if they so choose. As an example, the toolkit integration technique required a slight modification of applications in order for them to receive hypermedia services from the UI toolkit. In particular, they needed to switch from using the native toolkit widgets to using the newly-provided extended widgets. Any existing application that used the non-extended toolkit continued to function as normal after the integration.

Structural Computing

Structural Computing is a newly emerging field defined by the foundational papers of Peter Nürnberg [23-26] and the work presented at the First International Workshop on Structural Computing [22]. Structural computing “asserts the primacy of structure over data” [24] and posits the creation of a computing infrastructure that enables the specification of structural abstractions and the provision of services over those abstractions for use in third-party applications. Structural computing is, therefore, an attempt to capture and generalize the knowledge of the hypermedia community with respect to manipulating and providing services over structured information. Structural computing will certainly have to deal with issues of client integration to provide services to legacy applications, but its primary focus is providing a new paradigm for developing new applications. That is, more

This discussion leads us to an important characteristic of

61

structures that can be used to navigate the content stored in the information system. Our purpose is to enable the linking of content stored in these systems to other information reachable by an open hypermedia system in an automated fashion.

Extended widgets presented a small border around themselves to indicate their presence. Performance. How many infrastructures can be integrated

before the performance of a computing platform is adversely impacted? How much impact does an integration have on an individual infrastructure? With the toolkit integration technique, the greatest performance hit occurred during system initialization, since the hypermedia component had to spend time determining if the underlying open hypermedia system was on-line. Otherwise the userinterface toolkit performed as normal.

The key component in the Sanctuary system is a special kind of object called a mediator. The semantics of an integration process among a set of data sources, the operations and the data transformations performed on data from the data sources, and the accessing of the data sources are all captured within a mediator. The semantics of a particular mediator and its associated integration process are specified using a special-purpose programming language known as COIL. COIL specifications are used by the COIL compiler to automatically generate a mediator that provides the run-time mechanism for achieving the specified semantics.

Reusability. How much of the original infrastructure can be reused by the extensions? Achieving high reuse can speed the rate at which an integration can be performed. For instance, the toolkit integration technique was able to reuse the original toolkit widgets via object-oriented mechanisms when creating the extended widgets. Thus, the developer performing the integration focused on adding hypermedia services to the extended widgets and did not have to spend time implementing the functionality of the native widgets.

We focused our integration efforts on the COIL compiler and programming language. In particular, we extended the COIL programming language to allow developers to specify the terms used in queries by a target information system that would be mapped to open hypermedia anchors. The COIL compiler uses this information to generate a mediator that creates an anchor each time a particular value is supplied for one of the indicated terms. In addition, the COIL compiler can initiate a link traversal for each query using the generated anchors as source endpoints of the traversal. The compiler also generates code that allows a mediator to respond to a link traversal event. A link traversal that ends at a mediator leads to one of the generated anchors. The compiler associates the original query that generated the anchor as an attribute on the anchor. This attribute is used to re-execute the query, displaying the results of the query in the associated client. Finally, the compiler generates boilerplate code that handles such tasks as connecting to the underlying open hypermedia system, handling events from the open hypermedia system, and registering the mediator as a client of the underlying open hypermedia system. This code exhibits little variation between clients and thus is straightforward to generate for each mediator.

An additional aspect of reuse in client-integration-in-thelarge is how reusable can the hypermedia component be made? By its very nature, the OHP is amenable to reuse across multiple integrations. Therefore, the focus of this issue is on the reusability of the common hypermedia services. Again, the toolkit integration technique can supply experience with this issue. The toolkit integration technique was used to integrate two separate UI toolkits. In both cases the same code was used for the common services. Both toolkits were implemented using the Java programming language which certainly made it easier to reuse the code for the common services, but it would have been a straightforward programming exercise to translate the Javabased common services into another programming language using another UI toolkit, since modern UI toolkits provide highly similar sets of widgets. Scalability. If an application makes use of two integrated

infrastructures how will the hypermedia services provided by the two infrastructures be coordinated? We unfortunately do not have experience with this situation to provide insight into this issue.

We applied our integration to an example client that was previously constructed for demonstrating the abilities of the Sanctuary environment. The example concerns an on-line bookstore that provides capabilities such as retrieving detailed information about a specified book, retrieving books by a specified author, searching for books that match specified keywords, etc. The architecture of the example consists of a client and a set of heterogeneous data stores. The client is used to enter queries into the on-line bookstore and to display the results of those queries. The heterogeneous data stores consist of a relational database that keeps track of the inventory for the on-line bookstore, a legacy flat-file database of books and a more advanced book database stored in an object-relational database. The mediator for the example allows the clients to make queries about items in the bookstore without being aware that the

INTEGRATING INFRASTRUCTURE: AN EXPERIMENT

We developed an experimental integration to gain further insight into the issues of client-integration-in-the-large. We selected a middleware system called Sanctuary [31]. Sanctuary is a data source integration and evolution environment for supporting the construction of large-scale systems that integrate heterogeneous data sources. A successful integration with Sanctuary would allow hypermedia services to be provided to a class of applications that normally do not provide such capabilities, i.e. information systems that are centered on a search and query interaction style. Note that Bieber has explored work in this area [5] but his focus is on converting the elements of the underlying schemas of such systems into hypermedia

63

5. Bieber, M. (1995). On Integrating Hypermedia into Decision Support and Other Information Systems. Decision Support Systems, 14: 251-267. 6. Bouvin, N. O. (1999). Unifying Strategies for Web Augmentation. In Proceedings of the Tenth ACM Conference on Hypertext, pp. 91-100. Darmstadt, Germany. 7. Carr, L. A., DeRoure, D. C., Hall, W., and Hill, G. J. (1995). The Distributed Link Service: A Tool for Publishers, Authors, and Readers. In Proceedings of the Fourth International World Wide Web Conference, pp. 647-656. Boston, MA, USA. December 1995. . 8. Davis, H., Reich, S., and Millard, D. (1997). A Proposal for a Common Navigational Hypertext Protocol. . 9. Davis, H. C., Knight, S., and Hall, W. (1994). Light Hypermedia Link Services: A Study of Third Party Application Integration. In Proceedings of the Sixth ACM Conference on Hypertext, pp. 41-50. Edinburgh, Scotland. September 18-23, 1994. 10. Drufke, J. E., Jr., Leggett, J. J., Hicks, D. L., and Schnase, J. L. (1991). The Derivation of a Hypertext Widget Class from the Athena Text Widget. TAMUHRL 91-002. Texas A&M University. 11. Engelbart, D. C. (1991). Knowledge-Domain Interoperability and an Open Hyperdocument System. Pages 397-412 in E. Berk and J. Devlin, Eds., Hypertext/Hypermedia Handbook. McGraw-Hill. 12. Garrido, A., and Rossi, G. (1996). A Framework for Extending Object-Oriented Applications with Hypermedia Functionality. The New Review of Hypermedia and Multimedia: Applications and Research, 2: 25-41. 13. Grønbæk, K., Bouvin, N. O., and Sloth, L. (1997). Designing Dexter-Based Hypermedia Services for the World Wide Web. In Proceedings of the Eighth ACM Conference on Hypertext, pp. 146-156. Southampton, UK. April 6-11, 1997. 14. Grønbæk, K., and Trigg, R. (1994). Design issues for a Dexter-Based Hypermedia System. Communications of the ACM, 37(2): 40-49. 15. Haake, A., and Hicks, D. (1996). VerSE: Towards Hypertext Versioning Styles. In Proceedings of the Seventh ACM Conference on Hypertext, pp. 224-234. Washington DC, USA. March 16-20, 1996. 16. Hall, W., Davis, H., and Hutchings, G. (1996). Rethinking Hypermedia: The Microcosm Approach. Kluwer Academic Publishers, Norwell, MA, USA. 17. Hicks, D. L., Leggett, J. J., Nürnberg, P. J., and Schnase, J. L. (1998). A Hypermedia Version Control Framework. ACM Transactions on Information Systems, 16(2): 127160.

field is still in its infancy with only a few experimental prototypes to provide insight into a standard set of methods and tools for designing and constructing the proposed infrastructure. Therefore it is reasonable to pursue the development of techniques that will lead to a significant increase in the number of open hypermedia clients. These applications will then have taken a small step towards possible integration into a structural computing environment when the proposed structural computing infrastructure becomes a reality. Second, there will always be a significant set of legacy applications that may not be upgraded to become “structure-aware” either because the cost is too high or the required changes are such that conversion would be infeasible. Integrating these applications through the use of client-integration-in-the-large techniques could represent a more cost effective, or incremental, approach to providing information organization capabilities within them. Our research has provided the basis for an approach to integrating open hypermedia services into multiple types of infrastructure. We have identified issues that come into play when attempting integrations of this sort and used our experience in developing two infrastructure integrations to provide insight into those issues. We believe that developing the area of client-integration-in-the-large will lead to techniques that can significantly increase the number of clients that make use of open hypermedia services and thereby increase the utility and applicability of this approach to information organization to a wide range of end-users. ACKNOWLEDGMENTS

Amy Pearl, Hugh Davis, Jim Whitehead, and Uffe Wiil have all made significant contributions to the open hypermedia community’s understanding of client integration issues. Our work would not have been possible without their foundational contributions to this area. REFERENCES

1. Anderson, K. M. (1997). Extending User-Interface Toolkits with Hypermedia Functionality. In Proceedings of the 30th Hawaii International Conference on System Sciences, Vol. 6 Digital Documents, pp. 197-206. Wailea, Hawaii, USA. January, 1997. 2. Anderson, K. M. (1997). Integrating Open Hypermedia Systems with the World Wide Web. In Proceedings of the Eighth ACM Conference on Hypertext, pp. 157-166. Southampton, UK. April 6-11, 1997. 3. Anderson, K. M. (1997). Pervasive Hypermedia. Ph.D. Dissertation. Information and Computer Science. University of California, Irvine. 4. Anderson, K. M., Taylor, R. N., and Whitehead, E. J., Jr. (1994). Chimera: Hypertext for Heterogeneous Software Environments. In Proceedings of the Sixth ACM Conference on Hypertext, pp. 94-107. Edinburgh, Scotland. September 18-23, 1994.

65

28. Pearl, A. (1989). Sun's Link Service: A Protocol for Open Linking. In Proceedings of the Second ACM Conference on Hypertext, pp. 137-146. Pittsburgh, PA, USA. November 5-8, 1989. 29. Puttress, J. J., and Guimaraes, N. M. (1990). The Toolkit Approach to Hypermedia. In Proceedings of the European Conference on Hypertext, pp. 25-37. Versailles, France. November, 1990. 30. Smith, J. B., and Smith, F. D. (1991). ABC: A Hypermedia System for Artifact-Based Collaboration. In Proceedings of the Third ACM Conference on Hypertext, pp. 179-192. San Antonio, Texas, USA. December 15-18, 1991. 31. Todd, J., Och, C., King, R., Osborne, R. M., and McIver, W. J. (1999). Building Mediators from Components. In Proceedings of the International Symposium on Distributed Objects and Applications, pp. 352-362. Edinburgh, Scotland. 32. Whitehead, E. J., Jr. (1997). An Architectural Model for Application Integration in Open Hypermedia Environments. In Proceedings of the Eighth ACM Conference on Hypertext, pp. 1-12. Southampton, UK. April 6-11, 1997. 33. Whitehead, E. J., Jr. (1999). Control Choices and Network Effects in Hypertext Systems. In Proceedings of the Tenth ACM Conference on Hypertext, pp. 75-82. Darmstadt, Germany. February 21-25, 1999. 34. Wiil, U. K., and Leggett, J. J. (1996). The HyperDisco Approach to Open Hypermedia Systems. In Proceedings of the Seventh ACM Conference on Hypertext, pp. 140148. Washington DC, USA. March 16-20, 1996. 35. Wiil, U. K., and Leggett, J. J. (1997). HyperDisco: Collaborative Authoring and Internet Distribution. In Proceedings of the Eighth ACM Conference on Hypertext, pp. 13-23. Southampton, UK. April 6-11, 1997. 36. Wiil, U. K., and Leggett, J. J. (1997). Hyperform: A Hypermedia System Development Environment. ACM Transactions on Information Systems, 15(1): 1-31. 37. Yankelovich, N., Haan, B. J., Meyrowitz, N., and Drucker, S. (1988). Intermedia: The Concept and the Construction of a Seamless Information Environment. IEEE Computer, 21(1): 81-96.

18. Hill, G., and Hall, W. (1994). Extending the Microcosm Model to a Distributed Environment. In Proceedings of the Sixth ACM Conference on Hypertext, pp. 32-40. Edinburgh, Scotland. September 18-23, 1994. 19. Jeffay, K., Lin, J. K., Menges, J., Smith, F. D., and Smith, J. B. (1992). Architecture of the Artifact-Based Collaboration System Matrix. In Proceedings of the 1992 ACM Conference on Computer-Supported Cooperative Work, pp. 195-202. Toronto, Canada. October 31-November 4, 1992. 20. Kacmar, C. (1995). A Process Approach for Providing Hypermedia Services to Existing, Non-Hypermedia Applications. Electronic Publishing: Organization, Dissemination, and Distribution, 8(1): 31-48. 21. Meyrowitz, N. (1989). The Missing Link: Why We're All Doing Hypertext Wrong. Pages 107-114, The Society of Text: Hypertext, Hypermedia, and the Social Construction of Information. MIT Press. 22. Nürnberg, P. J. (1999). First International Workshop on Structural Computing. . 23. Nürnberg, P. J., and Leggett, J. J. (1998). A Vision for Open Hypermedia Systems. Journal of Digital Information, 1(2). . 24. Nürnberg, P. J., Leggett, J. J., and Schneider, E. R. (1997). As We Should Have Thought. In Proceedings of the Eighth ACM Conference on Hypertext, pp. 96-101. Southampton, UK. April 6-11, 1997. 25. Nürnberg, P. J., Leggett, J. J., Schneider, E. R., and Schnase, J. L. (1996). Hypermedia Operating Systems: A New Paradigm for Computing. In Proceedings of the Seventh ACM Conference on Hypertext, pp. 194-202. Washington DC, USA. March 16-20, 1996. 26. Nürnberg, P. J., Wiil, U. K., and Leggett, J. J. (1998). An Agenda for Open Hypermedia Research. In Proceedings of the Ninth ACM Conference on Hypertext, pp. 198206. Pittsburgh, PA, USA. June 20-24, 1998. 27. Østerbye, K., and Wiil, U. K. (1996). The Flag Taxonomy of Open Hypermedia Systems. In Proceedings of the Seventh ACM Conference on Hypertext, pp. 129-139. Washington DC, USA. March 16-20, 1996.

66