Performatives and IDL

From: Dave Millard (
Date: Thu 24 Sep 1998 - 11:42:26 CDT

Hello Everyone!

        I hope everyone who attended the 4.5 workshop has enjoyed mulling over some of the problems we encountered; Sigi and I have been concentrating on how
the performatives idea fits into the general OHP-Nav effort and in particular how we should proceed with the IDL and the common document.

        At 4.5 we agreed on the following things:

  1. Data Model
  2. Basic operations (yet to be finalized)
  3. Message syntax (XML as an on-the-wire format)

        We also agreed that the idea of describing communications, as expressed by performatives, was a good one. However we had difficulty seeing how this could be written into an IDL specification.

        We believe that by re-thinking the performative approach and looking carefully at the 'Danish Proposal' we have found some possible ways forward which aren't compromises but actually powerful combinations of the two approaches!

        Performatives deal with message flow not message content. The whole reason that we originally proposed performatives was to provide an extensible 'cradle' (i.e. a layer, see figure in that the OHP-domain protocols such as OHP-Nav and later OHP-Tax and OHP-Space could fit into.

        When a message is sent with an ask performative, for example, you do not have to understand the domain protocol to understand that it is a request for an action. Similarly when a message you send results in a performative error response, you know that the other component couldn't parse or understand it, even though that component may 'speak' an entirely different OHP-domain protocol or version.

        In the same way that in the real world personal assistants may exchange and work with information on behalf of their bosses, without actually knowing the meaning of that information, in the OHP world components can use performatives to communicate in a standard way whatever the domain or version spoken actually is.

        This is the aspect of performatives that Sigi and I hoped to preserve and still do not want to lose. However after some serious brainstorming we have decided that the performative proposal given at the meeting confused these higher level 'message primitives' with the application level 'OHP operations'.

        So we will try and explain performatives again but in the light of our conversations and incorporating the Danish proposal. Below is an ASCII diagram showing the levels of OHP (I hope its come out OK!)

          OHP-Nav | OHP-Tax | etc...

	The Danish proposal represents OHP-Nav described in IDL. Yes, we include
the Creat-ed operations and all the other -ed operations! What this does is to
provide a total application level solution. What it does not do is let us talk abstractly about messages or tell us anything about message flow. For example, there is no general way we can subscribe to messages.

        This is where performatives come in. The OHP layer (the cradle we mentioned earlier) sits underneath the OHP-Nav protocol and uses performatives.

        As an example of how this works we could define two performatives initially, ask and notify. These are important as we always know that an ask is followed by a notify that contains the result of the ask (thus there are legal sequences of performatives). Alternatively a notify on its own lets us know that something has occured in the system.

        Thus message flow could go as follows:

        Now we can define our performatives independently of the OHP-Nav operations, be defining what they mean in terms of the 'content' they carry and by defining message flow.

Basic performatives

ask - the result of the content will be sent back in a notify message

notify - sent either as a result of an ask or as a sequence with an ask-stream. Alternatively can be a general notification about something that has happened. It expects no response.

error - this is a possible response for any message and lets the receiving component know that this component could not understand the previously sent message in the content. It expects no response.

Streaming performatives

ask-stream - the results of the content will be sent back in a sequence of notify messages followed by an eos message

cancel - can only be sent in regards to an ask-stream message and tells the server to stop sending messages regarding that ask-stream. It expects no response.

eos - can only be sent at the end of a sequence of notifys resulting from an ask-stream message. It expects no response.

Subscription performatives

advertise - it is possible to subscribe to messages of the form in content, it
expects no response.

unadvertise - can only follow some time after an advertise, it means it is no longer possible to subscribe to messages of the form in content; it expects no response.

subscribe - can only be sent if the content has been previously advertised and means: send this component all messages you see of the form in content; It expects no response.

unsubscribe - can only be sent if the content has been previously advertised and subsequently subscribed to, this means: no longer send me all messages of the form in content; It expects no response.

_(fwd link)_        We believe that this now allows us to talk about the performatives and the OHP-Nav actions independently. We could in fact agree on these actions and move on to writing the IDL definition of OHP-Nav. Unfortunately we need to define both OHP-Nav and the OHP or performative layer to be interoperable.

        We see the following approaches to including performatives using IDL.

  1. Compile an exhaustive list of performative/action/object IDL functions. E.g. askCreateNode. This will result in a huge list of approximately 500 functions; it also makes it more difficult to later extend the set of performatives; the advantage is that is very straight forward.
  2. Define performatives in IDL as separate interfaces (that could be extended in the future). These would build a basic layer on top of which other IDL definitions for other domains would be specified. The problem is we are unsure of how to do this in IDL.
  3. The third option is to define the performatives and their meaning (semantics)in natural language and have a flag (parameter) in each of the IDL functions.

        Sigi and I feel that we could do this in the proposed common document as performatives are essentially 'operations on' or 'context of' whatever domain actions they are carrying. We could use any of the above approaches and we are open to any other suggestions.

Look forward to hearing your comments,

Dave + Sigi.

Dave Millard (
University of Southampton

This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:21:08 CDT