5.3 Sproc Specific Layer

A Vision for Open Hypermedia Systems

Nürnberg and Leggett

5.3 Sproc Specific Layer

The Sproc Specific (SS) Layer uses the services of the Sproc Generic Layer, and thus may assume reliable ordered structure object transport and automatic standard header tagging. This layer is responsible for mapping the abstractions of a particular Sproc to generic structure objects.

Each Sproc has its own set of abstractions and services it provides to clients. These abstractions may take arbitrary forms. However, they must be expressible in terms of generic structure objects, since the Sproc Generic Layer expects these objects as input. There are two questions that must be answered with respect to this requirement. Firstly, does the generic structure object provide a sufficiently powerful means of expression? Secondly, does the requirement to map all members of the set of open abstractions to one particular abstraction contradict the discussion in favor of an open set of abstractions provided in Section 3.2.1?

With respect to the question of expressive power, it seems clear that generic structure objects are sufficient. Aspects of messages that do not neatly fit into the attribute or endset categories can be modeled as arbitrary object content. However, we feel that a stronger claim can be made with respect to representation of messages as structure objects. It is the case that this representation is reasonably natural for many of the abstractions needed by Sprocs. Object endset functionality allows the manipulation of structure. Object attributes allow modeling attributes of structure objects such as presentation specifics. Content can be used to hold scripts or node contents. A proxy object can be added to a set of objects that contains things like message name. Because aspects of a message like the message name are modeled as structure objects, layers below the SS Layer have a simple job - they need only understand structure objects. Message name, protocol name, and other data are "folded" into this common representation. From a data type perspective, everything is stored in a common data type (structure object) with fields of predefined types (named arrays of strings for attributes and named arrays of arbitrary bytes for endsets).

This leads to the second question. In Section 3.2.1, we argued against the notion that sufficiency of expressive power be used as a criterion for expressing abstractions. However, that argument applied to the abstractions that clients manipulate, not to those that servers manipulate. There is always a layer in any protocol at which all abstractions take a common form, whether that be byte streams at the Transport Layer or generic structure objects at the Sproc Generic Layer. The important issue here is that this mapping be hidden from clients. These concerns should be transparent to clients.

Since the SS Layer is open, it is impossible to define all the mappings from all of the structural abstractions and services provided by this layer to generic structure objects. This can be handled two ways. Firstly, one could define mappings as new abstractions and services are added. However, this greatly hinders standardization. Secondly, one can define an algorithm for mapping arbitrary structural abstractions and services to the generic format. This approach is analogous to the way in which CORBA interface specifications are used both to define the programmatic interface to an object and to generate IPC libraries to convey messages concerning this interface. We have chosen this second approach. Appendix C provides and algorithm to map the parameters of a given message to a set of generic structure objects. Essentially, simple parameters are mapped to endset/endpoint or attribute/value pairs. Large parameters are mapped to their own objects.

Given an algorithm to translate service definitions into sets of generic structure objects, only the service definitions of Sprocs must be specified. There are an open set of these Sprocs, but we feel three Sproc interfaces should be specified as a starting point for OHSWG work. As mentioned in Section 4.1.4, these Sprocs should address navigation, composition, and IR. A proposal for the navigation Sproc interface is given below. Composition and IR Sproc interfaces should be addressed in the short term.