D. E. Millard, S. Reich, H. C. Davis
Multimedia Research Group
The University of Southampton
SO17 1BJ, Southampton UK
{dem97r, sr}@ecs.soton.ac.uk, hcd@multicosm.com
The Open Hypermedia Protocol (OHP) was originally envisaged as a simple but comprehensive protocol to deal with hypermedia navigation. However it contained aspects of other functionality, most noticeably hypermedia collaboration and dynamic service invocation. As the protocol has evolved it has become apparent that to properly deal with these areas OHP would need to be much larger and more complex then was appropriate. This paper describes the ideas behind dynamic services and presents an optional extension to OHP that is domain independant. We believe that by splitting the functionality of OHP into a suite of packages or modules we may better divide and conquer the problems we have encountered.
The Open Hypermedia Systems Working Group (OHSWG, http://www.ohswg.org/) has promoted research towards interoperability amongst hypermedia systems and integration with the World-Wide Web. To this end it has been actively investigating the possibility of a generalised protocol for hypermedia navigation that would enable interoperability between hypermedia systems. The Open Hypermedia Protocol (OHP) [Davis et al. 96] was originally designed to encompass the area of hypermedia navigation as well as several others that were deemed too important to ignore, these included collaboration and services.
As work on the protocol has progressed it has become apparent that these sub-areas are more complex then one might expect, in addition other domains have been identified e.g. Spatial and Taxonomic hypermedia [Nürnberg & Leggett 97]. To include this complexity in a general OHP protocol would be a strong disincentive for using it, and yet the subjects are to important to exclude.
A possible approach is to divide OHP into a suite of similar, related protocols, all using the same meta-information and delivery mechanism. Thus OHP-Navigational (OHP-Nav), OHP-Taxanomic (OHP-Tax) and OHP-Space were born (although OHP-Nav is currently the only mature definition, containing most of the functionality in the original OHP definition). Recently it has been decided to remove dynamic services from the Navigational protocol and into a package of their own that can be applied to any domain (The Service Package).
Services first appeared in the original OHP definition [Davis et al. 96], although they were never completely defined. A Service is a black box of functionality, known only by name to a client, that can be invoked and its results understood, even though its workings are completely opaque. In this way a generalised client gains access to complex functionality that would otherwise be unavailable.
There are therefore three ways to examine the data in an OHP system. Firstly by using the operations defined in OHP-Nav, i.e. Create, Delete etc. Secondly by utilizing a query facility, i.e. get all Nodes where Attribute 'Author' equals 'D.Millard'. Thirdly by using the Service Package to dynamically discover what services a server has to offer and then dynamically invoking them. This third method has the advantage that it allows us to use functionality stored on the server as well as data (for example, an effective search algorithm that depends on system knowledge to operate).
In the older definitions of OHP-Nav [Davis et al. 97] there were four standard services that had defined semantics:
Since the current version of OHP-Nav (used for the demonstation at Hypertext '99) does not contain services at all, these standard services have become operations. This results in a few advantageous side effects. It means that any server that is OHP-Nav compliant must understand and implement them, this is different to standard services which a server may or may not offer. Also it means that the messages that deal with this functionality can be much more specifically tailored for the task (as opposed to being generalised to cope with any service).
In networking the word 'service' means a facility that is available on the network [Tanenbaum 96]. Because of this overloading the objects that represent services in the OHP data model are known as Computations. A Computation stores the information about the service in the same way that a Node represents a document, it is a meta-information object.
Although Computations are defined in the Service Packages they may be referenced from other domains. For example in OHP-Nav all hypermedia objects have a field that represents the ID of an attached Computation. The semantics of this attachment are not defined, i.e. if a Computation is attached to a Node it may be executed when that Node is opened, activated, played, closed or a any other event. Without a complete event model this is impossible to implement in a generalised way. However Computations can still be associated with objects, it is merely up to the client to decide when to invoke the service.
Computations can be thought of as being similar to Computational Nodes. They are complete objects in the system and can be referenced by ID and even linked to. Although the actual behaviour of following a link to a Computation is undefined. A Computation contains information for the user (name and explanation of the functionality) and also the input and output parameters of the service. In this way a generalised client can understand how to call the Computation and what to expect in return.
There is a complete set of operations for manipulating Services, most of which reflect those already defined in OHP-Nav (Create, Delete etc.) However there are several operations unique to the Service Package. These are presented in the following table:
| Operation | Description |
| RetrieveServices | Requests a list of all appropriate services from the server. |
| ServicesRetrieved | Gives information about all relevant Computations to the recipient. |
| RetrieveCServices | Requests a list of all appropriate Composite Services from the server (Composite Services are decribed below). |
| CServicesRetrieved | Gives information about all relevant Composite Services to the recipient (Composite Services are decribed below). |
| ServiceProgress | Gives information about how near completion an invoked service actually is. |
| ExecuteService | Invokes a given Service with a set of parameters. |
| ServiceExecuted | Returns the result of a given service via a set of results. |
ExecuteService provides a means to invoke a service with a set of parameters resulting in a ServiceExecuted message containing ranked results.
In experimenting with services it becomes apparent that one of the problems is that a service may actually take a long time to complete. This produces a major problem - lack of feedback for the user. Once the service is initiated the only related message a client receives is the completion ServiceExecuted message.
It has already been proposed to use performatives (from agent languages) [Fipa 97][Labrou & Finin 97] to keep track of the progress of lengthily services. The ask-stream performative requests that results are sent back as and when obtained, rather then at the end of processing. Also the client is allowed to cancel the request if it takes too long. These performatives provide a small set of management messages but do not convey any information about the services. Thus our major conclusion from experimenting with services was that some mechanism was needed to either let the user/viewer know the time that a service takes or to send progress messages to give feedback.
The problem with adding an approximate 'time to complete' to a service's definition is that the time actually taken is very dependent on the load on the processor at the time of execution, again varying with other users activity and processor load on the machine. Because of this giving a time in seconds is inappropriate. The alternative we decided to use categorizes the time taken into one of five bands.
A viewer can therefore treat services differently according to their time to completion, e.g. providing an 'Are You Sure?' dialog for medium or slower. It could also maintain a progress bar based on the category, this would be inaccurate but still give the user a sense of progress.
A further problem occurs when the time to complete a service fluctuates. This can occur as a result of server load or even as a natural function of the service. For example, a service may require an index file to operate. When the service is called it looks for the file and if it doesn't find it then it generates a new one before starting the service. If this happens then the service time to completion could drop from tens of seconds (Medium) to several minutes (Slow).
Progress messages are better then categories in that they adjust dynamically to the speed of the server and provide accurate feedback. To this end a progress operation could be added to the Service Package, referencing the ExecuteService message and progress to date (presumably as a percentage). This does not add complexity to the service definition but does add network overhead and relies on the linkserver to continue to send progress messages.
The problem with progress messages is they do not convey to the user at the time of invocation the actual speed of the service. Thus a user could select a Very Slow service believing it to return in Instantaneous times.
As a compromise we have decided to combine both approaches. The service definition contains (as an XML attribute) the Expected Time to Completion (ETC) which is given the value of one of the five recommended bands. In addition a ServiceProgress message provides the necessary information for a client to track progress once it has started. However there is no assumption about the frequency of progress messages or even that a server will send any at all.
So far we have described what we believe to be a powerful mechanism for clients to access server functionality but it is conceivable that this mechanism will not be powerful enough. Take the example of a service that analyses a section of music and produces a contour - Find Similar Music (FSM). It then checks that contour against the ones in a database to produce a list of nodes representing musical scores similar to the selection. This is an ideal candidate for a service, a complicated operation with well defined input and output parameters that could be used by a generalised client.
There is a problem. Because the service needs to examine the music file to produce the contour. It must either move the music file to the service (which could potentially take a very long time) or it has to move the service to the music file. The first option becomes unrealistic with files larger then a few tens of Kbytes, the second deals with mobile code.
We could still provide the service to a specialised client that knew how to produce a contour, if we broke the FSM service into two. The first part takes a selection and produces a contour - Produce Contour (PC). The second takes a contour and checks it against the database - Search By Contour (SBC). If the PC service resides on the client and the SBC service on the server then by combining the two we get the original FSM service. In this way the idea for a Composite Service was born.
Composite Services contain similar information to computations with the addition of a computation graph. The computation graph describes how computations can be combined. It allows computations to be called in serial or in parallel. By having a non-cyclic graph we avoid a lot of the problems with managing the flow of data (such as getting stuck in loops) while retaining most of the power of the concept.
A Client that wishes to use a Composite Service cannot invoke it with ExecuteService (this puts too much load on the Server), instead the client must know where to find each of the sub computations (either from the server, itself or a third system component) the client may then call ExecuteComputation in turn on each service, passing the output of each into the next, until it has finished. However this does require an intelligent client that is aware of all the domains involved.
In this position paper we have presented dynamic service discovery and invocation within OHP. We have concluded that the complexity of this provision is such that it merits a package of its own applicable to the entire OHP suite. This also allows us to consider services with domains other then OHP-Nav. However there are a few outstanding issues.
The Service Package treads a fine line between over-complexity and power, only implementation will see if the mixture is correct. More work needs to be done on looking at where work is done in the system and looking at whether that work can be moved around (using mobile code). There is much scope here for integration with mobile code technologies and agent research. Also the power of this service proposal needs to be tested properly which we are attempting to do by working with the Amphion [Blackburn 98] and MAVIS [Lewis et al. 96] projects at the University of Southampton.
[Blackburn 98] Steven Blackburn, David DeRoure. A tool for content based navigation of music. 1998, pp. 361-368 of: Proceedings of Multimedia '98. 1998.
[Davis et al. 96] Davis, H., Lewis, A. & Rizk, A. OHP: A Draft Proposal for a Standard Open Hypermedia Protocol (Levels 0 and 1: Revision 1.2 - 13th March. 1996). 2nd Workshop on Open Hypermedia Systems, Washington, March 1996. Available as http://www.ecs.soton.ac.uk/~hcd/protweb.htm.
[Davis et al. 97] Davis, H., Reich, S., and Millard, D. A proposal for a common navigational hypertext protocol. Tech. rep., Dept. of Electronics and Computer Science, 1997. Presented at 3.5 Open Hypermedia System Working Group Meeting. Aarhus University, Denmark. September 8-11.
[Fipa 97] Fipa 97 Specification, Part 2: Agent communication language. Tech. rep., Foundation for Intelligent Physical Agents, Geneva, Switzerland, Nov. 1997.
[Labrou & Finin 97] Labrou, Y., and Finin, T. A proposal for a new KQML specification. Tech. Rep. TR CS-97-03, Computer Science and Electrical Engineering Department, University of Maryland Baltimore County, Baltimore, MD 21250, Feb. 1997.
[Lewis et al. 96] Paul Lewis, Hugh Davis, Mark Dobie, Wendy Hall, Towards Multimedia Thesaurus Support for Media-based Navigation. Presented at First International Workshop on Image Databases and Multimedia Search. 1996.
[Nürnberg & Leggett 97] Nürnberg, P. J., and Leggett, J. J. A vision for open hypermedia systems. Journal of Digital Information (JoDI). Special Issue on Open Hypermedia Systems 1, 2 (1997).
[Tanenbaum 96] Tanenbaum, A. S. Computer Networks, 3 ed. Prentice-Hall International, Englewood Cliffs, New Jersey, 1996.