Hypermedia%20infrastructures

1
Hypermedia infrastructures

• Peter J. Nürnberg
• Department of Computer Science
• Aarhus University

2
Outline

• Introduction
• Overview
• Hypermedia architectures
• Infrastructure support
• persistent storage
• collaboration facilities

3
IntroductionWho is this guy speaking?

• PhD in Computer Science Texas AM University,
  Aug 1997
• Forskningadjunkt at DAIMI Aug 1997-1999
• Research interests
• open hypermedia systems
• digital libraries

4
IntroductionWhy this talk has an odd title

• Scheduled talk hyperbases and collaboration
  support
• Just examples of infrastructure support
• Better placed in broader context

5
IntroductionFormat of talk

• Assumptions
• everyone has read the background material
• Expectations (of you)
• form the connections between the talk and the
  readings independently
• will contribute throughout the talk with
  questions, comments, concerns, etc.

6
Overview

• Hypermedia architectures
• defining hypermedia
• historical development
• architectural responsibilities
• Infrastructure support
• storage and collaboration(motivation,
  development, open issues)
• new directions

7
Hypermedia architecturesdefining hypermedia

• Interaction paradigm
• "point and click" manipulation
• Organization paradigm
• data and structure both first-class user
  abstractions
• Computation paradigm
• data and structure both first-class system
  abstractions

8
Hypermedia architecturesthe early years

• Monolithic, centralized architectures
• systems contained storage, interpretation, and
  display in one process
• simple to build, simple to use
• standard problems with non-distribution
• standard problems with forcing users to use new
  applications

9
Hypermedia architecturesthe middle years

• Client/server architectures
• allowed for "opening" the client layer
• defeated the "new application" problem
• still had problems with non-tailorable structures
  and behaviors
• generally still single server (limited
  distribution, scalability)

10
Hypermedia architecturesthe later years

• Open hyperbase systems
• moved storage out of the middle and distributed
  it
• much more sophisticated support (based around
  storage functionality)
• generally started to allow open behaviors

11
Hypermedia architecturesthis year

• Component-based OHS's
• finally allowing open middleware
• allows treatment of new domains
• allows easy tailorability
• complex infrastructure requirements

12
Hypermedia architecturesapplication layer

• Open set of applications
• custom-built and wrapped or modified third-party
  applications (clients)
• Orthogonality
• hypermedia functionality should not interfere
  with other functionality
• Requires a "bridge" concept
• locSpec and contentSpec

13
Hypermedia architecturesmiddleware layer

• Open set of "structure servers"
• each (conceptual) server provides a set of
  structural abstractions
• several conceptual servers may be combined into a
  single process
• Open set of behaviors
• "plug-in" to structure servers
• provide structural computation (e.g. traversal
  semantics)

14
Hypermedia architecturesinfrastructure layer

• Provides common support to middleware
• Effected in backend servers (store) and
  "non-localized" servers (SIM)
• Purpose 1 lessen development effort
• Purpose 2 increase efficiency

15
Hypermedia architecturestraditional backend
support

• Persistent storage
• basic (extensible) storage "atoms" plus
  transactions, access, concurrency, versioning,
  notifications
• IPC framework
• Other support
• distribution, naming, process control

16
Hypermedia architectureshypermedia specific
support

• New kinds of permissions/locks
• e.g., reference
• New kinds of process support
• e.g., behavior threading
• New kinds of memory management
• e.g., semantic locality based algorithms

17
Infrastructure supporthistorical developments

• Hyperbases (hypermedia databases)
• focused on persistent storage
• originally driven by use scenarios
• only later driven by efficiency gains (needed
  guarantee of "structure awareness")
• Development tools / IPC infrastructures
• SP3/HB3, HOSS (Texas AM)

18
Infrastructure supportplaces and faces

• Hypermedia Research Lab (HRL)
• Texas AM University, USA
• John Leggett, John Schnase, David Hicks
• Programming Systems Lab (PSL)
• Aalborg University, Denmark
• Uffe Wiil, Kasper Østerbye
• GMD-IPSI
• Darmstadt, Germany
• Jörg Haake, Norbert Streitz

19
Infrastructure supportstorage - motivation

• Development convenience
• ease development of structure servers
• Distribution / scalability
• enables more co-operation
• Runtime efficiency
• tailored support for hypermedia environments

20
Infrastructure supportstorage - early years

• Rudimentary support, no standards
• Examples
• HAM (Tektronix - 1986)
• HB1 (Texas AM - 1987)
• Aalborg HyperBase (Aalborg - 1990)
• GMD HyperBase (GMD-IPSI - 1990)

21
Infrastructure supportstorage - middle years

• Added more versioning, notification, concurrency
  support
• Examples
• HB 2 (Texas AM - 1990)
• EHTS (Aalborg - 1992)
• CHS (GMD-IPSI - 1993)

22
Infrastructure supportstorage - later years

• New structure awareness base efficiency gains
• New "hypermedia specific" functionality
• Examples
• HB3 (Texas AM - 1993)
• HyperDisco (Aalborg - 1993)
• HOSS (Texas AM -1996)

23
Infrastructure supportstorage - open issues

• Data model extensibility
• early work in Hyperform/HyperDisco
• new work focuses on efficiency gains through
  RDBMS optimizations
• work being done in the Coconut project at Aarhus
• Better hypermedia specific support
• still wide open

24
Infrastructure supportcollaboration - motivation

• "Realizing the vision"
• build systems as envisioned by Bush, et al.
• Take advantage of new distribution / scalability
• use the new hyperbase storage functionality -)

25
Infrastructure supportcollaboration - early
years

• HAM
• had versioning...
• HB n
• added locking, permissions
• Hyperform
• added fine-grained locking
• CHS
• added different co-operation modes

26
Infrastructure supportcollaboration - middle
years

• Moved support to middleware layer(appropriate
  for the times -)
• SP1 - SP3 (Texas AM - 1991-1995)
• SEPIA (GMD-IPSI - 1992)
• HyperDisco (Aalborg - 1993)

27
Infrastructure supportcollaboration - later
years

• Oddly enough, seems to have stalled or even
  regressed
• openness provided new challenges
• GMD-IPSI went into "open collaboration" but not
  "open hypermedia"
• Texas AM and Aalborg failed to build a large
  suite collaboration enabled applications

28
Infrastructure supportcollaboration - open
issues

• Combining open hypermedia and open collaboration
  support
• GMD-IPSI, Aarhus and Aalborg
• OHSWG standards and Construct Consortium
  implementations
• initial success stories (VITAL / Construct
  integration)
• forthcoming journal paper in "CSCW"

29
Infrastructure supportcurrent and future
directions

• Other types of infrastructure
• formalized IPC / process support
• development tools
• naming / identifier generation
• complex "bridge" abstractions
• integrated multiple domain support (see next
  lecture by Pete -)