Draft v0.3, March 21, 1997
URL: http://www.ics.uci.edu/~ejw/hidden/white_paper.html
This document provides a guide which can be used in the selection of hyperprogram technology available today within the Information Management cluster of EDCS. This document provides an overview of the goals of EDCS hyperprogram technology development, a high-level description of existing capabilities, brief scenarios of usage, definitions of terms, a comparison matrix, and a rich set of links which can be used to retrieve software and additional information. This guide can be used to assess and locate existing hyperprogram technology developed by the Information Management cluster of the EDCS program, allowing other researchers to use this technology within their own projects, and identify potential collaboration partners. This, in turn, will foster greater coordination among the research activities of EDCS.
Technologies discussed within this guide are:
Hyperprogram capability, the addition of hypermedia linking and traversal to software development, is a key component of the Evolutionary Design of Complex Software (EDCS) program. This document provides an overview of the goals of EDCS hyperprogram technology development, and provides a guide which can be used in the selection of hyperprogram technology available today within the Information Management cluster of EDCS. This guide includes a high-level description of existing capabilities, brief scenarios of usage, definitions of terms, a comparison matrix, and a rich set of links which can be used to retrieve software and additional information.
The goals of EDCS hyperprogram technology are to develop:
Many of these capabilities are available today both for use developing EDCS projects, and for embedding or integrating within EDCS technologies. They include:
Chimera Open Hypermedia System
Chimera is an open, serverized, hypermedia system that supports n-ary links between heterogeneous tools and applications in a network. This site includes the 1.2 and 2.0 release of Chimera, on-line documentation, a set of Chimera clients, and Chimera APIs in Ada, C, and Java. Many popular tools have been integrated with Chimera, including FrameMaker, XEmacs, Xvi, Xgif, and Mosaic.
Chimera currently can be used as a general-purpose hypermedia infrastructure within any environment. In software development environments, Chimera can be used to augment existing tools with hypermedia capability. While using their existing tools (such as XEmacs and FrameMaker), a software developer can capture the relations between their software development artifacts by creating links which may be quickly traversed at a later time. Over time, these links create a rich hypermedia web which allows rapid navigation between related artifacts in a software project.
Eventually, users of a hyperprogram environment will have access to three types of links: explicitly created links among software development artifacts and resources, automatically generated links, and implicit links. Explicit links are supported by current Chimera technology; support for the remaining two will be added during later phases of the EDCS project.
OzWeb
OzWeb 0.45 includes three major parts: the OzHTTP proxy server, the OzWeb server, and an HTML-based GUI. The OzHTTP proxy is multi-threaded, servicing any number of WWW browsers/tools, and can be daisy-chained with arbitrary HTTP proxies, e.g., supporting caching or an organizational firewall. Currently a given OzHTTP proxy is connected to a particular OzWeb server, in which it looks up every requested URL. If the OzWeb server indicates that it contains that URL, the request is redirected to OzWeb; otherwise, the request is sent to the appropriate website server as for any other HTTP proxy. A future version will use LDAP (the public-domain Lightweight Directory Access Protocol) to support lookup among multiple OzWeb servers, and support movement among OzWeb servers following a MUD (Multi-User Domain) metaphor.
An OzWeb server includes at least a Xanth subweb and, optionally, a set of groupspace services. Xanth consists of an object-oriented database (OODB) and a protocol interface. The protocol interface turns Xanth into an open, general-purpose hypermedia server via a variety of frontend client protocols and backend repository protocols, each providing callback functions fulfilling a predefined API. The current HTTP frontend client protocol supports the HTML GUI. The current HTTP backend repository protocol defines the operational behavior of (subclasses of) the WebObject superclass, which correspond to URLs referring to WWW entities. We plan Chimera (from UCI) and CORBA (Xerox PARC ILU and IONA Orbix) protocols supporting ChimeraObjects and CORBAObjects superclasses, resp. This would permit, e.g., the user of a Chimera viewer to follow a link through the Chimera server and from thence through the Xanth subweb server to a WWW entity or a CORBA object, and vice versa, with groupspace services imposed before and after.
OzWeb groupspace services support users collaborating together on subweb data, initially through the Amber process enactment engine, the Pern cooperative transaction manager, and the Rivendell tool manager. Amber and Pern were inherited from the Oz process-centered environment; the only significant extensions were to add read and write of object file attributes as built-in operations that can be overloaded based on object type. Amber supports processes operating over Xanth hypermedia based on Oz-like rules. We plan to integrate Amber with Endeavors (from UCI) to provide higher-level visualization and control based on task graphs. Pern supports both conventional and semantics-based transactions over subweb hypermedia.
Rivendell consists of a cooperating collection of peer tool servers and personal tool servers. When a Rivendell tool server starts up, it exchanges configuration information including the tools it can launch locally with its known peers on remote hosts. Tools are invoked through scripts, which may also combine several tools into a single activity, convert data formats, initialize environment variables, manage temporary directories, etc. A personal tool server is affiliated with a user's WWW browser through a new MIME type and runs on that user's machine. One tool server is associated with every groupspace, running on the same host as the OzWeb server, but its peers may run stand-alone.
WebSoft: Building a Global Software Engineering Environment
The WebSoft suite of tools and technologies is a continually expanding base of World Wide Web software to support collaborative software engineering on a global scale. This includes the wwwstat HTTP access log analysis tool, the multi-owner maintenance spider (MOMspider) for automating coherency analysis of distributed hypermedia webs, and the WWW client protocol library for the Perl language.
World Wide Web Distributed Authoring and Versioning (WEBDAV)
The WEBDAV working group of the Internet Engineering Task Force, led by EDCS/UCI, is actively guiding efforts to standardize Web distributed authoring and versioning capability. Encompassing functionality such as locking, name space management, versioning, metadata, and link creation, WEBDAV provides an infrastructure which can be used for collaborative, distributed software development. Web distributed authoring and versioning capabilities which do not conform to the WEBDAV standard are available today from several vendors of Web technology.
Distributed Authoring and Versioning is moving the Web away from being just a medium for publishing content which is then browsed, towards a new frame of reference where the Web is a globally distributed read/write medium, enabling easy collaboration among groups. Since Distributed Authoring and Versioning works on all media types, not just HTML, mainstream applications such as text editors, programming environments, word processors, and spreadsheets are able to perform distributed reads and writes over the Web. Collaboration between members of the same or different organizations is easy, due to widespread use of the same standard protocol for remote access, locking, versioning, and writing of shared documents, which are edited using traditional mainstream applications. Augmented with WEBDAV functionality, the Web becomes a simple, globally distributed, versioned filesystem, ready for a wide range of collaborative uses.
Distributed Authoring and Versioning offers much promise for providing a standard collaboration framework, supported by interoperable products from many vendors, which could be used by the widely distributed members of real or virtual software development organizations to develop software. By setting up a Distributed Authoring and Versioning capable Web server with all members of the (virtual) organization authorized to write to the server, the Web server can be used like a simple network filesystem. Members from around the globe can use their local applications to edit documents on the remote server. Using this technology, out-of-office or telecommuting workers can work collaboratively on documents stored at the home office.
This section describes scenarios of end-user use of the EDCS hyperprogram technology described in this document.
Evolution of Legacy Software
Jay, a software engineer at Rayheed Marthrop, has been assigned the task of performing software maintenance on the control software of the Striker missile, as part of the Striker-NG project. His task is to write a new device driver for the missile's gyroscope, which is being upgraded to better withstand new anti-missile technology. New to the Striker missile project, Jay decides to educate himself about the project, and its gyroscope related requirements.
Jay begins by launching his web browser, and browsing the corporate intranet. Performing a search of the intranet, he quickly discovers the original Striker project home page, maintained as a repository of corporate memory on the Striker missile. From the Striker project home page, Jay reads an overview of the project and available documentation, and also finds a link to the new Striker-NG project home page. Jay reads the requirements document for the original Striker missile project, and the updated requirements for the Striker missile upgrade project he is working on. While reading the requirements document, Jay occasionally follows links to external Army Web sites for information on the rationale and management of the Striker missile, and to Web sites of Striker subcontractors for information on their technologies. These links are still up-to-date because the Striker missile site has been maintained using MOMspider, which detects and reports broken links. Jay also follows links to design documents, which are maintained in FrameMaker files, and FrameMaker is launched automatically to display these documents. Jay easily follows links into these FrameMaker files, and just as easily follows links back out to Web content displayed by his browser.
Once he has learned about the new Striker missile requirements, and has followed hypertext links from the requirements, to the design, to the actual code, Jay begins his maintenance work. Using OzWeb, Jay locks a code file, and then begins editing it using XEmacs. While modifying the code, Jay creates anchors in the code files, and then creates links which capture relationships between the modified code and the Striker-NG requirements. While writing code, Jay follows links from his text editor to other documents as needed, to answer questions which arise during development. While working, Jay is unaware that he has created and followed links using Chimera, and has accessed and locked a file with an OzWeb repository.
Jay compiles his source code by starting an OzWeb compilation process. The compiler doesn't have any interactions with the hypertext links in the source code because the anchors and links are not embedded within the object -- to the compiler, they are literally not there, stored instead inside the Chimera hypermedia repository. Analysis tools similarly experience no adverse interactions when hypermedia functionality is added to Jay's development environment.
At the end of each week of work, Jay produces a status report, which he writes using the Amaya HTML authoring tool, and then saves directly to his departmental Web server, running the Jigsaw server. Using this Web distributed authoring technology, Jay's status reports are edited directly on the Web, and are immediately visible to his section leader and his program manager.
Though Jay continues to work for several weeks, the scenario ends here. It has showed how Jay can quickly find existing information on his project by traversing a hypermedia web which was developed during the original Striker missile contract, and was able to evolve the Striker code during the Striker-NG project by following these existing links, and creating new links as needed. During this project, Jay has used the following hyperprogram technologies: standard HTTP/1.1 Web browsers and servers, OzWeb, Chimera, and MOMspider.
This section provides definitions of terminology along with common issues which are frequently encountered when working with hyperprogram technology.
Several architectures can be used to support hyperprogram technology. Within the confines of a software development environment all that is required is a sophisticated data structure which maintains a model of the artifacts it creates and the relationships between them. However, this architecture while fine to service the hypermedia needs of a suite of tightly-integrated tools, it is inadequate to scale up to meet the needs of a heterogeneous computing environment filled with multiple tools, information, users and processes.
Two principle architectures have been used to date by systems attempting to support the stated goals of hyperprogram technology. The former is known as the link server approach while the latter is known as the distributed link data approach. Both approaches are now discussed and compared.
The link server approach to hypermedia systems is based on cooperation between a link server and a set of clients. The clients manage the display of, and user interaction with, graphical views of resources (i.e., entities or objects) in a hyperweb; the link server manages the persistence of hypermedia information, such as links and anchors associated with each resource. A hypermedia traversal event generated by a client is translated to a query on the link server, which responds by activating the semantics associated with the traversed link. This separation of concerns allows the link server to be independent of the nature (i.e., data type) of the resources contained in a hyperweb, allows dynamic binding of link traversal semantics (actions performed by the hypermedia system in response to the link traversal), and minimizes the amount of hypermedia functionality duplicated within each client implementation.
Because in the link server approach the links and link semantics are centrally located, the link server can easily provide for management of link consistency, analysis of dependencies between resources, and a coherent representation of the state of the hyperweb as it evolves. In addition, the separation of links from the linked resources allows anchors to be assigned without modifying the resources themselves, which is a necessity when the user does not have write-access to the resource, or when the data type of the resource has no built-in support for hypermedia anchors. It also allows links to be treated as first-class objects, in the sense that links can be grouped, analyzed, and referenced independent of the linked resources. However, the same conditions of centrality introduce problems in regard to scalability, constraints on distribution of linked resources, the inability to modify links and linked resources external to the hypermedia environment, and a single point of failure for hyperweb usability.
The distributed link data approach used by the World-Wide Web is based on standardizing the identification of, and interfaces between, linked resources, and having the resources themselves define the link anchors and traversal semantics. Links and anchors are embedded within the standard data types, so that once a resource is retrieved, all of the information needed to perform subsequent link traversal is available. This approach emphasizes the use of a few specific data types (e.g., HTML) and access protocols (e.g., HTTP), requiring the client software to perform all hypermedia functionality other than storage, and thus freeing the server for greater scalability. At the same time, distributing the link information to each resource allows each subsection of the hyperweb to be independently accessible and available for use, even when the user is isolated from the rest of the Web. Furthermore, it allows hypermedia resources to be created and modified by tools which may be completely unaware of the hypermedia environment, resulting in a pervasive distribution of information content.
The weaknesses of the distributed link data approach are in those areas where the link server approach has strength. In the WWW, data types not suited for link embedding can be the destination of hypermedia traversals, but not the initiator of a link; the information must first go through a data conversion process in order for such data to become hypermedia-aware. Likewise, the only method for analyzing links (and thus resource dependencies) in a distributed link data system is to actively traverse the hyperweb, either manually or with the assistance of software agents (e.g., web spiders). This limits the system's ability to maintain referential integrity when resources change, ability to assist the user in the navigation and visualization of the hyperweb, and ability to predict the effects of a change before it is made.
The implications of these architectures for the EDCS community is to develop techniques for harnessing the power of both approaches within hyperprogram systems. Leveraging the strengths of each technique will produce systems which scale to large problem domains while producing hyperwebs which can be evolved and maintained effectively by their end-users. One important avenue for this integration of the two techniques is to explore ways to make hyperprogram systems interoperable. In fact, in the open hypermedia systems community an effort known as the Open Hypermedia Protocol is working to develop a protocol to enable interoperability of link server systems from the client's perspective. That is, a client utilizing the open hypermedia protocol (OHP) would be able to access hypermedia services from any OHP-compliant link server. This work is still in its infancy but it provides one example of the potential benefits of interoperability.
An effort similar to the OHP in its aims, the Open Document Management API (ODMA) is in current widespread use by the document management community for interoperability between a wide range of third party client applications and all major document management systems. A follow-on effort, the DMA 1.0 specification, has attempted to repeat the success of the ODMA specification, but for a much broader range of functionality. This second specification is between one and two orders of magnitude larger than the original ODMA specification, and it is unclear whether it will ever be successfully fielded.
Another approach to leveraging the potential of the two architectures is to define a single conceptual API to hypermedia services and then provide mechanisms which configure the selection of the API's implementation by one or more systems which support one or both of the architectures. It remains an open research question whether this approach can adequately provide hypermedia services to a broad range of client applications. However, as a limited proof-of-concept, Chimera 1.2 defines a single language-independent API which is then deployed in multiple programming languages (Ada, C, and Java). This deployment occurred manually with an experienced Chimera developer implementing each separate language-specific API. What is now required is the ability to generate these implementations automatically and with more dimensions than just programming language provided (i.e. different implementations can be provided for clients communicating with a hypermedia system across a WAN than for a LAN, etc.).
The hyperprogram technology comparison matrix is intended to give a quick overview of the features of various systems which offer hyperprogram-like capabilities. Below, a description of the categories used to differentiate the target systems is presented. The matrix follows this description. Each system is linked to its respective web site, when possible.
The hypermedia model of a system is the set of concepts and abstractions employed to map hypermedia structures over a set of information. A brief description of each system's model will be included in the matrix.
Secondary categories within this topic are listed next.
This category considers whether the hypermedia model includes elements which typically are not thought of as standard hypermedia concepts, such as clients, but which enable the accurate modeling of the hypermedia system's external environment at run-time.
Links as first-class objects within the model enable the hypermedia system to store links separately from the data they link and provide operations which query and modify their state. This category asks questions like: Does the hypermedia model treat links explicitly or implicitly? If explicitly, does it provide link types? Can the semantics of link traversal be controlled by client applications?
For those hypermedia models with first-class links, can the links include an arbitrary number of anchors or is it limited to just two anchors per link? n-ary links enable groups of related items to be modeled accurately and stored more efficiently than creating binary links between each member of the group.
The characteristics of clients supported by the hypermedia system is important information since they bound the range of applications which can be integrated with the system. What are the characteristics of the clients supported by the hypermedia model? Can a client be multi-threaded? Must it meet certain standards? Can it be an applet? Does it have to store its data in a specific place or format?
The ability to support distribution of information is a key aspect of scalability. For instance, hyperbase systems provide a database to store both client data and hypermedia structures. Some hyperbase systems provide databases stored locally while others are internally distributed and replicated. How does the hypermedia system distribute its hyperwebs and the data it links? Must all data reside locally? Can a hyperweb be stored remotely?
While distribution is one aspect of scalability, other dimensions exist which determine how well a hypermedia system scales to handle real-world tasks. How many simultaneous clients can a hypermedia system support? How large can hyperwebs grow? Are there performance bottlenecks in the architecture?
Integrating third-party applications is a desirable feature of hypermedia systems. Users are unwilling to abandon the tools they use now to gain hypermedia features. As such, hypermedia systems should come to them by integrating the tools they use to perform work. Thus, what mechanisms does a hypermedia system provide for integrating third-party applications, such as Adobe FrameMaker or Microsoft Word?
Asynchronous event generation is an important technique for enabling collaboration and implementing link traversal. An integrated client can provide event handlers to modularize the code used in implementing certain hypermedia services. Other events can supply users with awareness information of the actions other users are performing in the hyperweb. Does the hypermedia system generate events? If so, what are the different event types possible?
While event generation provides the basis for collaboration, other features such as session management and synchronization mechanisms are needed to fully enable it. Collaboration features enables the support of work performed by teams, a key goal of the EDCS program. Thus, does the hypermedia system provide support for collaboration? Can users work both synchronously and asynchronously?
The World Wide Web is the largest hypermedia system in deployment today. It provides a relatively simple set of hypermedia services which nevertheless effectively scales to handle large real-world problems. Hyperprogram technology can integrate with the WWW in two principle ways. The first is to increase the quality or the ability of the Web with respect to the hypermedia services it provides. The second is to take advantage of the Web's protocols within the hyperprogram system so as to gain the robustness and scalability benefits they provide. Thus, this category serves to illuminate the ways in which a hypermedia system interacts with the World Wide Web.
In order to scale to large software engineering projects, the hyperprogram system should have the ability to automatically generate links on the artifacts developed by the software development process. There are potentially millions of links which could be created or computed, and no single engineer or development team would have the time or inclination to hand generate them. Thus, what mechanisms are provided to facilitate automatic link creation?
One simple technique for increasing the range of clients which can be integrated with a hypermedia system is to provide access to its API in multiple programming languages. Thus, an important question is what language bindings exist for a hypermedia system's API?
A related issue to supporting multiple programming languages is supporting multiple platforms. The more platforms for which a software is deployed, the more clients can be potentially integrated. Thus, can the hypermedia system operate on multiple hardware/OS platforms?
| Hyperprogram Technology Comparison Matrix | |||||
|---|---|---|---|---|---|
| Category | Chimera 1.2 | Chimera 2.0 | OzWeb 0.45 | WWW | |
|
Description | Chimera's hypermedia model consists of viewers, objects, views, anchors, and links. Each of these concepts can have an arbitrary number of attribute-value pairs associated with them. A hyperweb is composed of persistent instances of these concepts and is stored separate from the hypermedia content it links. Viewers are applications which browse and edit objects. Views are the graphical depictions viewers generate of their objects. Anchors are associated with views, and links are sets of anchors. | The same as Chimera 1.2 with two additions. Anchors can now be associated with objects as well as views. The former are known as view-independent anchors and should be displayable by any viewer which supports the object's data type. The latter are known as view-specific anchors and can only be displayed by the viewer which created it. In addition, objects can now be added to other objects to form composites. This is useful for situations in which an application's views are generated based off of information from multiple objects. | OzWeb's hypermedia model is implemented by Xanth. Xanth supports an arbitrary collection of primitive and file attributes of objects, and composite and reference links among objects, all external and orthogonal to any attributes and links embedded in the object content. Objects are typed via multiply inherited classes, which specify types for attributes and links (possibly the universal ENTITY class for the latter). Links are unidirectional but can be traversed in the reverse direction via Xanth's object-oriented query language. | The WWW's hypermedia model is provided by the data type transferred between servers and clients. Currently, HTML is the most common such data type, although others exist such as Adobe's PDF. HTML provides a simple model which embeds hypermedia anchors into the information being presented. These anchors act as uni-directional links by containing a pointer within them which specifies their destination. |
| Model of the External World | Chimera 1.2 concepts include elements to track the applications in its environment, their objects, and the views they generate of these objects. This information enables it to accurately track these entities at run-time, invoke needed applications, and provide awareness information to its end-users. | Chimera 2.0 has the same features of Chimera 1.2 while adding support for the remote distribution of objects and hyperwebs. This additional support comes from increased use of WWW protocols such as HTTP and URL. | Xanth supports native OODB objects and definition of new classes of objects, the latter's implementation (backend repository and access/update) supplied via dynamically loaded protocol modules. An HTTP protocol module is fully functional, and Chimera and CORBA modules are being developed. Links can be created and traversed among objects substantiated by different protocols. | The WWW has limited support for external entities within its model. HTTP is able to transfer information of any type between its clients and servers. WWW clients can invoke external applications to handle unknown data types. The services of proxies are defined without specifying the exact form a proxy must take. | |
| Links as First-Class Objects | Yes. Links are first-class entities with multiple operations available. Links can have types assigned to them via attribute-value pairs. Only three types of link traversal are provided. | Yes. Links are essentially unchanged from Chimera 1.2 except that clients can now specify their own link traversal algorithms to be used for traversals they initiate. | Yes and No. Xanth links are not first class objects, however they may be retrieved through queries and modified at any time. However, Xanth objects may represent links in an external protocol. | No. Links are not directly specified by HTML. WWW Clients implement bi-directional links by keeping track of the pages a user visits. | |
| n-ary links | Yes. Links are modeled as sets. | Yes. Links are modeled as sets. | Yes and No. Xanth links may be 1-to-N but are directional and thus not sets in the Chimera sense. However, set n-ary links in an external protocol can be represented by a Xanth object. | No. Only uni-directional linking is supported by HTML. | |
| Client Characteristics | Chimera 1.2 makes a distinction between the notion of client and the notion of viewer. It then places separate requirements on both notions. The definition of a client is that it contains one or more viewers and provides those viewers with access to the Chimera API. As long as the client meets these requirements, all other aspects of a client are free to vary. The Chimera 1.2 API is currently available for the programming languages of Ada, C, and Java. | Same as Chimera 1.2. However, due to the relative infancy of Chimera 2.0, except for a few API operations available via HTTP, a complete API to the servers is only available in Java. APIs for other programming languages will be made available as the project matures. | Native Oz XView, Motif and tty (command line) clients are supported by OzWeb. Xanth enables dynamic loading of protocol modules for frontend clients. The HTTP/HTML browser client module is in active use, although we plan to replace it with a more sophisticated Java-based GUI. Chimera and CORBA frontend modules are in progress. | The standard protocols define the requirements an application must meet in order to be a WWW client. All aspects of a client unrelated to satisfying the protocols are left undefined. This enables a wide range of client types, although typically clients follow the monolithic browser model. | |
| Distribution of Data | Chimera stores its hyperwebs on a networked file system available to the server. Chimera's clients are free to store their data in any location, local or remote. Clients typically use filenames as object names. | The same as Chimera 1.2 except that client data which has an associated URL can potentially be included for display in a WWW client when the server is handling HTTP requests for information on the contents of a hyperweb. | Native Xanth objects are currently stored in a centralized objectbase, one objectbase per OzWeb environment instance, although we are working on alliances among OzWeb servers similar to those supported by Oz. Protocol object instances are cached by Xanth, but may reside in any respository anywhere on the Internet supported by a backend protocol module. For example, HTTP web objects can reside at any HTTP/WWW server. | Data can be stored in any location which has an associated URL. This assumes that a WWW server is available to handle the HTTP request for the URL, retrieve the data and then return it to the client. | |
| Scalability Issues | Chimera's hyperwebs have been stress-tested with programs which create and then manipulate webs containing tens of thousands of instances of Chimera's hypermedia concepts. However, the Chimera server can be slowed by multiple users accessing it simultaneously due to its centralized nature. | Chimera 2.0 addresses the bottleneck issues of Chimera 1.2 along with some other problems. Chimera 2.0's hyperwebs can be distributed anywhere on the Internet, and it is now easier to share information between them, lessening the need for storing all hypermedia information in a single hyperweb. Chimera 2.0's chimera server runs locally in a user's environment and services the clients for only a single user. This increases the performance for the end-user while shifting the bottleneck issue to the hyperweb server. However, with the ability to store hyperwebs in separate websites, the load on any one hyperweb server is less than with a centralized model. In addition, the hyperweb server is multi-threaded and configured to handle multiple connections in parallel, mitigating the effects of the bottleneck. | Scalability is limited in the current realization by the centralized server. Oz-like alliances among servers are intended to address this problem. | The WWW was built with scalability issues tackled early in its design. The standard protocols are designed with extensibility mechanisms. Web servers can handle seventy to one hundred connections in parallel per second. In addition, a site can have several Web servers running at once waiting to service connections to a particular site. Finally, the ability to access data stored anywhere on the Internet lessens the need for storing the data locally. | |
| Third-Party Application Integration | Chimera 1.2 provides a levels-of-integration framework which aides the integration process of third-party applications by modeling the key aspects of a client integration. In particular, the three levels of integration are launch-only, wrapper, and custom. The latter two involve the use of Chimera's API. | Same as Chimera 1.2 with the addition that Chimera 2.0's support of HTTP adds one additional mechanism for integration. In addition, research is being performed in the area of integrating user-interface toolkits with Chimera in order to provide hypermedia services to applications built with the toolkit. This toolkit approach can greatly lower the developmental effort associated with integrating applications with a hypermedia system. | OzWeb's application launching facility is implemented by Rivendell. Rivendell supports wrapping of tools operating on the contents of arbitrary Xanth objects via Shell scripts and potentially other scripting languages, and invocation of tools on either the user's host or an appropriate local or remote tool server machine. Xanth supports integration of external applications compliant with protocol modules, generally invoked through their own mechanisms (perhaps using the Rivendell component). Additional groupspace services can, in principle, be added to OzWeb beyond the built-in process/transaction services and Rivendell. | Clients must support some aspect of the WWW's standard protocols in order to achieve integration. Otherwise, WWW browsers can be configured to launch applications in response to certain data types, however these applications have no hypermedia services. | |
| Event Generation | Chimera 1.2 allows clients to register interest in particular types of events. When an event occurs, the server sends an event notification to all clients interested in the event. This is true for all event types except link traversal. Link traversal events are necessarily directed to specific destinations. | Same as Chimera 1.2 except that the number of event types available has increased. | Various events, potentially including read, write, link, unlink, add, delete, etc. of backend data corresponding to Xanth object instances, trigger OzWeb groupspace services. In particular, process task conditions (prerequisites) and effects (consequences or implications) are applied to each event, perhaps triggering backward and/or forward chaining to guide users to initiate or automatically initiate other tasks. | None. | |
| Support for Collaboration | Event notifications serve as minimal form of awareness between users working on the same hyperweb. | Improves on Chimera 1.2's support by adding a locking mechanism which enables user's to lock portions of a hyperweb for editing. | OzWeb process models may define synchronization among concurrent tasks and delegation of tasks from one user to another. Conventional atomic/serializable transaction groupings and/or application-specific concurrency control policies, potentially to support group work, may also be applied to such events. Failure recovery policies are being investigated, but may be limited by the capabilities of backend repositories. | Not directly supported by the protocols. Can be added to Web applications via CGI scripts. | |
| Integration with the WWW | Chimera 1.2 provides a minimal level of interaction with the WWW by integrating a WWW client with Chimera via the use of the wrapper technique. This enabled Chimera anchors to be associated with Web pages. These anchors could then be included in Chimera links, linking these Web pages to information managed by Chimera clients. | Chimera 2.0 provides a deep level of integration with the Web. URLs are used to reference both hyperwebs and their contents. HTTP is used to establish connections between clients and servers. HTTP can also be used to invoke API operations on Chimera 2.0 servers. Java Applets can now be Chimera clients allowing a deeper integration of Chimera's services and standard WWW clients. | HTTP GET and PUT are fully supported by both frontend and backend protocols; the appropriate semantics for HTTP POST are unclear and more study is needed. Our OzWeb WebCity environment employs web objects from multiple websites in our day to day software development work. We plan to fully support all emerging HTTP collaboration specifications as they become available. | N/A | |
| Automatic Link Generation | Links are first-class objects whose operations are available via the API. Any application with access to the API can automatically generate links. | Same as Chimera 1.2 | WebCity uses Hi-C, a homegrown utility for generating HTML-ized cross-links from C source code. Other automatic link generation utilities can easily be integrated into an OzWeb environment instance via the process enactment facilities. | Yes. At a minimum all that is required is an application which can generate HTML. These are typically combined with WWW spiders which crawl the Web to retrieve information, process it in some fashion, and then generate HTML based on the results. | |
| Multi-lingual APIs | Yes. APIs exist in C, Ada, and Java. | No. Currently only a Java API is provided in the Alpha release. Other APIs (i.e. C, C++, Ada95) will be provided in future releases. | Xanth protocol modules must be implemented in C, but can interface to backend repositories and frontend clients written in any language. | Yes. The HTTP protocol has many implementations available in a variety of programming languages. | |
| Cross-Platform | No. Executes only on Sun hardware under either SunOS 4, or Solaris 2. | Yes. Chimera 2 can run on any platform with a Java Virtual Machine. | OzWeb runs only on Solaris 2.5+, but some components run on other architectures. Rivendell supports Windows 95 tools via WinDD. Protocol modules allow interaction with clients and servers running on any platform that supports that protocol. For example, HTTP/WWW clients can run pretty much anywhere. | Yes. WWW servers and clients exist on many platform combinations. | |
Notable recent developments and significant available software for projects described in this document includes:
Chimera
OzWeb
WEBDAV
WebSoft
WebSoft software is written in Perl 4.036 (and in 5.002 for wwwstat), and should work on any Unix system on which Perl has been installed.
This editor of this guide is Jim Whitehead, U.C. Irvine <ejw@ics.uci.edu>.
Contributors to this guide are (in alphabetical order:)
Ken Anderson, U.C. Irvine <kanderso@ics.uci.edu>
Steve Dossick, Columbia University <dossick@cs.columbia.edu>
Gail Kaiser, Columbia University <kaiser@cs.columbia.edu>
Richard N. Taylor, U.C. Irvine <taylor@ics.uci.edu>
Jim Whitehead, U.C. Irvine <ejw@ics.uci.edu>