Towards a Proposal for a Standard Component-Based Open Hypermedia System Storage Interface

Transcription

1 Towards a Proposal for a Standard Component-Based Open Hypermedia System Storage Interface Uffe Kock Wiil Department of Computer Science Aalborg University Esbjerg Niels Bohrs Vej 8, 6700 Esbjerg, Denmark ukwiil@cs.aue.auc.dk Abstract. This paper takes a first step towards defining a standard component-based open hypermedia system storage interface in the context of the Open Hypermedia System Working Group. The paper presents a proposal for the core set of services of such an interface. The existence of such an interface is one of the basic preconditions for interoperability at the middleware level in hypermedia systems. The proposed interface has been implemented both as a stand-alone hypermedia storage service and as a basic service in the Construct development environment. Both implementations are in Java and are based on underlying file system services. 1 Introduction The Open Hypermedia System Working Group (OHSWG) [1] is the forum for definition of de facto standards for component-based open hypermedia systems (CB-OHS). Previous success stories of the OHSWG include the definition of a standard interface for navigational hypermedia called OHP-Nav [2] [3]. The members of the OHSWG typically meet twice a year at the Open Hypermedia System (OHS) Workshop at the annual ACM Hypertext Conference [4] [5] [6] [7] [8] and at a working group meeting in between hosted by one of the participating institutions [9] [10] [11] [12]. The common storage interface idea has been around for some time in the OHS community and has been discussed in various papers at past OHS workshops and working group meetings. The existence of such an interface is one of the basic preconditions for interoperability at the middleware level in hypermedia systems. At the latest working group meeting, OHS5.5 in September 1999 in Esbjerg, it was agreed that the author should come up with a proposal for a common storage interface. This paper takes a first step towards defining a standard CB-OHS storage interface in the context of the OHSWG. The proposal is based on the idea, which splits up the interface into a core set of services and a set of extensions dealing with more advanced services in the areas of access control, concurrency control, version control,

2 and notification control 1. This paper presents a proposal for the core set of services of such an interface. We envision that the core set of services and each extension is defined as a separate interface. The proposed interface has been implemented both as a stand-alone hypermedia storage service and as a basic service in the Construct development environment [13]. Both implementations are made in Java and are based on the underlying file system services. Section 2 provides a short overview of the previous work of the author to set the context for the present work. In Section 3, we present the storage interface proposal and, in Section 4, we describe the current status and plans for future work. 2 Previous Work The previous work of the author is centered on a decade of hypermedia system development involving various systems including Hyperform ( ) [14], HyperDisco ( ) [15], and Construct (1997-) [16]. The author has also been involved in the OHSWG standards work since its beginning in 1996 [2] [3] [17]. Construct is a CB-OHS developed as the common code base successor of the DHM [18], HOSS [19], and HyperDisco systems. It is a major goal of the Construct project to be fully OHSWG standards compliant. For example, Construct provides a complete implementation of the OHSWG navigational interface standard (OHP-Nav). The latest news in the Construct project is the addition of a set of development tools that assist the hypermedia system developer in building CB-OHS service components [20]. The development cycle has two steps (Figure 1): 1. The developer creates a UML diagram or an IDL specification for the interface of the service. Based on this input the UML to IDL tool (U2I) and the Construct Service Compiler (CSC) generates a skeleton service component. 2. The developer creates the semantic parts (methods bodies) of the operations defined in the interface. When the semantic parts are added to the skeleton service, the service component becomes fully operational in the Construct environment. Experiences with the development of service components (e.g., development of a filebased implementation of the storage interface proposed in this paper [13]) have proven that the Construct development environment reduces both the time and complexity involved in development of CB-OHS service components. 1 The term was coined in 1997 in the early phases of the Construct project. It may turn out to be misleading as the development of the storage interface progresses. We may end up with more than 4 advanced service extensions. An example of an additional advanced service is search and query. Maybe the term 1 + n would be more appropriate.

3 Step 1 Construct Service Compiler Process template Skeleton service or XML DTD Step 2 U2I CSC IDL specification Construct UML to IDL tool Service semantics Auto-generated service semantics Code library Fig. 1. The Construct Development Environment 3 Storage Interface Proposal The presentation of the storage interface proposal is divided into two parts. Section 3.1 presents and explains some of the overall design decisions for the storage interface. Section 3.2 presents and explains a specification for the storage interface. 3.1 Storage Interface Design A class diagram for the proposed core set of storage interface services is depicted in Figure 2. The basic storage entity in the proposed storage interface is the Unit. The StorageInterface is responsible for the persistent storage of Units. A Unit has a set of Characteristics, which contains Unit specific data. A Characteristic has one of four types: BinaryAttribute, which can contain binary data. Attribute, which can contain all types of attribute values. Relation, which can contain references to other Units. Behavior, which can contain computations. A Characteristic has a name (type: string) and can contain several values.

