Figure 1. Web Service usage
During the past decade, considerable research on Open Hypermedia Systems (OHSs) was conducted in order to provide services of structuring and accessing information. Several hypermedia application domains were introduced, apart from the classical navigational, such as spatial [22] and taxonomic [26], so as to raise the number of cases where OHS structuring could be useful. Furthermore, the design of Component-Based Open Hypermedia Systems (CB-OHSs) [24] emphasizes the notion of services because it aims at enabling the cooperation between independent components each of which provides a specialized set of hypermedia services. The Open Hypermedia Systems Working Group (OHSWG) [25] was established in order to address interoperability problems between OHSs. The OHSWG developed perspectives for creating new inter-domain services (as opposed to intra-domain services which are valid for a single domain - such as navigational hypermedia - only). However, as it has been pointed out [23], the usage of hypermedia systems and services is narrow and has failed to reach a considerable mass of people.
The World Wide Web (WWW) [9], which was developed under different design principles, had the chance to meet global acceptance and rapid progress. The broad acceptance results in new services being developed continuously; additionally, new users are becoming members of the Web community, without being daunted by its well-known disadvantages and problems. Recently, the notion of Web Service and its well-defined specification [33] gave yet further boost in the progress of the Web, since interoperability and reusability problems of network applications seem to be addressed.
The Web Services technology was built under a perspective, which has common elements with the OHS architecture. In particular, the WWW is expanding as an environment, where several network applications submit their services in a common accessible manner. Such kind of reasoning is supported by OHSs either by CB-OHSs architecture or by new proposed architectures which differ from the classic notion of level design and are based on the distribution and cooperation between independent multiple open services [36]. Given the high expansion rate and the universal popularity of the WWW, the open hypermedia researchers are motivated to integrate their systems [1] or/and extend their system services with it.
However, the task of integration between OHSs and the WWW (or other third party client applications) is tricky and complicated. Most Web integration efforts by the Hypermedia research community are characterized by the following drawbacks: a) Although users want to use only one hypermedia service, in many cases they get to have access (and to pay) for all the OHS usability [29]; b) Hypermedia extensions and Web integrations are usually ad-hoc implementations, created by non-standardized methodologies; c) The OHS community has so far not made great usage of standard Web technologies.
This paper presents a well-defined step-wise approach for making open hypermedia services available to the broad Web community, in a platform-independent way. With respect to both the existing work in open hypermedia systems, and the open hypermedia protocol (OHP) [28], this process does not require rigid changes inside the architecture of OHSs, but proposes the creation of Web Services that map the functions of hypermedia services and operate autonomously as hypermedia clients. Hence, the usage of independent hypermedia services into the Web is made available. Moreover, like any other component technology, such as agents or also CB-OHSs, the simple fact that people "think" in components results in more usable software. OHS researchers find, through Web Services approach, a C - class tool [14] to attain their goal for Web integration. (As pointed out by Dr.Engelbart, front-line - or A-level - programmers use applications, which are constructed by B-level developers and tools. The methodologies and frameworks used by these B-level developers are developed by C-level developers-tools.)
Section 2 briefly describes the related work for augmenting Web Services based on OHSs. It focuses on the integration techniques used so far and discusses the three considering issues listed above. Section 3 analyses the Web Services as component technology, while Section 4 presents the proposed process for providing hypermedia services in the WWW. Finally, Section 5 is dedicated to a case study for the proposed methodology over Babylon Taxonomic System [8]. Summary and future work conclude the paper.
During the last years, important efforts for Web integration are reported in literature, the most important of which are being presented below.
The Microcosm group [19] has performed work in this area with several efforts, most notably the Distributed Link Service (DLS) [13]. A Web server's functionality is extended by hypermedia functional (including computational links, navigational links, etc.). Clients make requests, and the corresponding anchors are integrated and translated into HTML documents on the fly.
In DHM [18], a platform-independent framework as an extension to the Web browsers is presented (DHM/WWW [17]). For that purpose, Java is used for writing a general applet that handles browser integration and communication with the Hypermedia service, and CGI scripts are used for the communication between the browser and the Hypermedia (structure) server.
Chimera [1,4] extends a WWW server written in Java to make use of the Chimera Java API. In another integration effort, a client side server (or hypermedia session server) presents a user-interface, which allows the Chimera functionality to be wrapped [1,2].
Multiple Open Services project [36] presents an innovating idea. It aims to split up services into components. Each component provides a functionally independent service. Thus the way in which services are provided at all layers in OHS architecture is redesigned.
Recently, an interesting effort, which was presented in [7], has attempted to map SoFAR system to Web Services with respectful results.
Also, recent web technologies such as Extensible Markup Language (XML) [12] in combination with XLinks [21] and other standards provide a limited degree of open hypermedia functionality (e.g., more flexible navigational linking). In [3] the use of XML for information integration enables complex information management tasks and gives flexibility and extensibility capabilities in prototype software tools.
A more detailed analysis over the techniques used for integrating OHS with the Web, in literature, is presented in [1]. Apart from the Web integration efforts, an architectural framework for modeling third-party network application integrations with OHSs (WebDAV) [35] and an interesting framework for Web augmentation (Arakne) [11] have been presented. The need for Web augmentation with hypermedia functionality is outlined in various papers, such as in [10].
The approaches outlined above are characterized by deficiencies such as implementation costs, missing methodology and general availability. In the following these are described in more detail.
Cost: Shackelford argues that: "...every service has a cost associated with it...ideally, one should be able to use a service when it is needed without having to pay for it when it is not." [29]. Until now, in nearly every Web integration effort the client has access to the whole API of the OHS, even though only a part of the OHS functionality is needed. Thus, the cost and the complexity of the OHS service provision are multiplied. The goal is the user to be provided with simple, flexible, scalable, and well-defined services.
Ad-hoc Implementations: In most cases, the implementations that enable Web integration are ad-hoc. Instead of the existence of a (standard) methodology that integrates OHS with in the Web, each time developers want to integrate an OHS with the Web they are forced to invent their own techniques. This issue is transforming into a serious problem in CB-OHSs, where components are dynamically added or even modified, requiring from the developer to make new integration efforts every time. The lack of a concise methodology makes such integrations error-prone and difficult to maintain. The observation that the developer has to do the same effort many times is an indication that he should raise his level of work to the "C-level". Therefore, a standardized way for developers to create Web Services through OHSs would be desirable.
New Web technologies: The OHS community has so far not made great usage of standard Web technologies. The reasons therefore are manifold, the key argument being that most Web standards do not explicitly express a notion of links. Web Services as an emerging standard for component-based software development could well be a technology whose adoption by the OHS community would benefit both worlds: the OHS people would base their tools on technologies that are widely available; the Web community would benefit by the much richer structuring facilities offered by typical OHS services.
Web Services are an emerging technology to reuse software as services over the Internet by wrapping underlying computing models with XML [6].
The W3C definition of a Web Service argues that: "a Web Service is a software application identified by a URI [IETF RFC 2396], whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via internet-based protocols". [33]
An ordinary Web Service model consists of a SOAP (Simple Object Access Protocol) server, which interacts with its environment through a collection of operations that are network-accessible through standardized XML-messaging [32]. Using a Web Service Description Language (WSDL), one can fully describe all Web Service access details.
The establishment of a set of standards for Web Service has driven most of the developers to design and implement Web Services in a very common way. Those standards gave application developers the opportunity to use Web Services easily and effortlessly. Figure 1 presents a schema of the usage of Web Services components.
Figure 1. Web Service usage
It is important to give the image's size in case some automatic rescaling is needed. We would prefer images not to exceed 1000 by 750 and we may scale them to fit on ther page.
For SVG graphics use:
SOAP (Simple Object Access Protocol) is a W3C standard [32], which is used to define protocols able to send simple objects in XML format. Thus, any SOAP-enabled service can receive calls for methods, passing objects in XML. The main protocol used in conjunction with the SOAP protocol is HTTP, although it can be easily used with many other protocols such as FTP or SMTP.
WSDL (Web Service Description Language) is an XML-based language, used to specify the interface provided by a Web Service. W3C standardized WSDL [34] for the description of a Web Service, enabling its use by any user that links to the certain WSDL file.
UDDI (Universal Description, Discovery, and Integration) is a registry protocol [31] for Web-based services. It is used to provide information about Web Services, and it can be private, public or hybrid. A registry entry must contain certain information about the service. Initially, it must have the WSDL file describing the service as well as the location of the runtime service. In addition, a registry entry may contain any other useful information about the service and its provider.
The Web Service architecture is qualified by the following advantages [15]:
Interoperability. A Web Service provides hardware and software platform independence. Any client who uses the standard Web Services technologies can easily access a Web Service. By using WSDL files a SOAP client can easily be automatically created.
Encapsulation. A Web Service can easily be consolidated in any application, regardless of the internal programming details of the component.
Availability. The Web Service developer is able to publish enough information for any other developer to use, and create a Web Service client.
Modularity: Web Services provide modular advantages such as reusability and extensibility.
Self-description: Web Services have the ability to describe themselves in a way that can easily be recognized. Thus, the interface, the location and access information of the Web Service are identified by any external application.
Public ability: Web Services descriptions are provided through a wide public repository, and can be found and used by any user.
Summarizing, in contrast to using HTTP as a transport layer protocol with proprietary semantics attached to it, the notion of Web Services allows for the semantics of the remote method invocation to be explicit and thus to processed by software components autonomously. In combination with the exchangeability of the underlying transport protocol and the wide availability of implementations, this results in a new quality for component-based software development in Internet environments.
The main goal of this paper is to prescribe a process for creating Web Services and mapping functions of hypermedia services to operations of Web Services and vice versa. The proposed implementation process provides independence over the overall OHS architecture, and this is the main advantage from the other techniques described so far. Particularly, as shown in Figure 2 that presents the proposed architecture, it is indicated that neither the structure of the hypermedia components nor their communication protocol should be changed when an OHS developer wants to publish a service on the Web.
It must be clarified that the target is not the OHS integration of a Web Browser or any other client side application. Instead, this implementation process targets on mapping structure servers to Web Services in order to make OHS features accessible through the Internet. Those Web Services behave as clients for the OHS but they also behave as servers to the SOAP-aware applications.
As discussed above, the OHS community has mainly focused on the integration within third party clients with a view to providing hypermedia services to a number of user-friendly applications. Those attempts often use either wrappers or communicators or other communication applications of structure servers, so that the clients are provided with hypermedia awareness. Typically, wrapper-implementations of clients of OHSs are ad-hoc implementations. Each time, an OHS integration with an additional client application is needed, the necessity to create another ad-hoc communicator arises. Therefore, by adopting the proposed methodology, the effort for integrating new clients will be significantly reduced. Technically, in order to integrate a hypermedia service, the creation of a corresponding SOAP server is required. Furthermore coding of communication shims may be necessary. The notion of communicator has been referred to [35]. However, in the proposed approach, this communicator resides on server side and has to be created only once for a specific hypermedia service.
The mapping of the structure server to Web Service creates a new middleware service. Hence, every time an application needs OHS services, the steps of the integration method are simple. The generation of SOAP client can be done automatically (based on Web Service corresponding WSDL file). By the use of the widely accepted Web Services, the provision of a set of hypermedia services in the Internet through a common communication platform is achieved.
Figure 2. The classic (a) and the proposed (b) architecture for providing OHS services to external applications.
The steps of the proposed implementation process are the following:
Service specification: The service design starts with the specification of the service that will be created. Thereby, the service task, the target user group and the operations provided must be defined. A very important aspect of this step is the fact that there is no actual need to provide one-to-one mapping to every service offered by the OHS. What is more, there is no need to define a Web Service that maps every function of the structure server to operations. The services can emerge by a single hypermedia structure server or even by a subset of the functions supported by a structure server in an OHS. For example, the data navigation service, without authoring rights, in an OHS could be provided as a service on its own. Furthermore, versioning, storage, transaction and searching services could be published as independent Web Services.
A single Web Service is consisted of a set of simple operations. For each operation, there must be a specification of the name, the description, the type, the way it is called by a client, and the parameters it receives and passes. Every operation can map one ore more functions of the structure server to Web Service.
WSDL file creation: As long as the definition of the specifications is set, a description of the service is created using WSDL in a simple XML format. The latter WSDL file will comprise of the "guide" for the development of the service as well as of the creation of the SOAP clients.
Even though the WSDL file describes the Web Service API with a well-defined way, Web Service documentation has to exist. This documentation needs to describe specific details about the client behavior and the calling sequence of Web Service's operations giving clients the hypermedia perspective of the Web Service.
The Web Service implementation presupposes both the existence of the WSDL file of the Web Service and the knowledge of the API of the structure server. The form that the OHS API is provided is not affecting the implementation procedure. The methodology does not alter the functionality of the OHS, but, on the contrary, extends each of its services in a very simple and clear way.
SOAP Server creation: The development process continues with the implementation of a SOAP server, which can use the OHS or structure server functionality through its API. This is a fairly simple procedure because most of the present programming tools can automatically create SOAP servers and clients, as they seem to be aware of their usefulness (Microsoft .net, Delphi studio 7, etc).
The created Web Service, supports several operations. For each operation a corresponding internal function must be developed. This function must accept the parameters passed by the client as a service request. Furthermore, the function must execute one or more calls to the OHS, via its API, and then return a response. Communication between Web services and OHS structure servers requires data sets to be converted from structure server-supported data format into XML structures according to the corresponding WSDL file.
The internal functions of the Web Services are divided into a) simple mapping functions and b) complex functions. The former are those that map with one-to-one relationship the corresponding functions of structure servers. On the other hand, later call several functions of structure servers and combine the received results, aiming to provide clients with the requested information. Every complex function accomplishes a specific task, and has its own algorithm that can be presented with a diagram of the used hypermedia functions and the other data processes.
In order to clarify the ideas stated above, the proposed architecture is compared against the CB-OHS conceptual architecture and its layers and interfaces [24]. As illustrated in Figure 2, the Web Service is implemented as a hypermedia client that uses the structure server API to communicate with the structure server. In addition, the client interface is replaced by a set of SOAP functions, which compound the Web Service API (described by the WSDL file). The result of this procedure is a new middleware layer, which acts as a client for the structure server and as a server for third party SOAP applications.
SOAP Client creation: The next phase is to develop a simple SOAP client. The SOAP client is used for testing the communication of the Web Service. It is worth mentioning that there are various tools that can generate a SOAP client automatically. These tools only need to know the URI of the WSDL description file of the service.
Along with the creation of a SOAP client, a simple user interface is needed. The user interface is required so as the functionality of the Web Service to be checked.
Publication: The proposed methodology is concluded by the publication of the Web Service. A Web Service is published when it is registered using UDDI. Hence, the discovery procedure of the Web Service is possible. Additionally, new description languages have been created, such as DAML-S [5], providing semantic information about Web Services.
Despite the fact that a typical Web Service publication is formed only by the UDDI registration, there is also the need of demo software that is available to the users and demonstrates the usage of the Web Service (e.g. Google Web Service API and Demo Software [16]).
The implementation process described above provides a set of advantages in conjunction with the existing Web integration technologies. Firstly, Web Services provide by themselves a set of advantages that have been mentioned before. Secondly, the proposed implementation process provides the following additional advantages:
The main drawback is encountered in the early steps of the proposed methodology. That happens because it is difficult to define a Web Service with simple operations from a complicated system.
Besides, when the OHS API or the content type changes dynamically, it may be impossible to completely define the request and response parameters or even the operation at all. The WSDL descriptor file cannot be dynamically changed.
Finally, some important issues like QoS, transaction information and security issues are not yet fully researched and standardized in Web Services.
The main goal that led to proposing this methodology was to extend some of the Babylon System services as Web Services. A brief overview of the Babylon System is presented next (a more detailed description can be found in [20]), as well as a Web Service creation example.
The Babylon system (inspired by the hanging gardens of Babylon) is based on the idea of creating an integrated framework aiming to provide multiple categorization services using abstractions met in taxonomies. The main goal is to provide developers with an easy and fast way to construct Internet services for item categorization.
The model has the following features: The main entity of the data model is the object entity called "item" in which several characteristics are assigned. Each item can be inserted in a single category. Each category is identified by a group of characteristics and may contain a set of items or other categories, formulating a tree-structure. The system supports the creation of category shortcuts in other categories of a tree, giving the notion of relevance. Finally, the meaning of association is also defined; a specific relationship between different tree categories that are being used for automatic tree-to-tree item transferring and sharing.
During the design and implementation of the Babylon System, there was special care for two innovating features for OHSs: a) user management and category sharing capabilities and, b) association capabilities between similar categories of different taxonomies, targeting on automatic update of all the common interest categories. This feature allows end users to get notified when associated categories of other taxonomies change (e.g. when items are added or deleted).
The targeted task is to redefine the Babylon System as an integrated component supporting taxonomic services in CB-OHSs such as Callimachus [30].
Babylon's architecture consists of three layers: a) the storage layer that is responsible for storing and managing the structural and non-structural information imported into the system, b) the taxonomic management layer that provides taxonomic creation and manipulation services and c) the client layer, which consists of either independent applications or several tree-structure applications that provide tree service development capabilities. The conceptual architecture of Babylon system is presented in Figure 3.
The storage layer and the taxonomic management layer comprise of the basic infrastructure that provides taxonomic services for developers. More specifically, the storage layer is the repository of the system, composed by the structure storage system and the data storage system. The structure storage system stores and organizes the structural information while the data storage system is responsible for the user-imported data. Besides, the taxonomic layer provides basic taxonomic management capabilities to the system by serving structure and content management as well as sharing and comparison requests. The kernel of this layer is a taxonomic structure server, which is responsible for the taxonomic structure creation, management and storing as well as the data categorization requests. The communication with the client layer is achieved using the HTTP protocol, sending the data in a very simple XML format.
Figure 3. Conceptual architecture of the Babylon system. The level division and the services naming was made according to the CB-OHS architecture.
The target is to extend some Babylon Services into the Internet as Web Services. Below there is an example for the creation of such a Web Service.
Service specification: The Babylon System is currently managing a set of taxonomic structures, each of which is used for the categorization of type-specific pieces of information. One of these taxonomies is called Babylon URL Manager. Web Users can perform navigation and authoring tasks using the Babylon URL Manager in a Web directory service.
Next, we define a simple service called Babylon_WebDirectoryService that provides free navigation capabilities over Babylon URL taxonomies. The service, provided to the public, prohibits the authoring either the tree or the data.
The WebDirectoryService communicates with SOAP over HTTP. The available operations are:
WSDL file creation: For each operation, we define the parameters and finally we create the Babylon_WebDirectoryService WSDL file [8].
SOAP Server creation: Following the proposed methodology, we create a PHP-SOAP server, using a corresponding PHP-SOAP unit [27], in which we define the URI of the WSDL file.
Afterwards, for each operation defined, a function that accepts and returns the proper parameters is created. For instance, the DoOpenCategory function just receives the category id and then calls the Babylon server's procedures GetChildren(idcategory) and GetNodeItems(idcategory). Then, it converts the data (using XSL and XML parsing) in SOAP oriented data. This is a complex function. On the other hand, the functions used for the last three operations (DoGetCategoryPath, DoGetUrlCategory, DoSearchUrl) are simple mapping functions. These functions just call the corresponding Babylon server function and return the data in SOAP format.
SOAP Client creation: A PHP-SOAP (testing) client is created, based on the corresponding WSDL file and the communication with the Web Service is tested. Next, a plain Web Interface is created so as the Web Directory Service Tree to be visible. A demo site of Babylon's Web Service is located in [8].
Publication: The last important task is to publish the created Web Service through UDDI. Also, it is rather simple to create a corresponding demo version. This is achieved by a slight transformation of the already created testing client. Then it is publishedas an Downloadable Demo Version.
The implementation process, which was presented in the previous subsection, can act as a "guide" (a "C-class" approach) so that new Web Services are created or existing Web Services are altered. The conceptual architecture when a new service is added in the Babylon System is altered to the schema presented in Figure 4, in which Web Service requester is any SOAP-aware network application. In Figure 4 the combination between the former conceptual architecture schema of the Babylon System (Figure 3) and the schema of the usage of Web Services (Figure 1) is obvious.
Figure 4. Mapping a Babylon Service to Web Service.
An interesting aspect of the proposed Web Service creation process occurs when someone tries to create a Web Service that has mapped all the services provided by the OHS. In this case, a central Web Service is implemented. This central Web Service can serve other specific-purpose Web Services. In this way, the whole OHS API is extended through a single Web Service. The main drawback of this aspect is that in most cases this implementation will be rather tricky due to the complexity of the operations of OHSs components.
Nevertheless, the Babylon system exhibits a controlled complexity at the functional level. Therefore, the implementation of a central Web Service is possible, for the process of a large set of taxonomic services. By this way Babylon system's services are offered through a single Web Service. The resulted architecture, in this case, for the Babylon System is presented in Figure 5.
Figure 5. Full mapping of Babylon structure server.
The future work of the approach presented in this paper focuses on the implementation of a set of tools that can automatically produce Web Services from UML schemas.
There is a variety of tools available that can create a WSDL file from an IDL definition of a service. In addition, most of the modern programming languages and some stand-alone tools can generate the SOAP Server and SOAP client code or executable applications based on a giving WSDL file. The main goal is to build an integrated developer framework able to generate Web Service skeleton sources that have hypermedia awareness and map every hypermedia structure server function. This framework will be able to create also automatically Web Service clients that support the SOAP communication with Web Service.
The Construct development environment [36, 37] provides development tools that assist the system developers in the generation of set of services that make up a hypermedia system [35]. Construct could be extended in order (a) to support IDL to WSDL tools and (b) to rebuild CSC (construct service compiler) so that it also creates a mapped Web Service based on the structure server, as outlined in Figure 6.
Figure 6. The current (a) and the proposed development process (b) with the Construct development tools. CWSC stands for Construct Web Service Compiler.
Furthermore, an interesting additional investigation is how those Web Service structure components can interact with each other in order to provide complete structure service functionality within OHSs.
In this paper we have argued for a step-wise approach to make the rich functionality of Open Hypermedia Systems (OHS) available to the web community. Using well-defined and accepted component-based technologies such as Web Services a broad platform for further usage and extension for web developers will be provided. Additionally, an integration example with the Babylon system has been demonstrated.
We believe that our approach offers multiple opportunities: By providing open and standard services, the OHS community benefits from the acceptance and popularity of existing tools and services. On the other hand, the web community can build on well-established research prototypes. Finally, end-users can take advantage of the unique features that can be offered by OHSs.
The authors would like to thank Ioannis Panaretou from the Business Management & Administration Department at the University of Patras for his support during this research.
[1] : Integrating Open Hypermedia Systems with the World Wide Web. In Proceedings of the 1997 ACM Hypertext Conference, (Southampton, UK).
[2] : The extensibility mechanisms of the Chimera open hypermedia system. In Journal of Network and Computer Applications, 24, pp. 75-86. 2001
[3] : Using XML to support Information Integration. Proceedings of the 7th Workshop on Open Hypermedia Systems, Aarhus, 2001. Lecture Notes in Computer Science (LNCS) 2266.
[4] : Chimera: Hypertext for heterogeneous software environments. Presented at The First International Semantic Web Conference (ISWC), 2002
[5] : DAML-S: Web Service Description for the Semantic Web. In Proceedings of the 1997 ACM Hypertext Conference, (Southampton, UK).
[6] : Web Services Engineering: Promises and Challenges ICSE'02, 02, May 19-25, 2002, Orlando, Florida, USA.
[7] : Agents for the Grid: A comparison with Web Services (part II: Service Discovery). In AAMAS'02, July, 2002, Bologna, Italy.
[8] Babylon System's Web Service Demo. At URL: http://www.optionsnet.gr/babylonproject/Webservice
[9] : The World-Wide Web. Communications of the ACM, 37(8), pp. 76-82. 1994
[10] : The need for Web augmentation. In ACM Hypertext '99 Doctoral Consortium Final Report, Technical Report AUE-CS-99-03. Aalborg University Esbjerg, Denmark, 1999.
[11] : Unifying Strategies for Web augmentation. In Proceedings of the ACM Hypertext 99 Conference, pp. 91-100, Darmstadt, Germany, Feb. 1999.
[12] : Extensible Markup Language (XML) 1.0 W3C Recommendation, 10-Feb-1998. At URL: http://www.w3.org/TR/REC-xml
[13] : The Distributed Link Service: A Tool for Publishers, Authors and Readers. In Fourth International World Wide Web Conference: "The Web Revolution". Boston, Massachusetts, USA, 1995
[14] : HT'98 OHS Workshop Keynote Address.
[15] : Enterprise Services Communications of the ACM, October 2002/Vol.45.No 10, pp.77-82.
[16] Google Web APIs Home. At URL: http://www.google.com/apis
[17] : Designing Dexter-based Hypermedia Services for the World Wide Web. In Proc. of Hypertext '97. Southampton, UK, pp. 146-156.
[18] : The Dexter Hypertext Reference Model. Communications of the ACM, 1994, 37 (2), pp. 30-39.
[19] : Rethinking Hypermedia: The Microcosm Approach. Kluwer Academic Publishers, Norwell, Massachusetts, USA. 1996
[20] : Babylon Bookmarks: A Taxonomic Approach to the Management of WWW Bookmarks. MIS'02, (Esbjerg, Denmark).
[21] : XML Linking Language (XLink). At URL: http://www.w3.org/TR/1998/WD-xlink-19980303 1998
[22] : Spatial hypertext: Designing for change. Communications of the ACM, 38(8), pp 88-97. 1995
[23] : Relationships Among Structural Computing and Other Fields. JNCA Special Issue on Structural Computing, 2002
[24] : An agenda for open hypermedia research. In Proceedings of the 9th ACM Conference on Hypertext, June 20-24, 1998, Pittsburgh, PA, pp. 198-206.
[25] Open Hypermedia Systems Working Group - OHSWG WWW site.: At URL: http://www.cs.aue.auc.dk/ohswg
[26] : Don't link me in: Set based hypermedia for taxonomic reasoning. In Proceedings of the 1991 ACM Hypertext Conference, (San Antonio, TX, Dec), ACM Press, pp. 233-242.
[27] PHP-SOAP Unit (NuSOAP). At URL: http://dietrich.ganx4.com/nusoap/index.php
[28] : Addressing interoperability in open hypermedia: The design of the open hypermedia protocol. Special issue on open hypermedia. The New Review of Hypermedia and Multimedia, 5, pp. 207-248.
[29] : The Architecture and Implementation of a Distributed Hypermedia Storage System. In Proceedings of the 1993 ACM Hypertext Conference, (Seattle, WA, Nov), ACM press, pp. 1-13.
[30] : Structuring Primitives in the Callimachus Component-Based Open Hypermedia System. JNCA Special Issue on Structural Computing, 2002.
[31] Universal Description, Discovery and Integration of Web Services (UDDI). At URL: http://www.uddi.org
[32] W3C Simple Object Access Protocol (SOAP). At URL: http://www.w3.org/tr/SOAP
[33] W3C Web Services Architecture Domain. At URL: http://www.w3.org/2002/ws/
[34] W3C Web Services Description Language (WSDL). At URL: http://www.w3.org/tr/WSDL
[35] : An Architectural Model for Application Integration in Open Hypermedia Environments. In Proc. of Hypertext 97, (Southampton, UK), pp. 1-12.
[36] : Multiple Open Services: A New Approach to Service Provision in Open Hypermedia Systems. In Proceedings of the 2001 Hypertext, (Aarhus, Denmark), pp. 83-92.
[37] : A development Environment for Building Component-Based Open Hypermedia System. In Proc. of ACM Hypertext 00, (San Antonio, TX), pp. 266-267.