4 StorageInterface 1 * Unit 1 * Characteristic BinaryAttribute Attribute Relation Behavior Fig. 2. Class diagram for the proposed storage interface A Unit has three predefined Characteristics: Name (type: Attribute), which can contain a set of names. The name given when the Unit is created is the primary name. All other names are secondary. Type (type: Attribute), which can contain a set of types. The type given when the Unit is created is the primary type. All other types are secondary. ContentUrn (type: Relation), which can contain a reference to wrapped content located elsewhere (e.g., in the file system). The argument for multiple names is simply that it may be useful to refer to a Unit using different names (e.g., in queries). The argument for multiple types is related to the issue of interoperability at the middleware level. Consider the following scenario: a navigational service and a spatial service share a store. In some cases, we may want the spatial service to be able to open navigational objects (e.g., nodes); and, likewise, we may want the navigational service to be able to open spatial objects (e.g., data). Having multiple types is a first step towards interoperability between the navigational and spatial services. An object created as a navigational node will have the primary type nav.node and additional attributes that only can be interpreted by the navigational service. A secondary type can then be added (say, space.datum ) together with attributes that only can be interpreted by the spatial service. This will allow applications of both types of services to open the Unit. 3.2 Storage Interface Specification The navigational hypermedia interface, OHP-Nav, was specified using an XML DTD. At OHS 3.5 [10] it was agreed to use IDL to specify interfaces. This allows the work to take place at a much higher level of abstraction when defining interfaces. When the OHP-Nav XML DTD was defined, it turned out to be very time-consuming to decide

5 and agree upon every single detail in the XML DTD. The CSC can generate an XML DTD from an IDL specification and, thus, save a considerable amount of time. module store { interface Characteristic { void addvalue(in java::lang::object value); void deletevalue(in java::lang::object value); void getvalues(out java::util::linkedlist values); void setvalues(in java::util::linkedlist values); void deletevalues(); }; interface BinaryAttribute : Characteristic { }; interface Attribute : Characteristic { }; interface Relation : Characteristic { }; interface Behavior : Characteristic { }; interface Unit { void getprimaryname(out string name); void setprimaryname(in string name); void getprimarytype(out string type); void setprimarytype(in string type); void addsecondaryname(in string name); void deletesecondaryname(in string name); void addsecondarytype(in string type); void deletesecondarytype(in string type); typedef sequence<char> chararray; void getcontent(out chararray content); void setcontent(in chararray content); void addcharacteristic(in string characname, in Characteristic charac); void getcharacteristic(in string characname, out Characteristic charac); void deletecharacteristic(in string characname); }; interface StorageInterface { void createstorageunit(in org::ohswg::construct::core::svc::urn urn, in string name, in string type, out Unit unit); void readstorageunit(in org::ohswg::construct::core::svc::urn urn, out Unit unit); void writestorageunit(in org::ohswg::construct::core::svc::urn urn, in Unit unit); void deletestorageunit(in org::ohswg::construct::core::svc::urn urn, in boolean deletecontenturn); }; }; Fig. 3. IDL specification of the proposed storage interface Based on the above argumentation, the proposed storage interface has been specified using IDL (Figure 3). The IDL specification defines the elements of the class diagram in Figure 2 in more detail: StorageInterface defines operations to create, read, write and delete Units. Unit defines operations to handle names and types (primary as well as secondary), to manipulate the content, and to manipulate Characteristics. Units are referenced using a Urn type. Characteristic defines operations to manipulate the values. BinaryAttribute, Attribute, Relation, and Behavior inherit the properties of the Characteristic interface.

6 4 Current Status and Future Work The Construct development environment is partially developed (late March 2000). The U2I tool is still under development. We expect to have the first running version of the U2I tool in the summer The CSC has been operational since January The CSC generates a code skeleton in Java based on an IDL specification like the one in Figure 3. We have made two different lightweight implementations of the proposed storage interface: a stand-alone implementation and an implementation based on the CSC. Both implementations are made in Java and use the file-system to provide persistent storage of Units. Thus, these implementations will run on any machine that has Java s runtime environment (JRE) installed. The stand-alone implementation operates as an isolated hypermedia storage package that can be imported into other Java programs. The CSC implementation operates as a hypermedia storage component in the Construct environment and has become part of the foundation services in the Construct development environment. We plan to continue the work on defining a storage interface to cover also the possible advanced extensions (at least the four mentioned in the Introduction). We also plan to continue to use the Construct development environment to develop different services and to integrate different applications to use these services. A demonstration of the Construct development environment and some of the generated services will be given at ACM Hypertext 2000 in June. Acknowledgment The Construct development environment is currently being developed at the Department of Computer Science, Aalborg University Esbjerg, Denmark and at the Department of Information Systems, University of Linz, Austria. The development team consists of Peter J. Nürnberg, David L. Hicks, Uffe K. Wiil, and Siegfried Reich. References 1. OHSWG. The web site for the Open Hypermedia Systems Working Group (2000). ( 2. Davis, H. C., Millard, D. E., Reich, S., Bouvin, N. O., Grønbæk, K., Nürnberg, P. J., Sloth, L., Wiil, U. K., and Anderson, K. M. Interoperability between Hypermedia Systems: The Standardisation Work of the OHSWG. In ACM Hypertext '99 Proceedings, Darmstadt, Germany, Feb. (1999) Reich, S., Wiil, U. K., Nürnberg, P. J., Davis, H. C., Grønbæk, K., Anderson, K. M., Millard, D. E., and Haake, J. M. Addressing Interoperability in Open Hypermedia:

7 The Design of the Open Hypermedia Protocol. The New Review of Hypermedia and Multimedia 5 (1999) Wiil, U. K., and Østerbye, K. (Eds.). Proceedings of the ECHT '94 Workshop on Open Hypermedia Systems. Edinburgh, Scotland, Sep. Technical Report R , Department of Computer Science, Aalborg University (1994). ( 5. Wiil, U. K., and Demeyer, S. (Eds.). Proceedings of the 2nd Workshop on Open Hypermedia Systems. Hypertext '96. Washington, DC, Mar. UCI-ICS Technical Report 96-10, Department of Information and Computer Science, University of California, Irvine (1996). ( 6. Wiil, U. K. (Ed.). Proceedings of the 3rd Workshop on Open Hypermedia Systems. Hypertext '97, Southampton, UK, Apr. CIT Scientific Report SR-97-01, The Danish National Centre for IT Research (1997). ( 7. Wiil, U. K. (Ed.). Proceedings of the 4th Workshop on Open Hypermedia Systems. Hypertext '98, Pittsburgh, PA, Jun. Technical Report CS-98-01, Aalborg University Esbjerg (1998). ( 8. Wiil, U. K. (Ed.). Proceedings of the 5th Workshop on Open Hypermedia Systems. Hypertext '99, Darmstadt, Germany, Feb. Technical Report CS-99-01, Aalborg University Esbjerg (1999). ( 9. Davis, H. C. 2.5 Open Hypermedia System Working Group Meeting. Southampton, UK, Dec. (1996). 10. Wiil, U. K. 3.5 Open Hypermedia System Working Group Meeting. Århus, Denmark, Sep. (1997). ( 11. Reich, S. 4.5 Open Hypermedia System Working Group Meeting. Southampton, UK, Sep. (1998). 12. Wiil, U. K. (Ed.). Proceedings of the 5.5 Open Hypermedia System Working Group Meeting. Esbjerg, Denmark, Sep. Technical Report CS-99-02, Aalborg University Esbjerg (1999). ( 13. Wiil, U. K. Using the Construct Development Environment to Generate a File-Based Hypermedia Storage Service. Lecture Notes in Computer Science, this volume, Springer-Verlag (2000). 14. Wiil, U. K., and Leggett, J. J. Hyperform: A Hypermedia System Development Environment. ACM Transactions on Information Systems 15, 1 (1997) Wiil, U. K., and Leggett, J. J. Workspaces: The HyperDisco Approach to Internet Distribution. In ACM Hypertext 97 Proceedings, Southampton, UK, Apr. (1997) Wiil, U. K., and Nürnberg, P. J. Evolving Hypermedia Middleware Services: Lessons and Observations. In ACM SAC 99 Proceedings, San Antonio, TX, Feb. (1999) Wiil, U. K. (Ed.). Open Hypermedia: Systems, Interoperability and Standards. Journal of Digital Information 1, 2 (1997). 18. Grønbæk, K., and Trigg, R. H. Design Issues for a Dexter-based Hypermedia System. Communications of the ACM 37, 2 (1994)

8 19. Nürnberg, P. J., Leggett, J. J., Schneider, E. R., and Schnase, J. L. Hypermedia Operating Systems: A New Paradigm for Computing. In ACM Hypertext '96 Proceedings, Washington, DC, Mar. (1996) Wiil, U. K., Nürnberg, P. J., Hicks, D. L., and Reich, S. A Development Environment for Building Component-Based Open Hypermedia Systems. In ACM Hypertext 2000 Proceedings, San Antonio, TX, Jun. (2000).