\"\" \"\" \"\"
Go backward to The Mental Model
Go up to The CONCERT Architecture
RISC-Linz logo

Application Programming Interface

We suggest an implementation of the mental model described in the previous section using the following technological framework (see also Implementing an Application Framework :

The following subsections describe the low-level programming interface on which concert scores are based. Composing Concert Scores shows how this may serve as the basis abstract coordination models.

  • Concert Example
  • Concert Composition
  • Database Services
  • Concert Services
  • Ensemble Communication
  • Beat Sequences
  • Concert Example

    The core of the concert score is a class method of the following kind describing the overall structure of a concert:

      monitor.start();              // start monitor on lecturer's host
      slides.start("slides");       // start slide show controlled by monitor
      monitor.wait("start");        // wait for lecturer's start signal
      audio.start();                // start audio instrument
      slides.wait("example");       // wait until example1 slide
      math.start("notebook");       // start mathematica notebook concert
      slides.wait();                // wait for lecturer prompting next slide
      math.hide();                  // hide mathematica
      slides.wait("exercise");      // wait for exercise slide
      math.show();                  // show mathematica for exercise work
      math.async();                 // let audience work independently
      monitor.wait("interrupt");    // wait for lecturer signal
      math.leader(lecturer);        // lecturer becomes math leader again
      slides.hide();                // hide slide show
      whiteboard.start();           // start whiteboard 
      monitor.wait("continue");     // wait for lecturer signal on monitor
      whiteboard.stop();            // terminate whiteboard
      math.stop();                  // terminate mathematica
      slides.show();                // show slide show again
      monitor.wait("stop");         // wait for lecturer signal on monitor
      slides.stop();                // terminate mathematica
      audio.stop();                 // terminate audio connection
      monitor.stop();               // terminate monitor

    This concert consists of the following instruments whose construction is described later:

    The concert starts by invoking the monitor on the lecturer's host (the association of instruments to hosts is described later). The slide presentation instrument is started receiving as its argument the name of the presentation stored in the database. All this takes place before the actual concert starts giving the audience hosts time to connect to the concert and watching the cover slide of the presentation.

    When the lecturer has given the start signal via the concert monitor (which generates a beat with the name of the key pressed), an audio ensemble is created transmitting the lecturer's voice to the remote audience. The lecturer starts presentation with a set of slides explicitly controlling the leader of the slide viewer ensemble; the audience can watch the corresponding slides via their followers. Furthermore, for each presented slide, the leading slide viewer generates a beat with the name of the slide.

    When the presentation has reached slide "example", a Mathematica ensemble is created and brought into independent mode giving the audience the possibility of interactive exercising. When the lecturer presses an "interrupt" button in the monitor, the Mathematica ensemble brought back into follower mode with the lecturer's instrument being the leader. The slide presentation is hidden; instead a whiteboard ensemble is created with the lecturer controlling the leading instrument. The lecturer continues presentation using Mathematica and drawings on the whiteboard.

    When the lecturer presses a "continue" button on the monitor, both Mathematica and the whiteboard ensembles are terminated. The lecturer brings the slide ensemble into the foreground and continues the concert with a set of slide presentations. When he finally presses the monitor's "stop" button, all ensembles are dissolved and the concert terminates.

    Above demonstration sketches the essential core of the programming interface for developing interactive education sessions. Its essential characteristics is the SPMD style of control with focus on a single thread of control that manages many replicated instances of asynchronously executing processes from a leading process. Explicit synchronization takes place by waiting for specific signals from various instruments (e.g. from a monitor that emits signals with button names for every button pressed, or a a slide viewer that emits signals with slide names for every slide displayed).

    Distributed communication takes place "behind the curtains" by the use of predefined components that load the objects they operate on from the network database (such as the slide viewer and Mathematica) and store potential results there.

    We summarizing the methods presented up to now in a class

    class Instrument
      String wait();

    with methods for starting a instrument, terminating it, putting it into independent execution mode, resetting it into following mode with denoting a particular instrument instance as leader, waiting for the next signal generated by the ensemble and returning its name and waiting for a signal of the specified name, respectively. Subclasses may override and extend the interface e.g. in

    class SlideViewer extends Instrument

    for iconifying and deiconifying a slide presentation.

    More details about the construction of a concert and individual instruments are provided in the following subsections.

    Concert Composition

    Each concert is represented by a score object that is given a unique name to be displayed in a selection menu when the concert manager is contacted. This object is an instance of a superclass of Concert that provides virtual methods to be overridden by the concrete score:

    class Concert
    class MyCourse extends Concert
       run()  ...  // shown above
    MyCourse mycourse = new MyCourse("Computer Algebra I");

    Before defining the various player ensembles to be admitted to the concert, we construct various policies that restrict player ensemble access to particular network domains or hosts and optionally introduce password protection. For example,

    class Control
      adddomain(Domain)     // add domain
      addhost(Host)         // add host
      addany();             // allow access by any host
      Control(Bool)         // with or without password?
    Control lecturerControl = new Control(true);	// password protection
    myhost.addany();                                // lecturer uses any host
    Control localControl = new Control(false);      // the local audience
    mydomain.adddomain();				// only my domain
    Control all = new Control(true);	        // the remote audience
    remote.addany();                                // anybody with password

    The controls are not bound statically to concrete networks/hosts/passwords; the binding takes place when the score is registered at the concert manager; based on a score password, the lecturer can interactively provide/manipulate this information.

    Player ensembles are defined via the access controls and linked to the concert being constructed. Ensembles may be also compound to form larger ensembles:

    Ensemble lecturer = new Ensemble(mycourse, lecturerControl);
    Ensemble localAudience = new Ensemble(mycourse, localControl);
    Ensemble remoteAudience = new Ensemble(mycourse, remoteControl);
    Ensemble audience = new CompoundEnsemble();
    Ensemble all = new CompoundEnsemble();

    Now we define the various instruments utilized by the concert and establish their relation to the various ensembles specifying where the leader is to be located and where the followers are invoked:

    class Monitor extends Instrument
    Monitor monitor = new Monitor("monitor", lecturer, all);
    Audio audio = new Audio("audio", lecturer, remoteAudience);
    Slides slides = new Slides("slides", lecturer, audience);
    Mathematica math = new Mathematica("math", lecturer, audience);
    Whiteboard whiteboard = new Whiteboard("board", lecturer, audience);

    This list encompasses

    All the corresponding instrument classes have to be defined as subclasses of Instrument and implement the interface to the various applications integrated in the concert. The instruments will be only activated in the specified ensembles (e.g. no audio connection for the local audience); the string passed for the creation of the instrument is a unique name for the ensemble to which the instrument is to be attached.

    We still have define code for the various concert instruments, which is described in Section Application Components. This requires access to several lower-level services that are sketched in the following subsections.

    Database Services

    For implementing a instrument method

    class Slides extends Instrument
      start(String) { ... }

    access to the global database is required in order to load the slide presentation identified by the parameter string. Likewise, a instrument may output objects to be stored in the database. Native code of external applications may be stored in the database and retrieved on demand by the corresponding concert instruments on demand (thus avoiding local installations of the program). Last but not least, the concert score itself may be stored in the database from where it can be retrieved by the concert client.

    We assume that all objects in the database can be referenced via qualified names that incorporate the following information:

    A unique concert name.
    A unique object identifier (which may be again a structured identifier corresponding to a directory structure)
    A name for the variant of the object, such as the language of a document, the type of native code for a program, or the member of an ensemble that generated an object during a concert.
    A name for the revision of the object.

    An object may then be retrieved by providing this qualified name (where a default may be substituted for the version). Actually, most of the information needs to be specified only once when the concert connection is established (concert name, machine type, language preference, etc.) such that in the actual score typically only the "object" component of the identifier needs to be explicitly provided.

    A concrete object-oriented programming interface might then look as follows:

    class Object
      Int get(String)
      Int put(String)
    class MyObject: Object
      Result use(Arguments)
    MyObject object = new MyObject();       // create new object handle
    code = object.get("identifier");        // bind handle to object in db
    result = object.use(arguments);         // access object interface
    code = object.put("identifier");        // store object in database

    Database objects are instances of subclasses of Object that provides methods for loading the object from the database and storing it there while the concrete usage of the object is defined by the method interface of the particular subclass.

    Concert Services

    For actually implementing classes Concert, Control, and Instrument, ..., a variety of low-level services are required:

    All these facilities are ultimately based on a low-level interface that allows a instrument to get access to several concert services:

    class Service
      Int bind(String)
      Int call(String, InInterface, InParameter, OutInterface, OutParameter)

    These services are provided in the context of the current concert instrument i.e. a service request is implicitly parameterized by a unique concert identifier, host identifier, player identifier, and process identifier. An instrument may then ask for a service

    Service service = new Service();
    MyInstrument leader;
    service.call("leader", InVoid, InDummy, OutObject, mymaster);

    to retrieve the identity of the current leading instrument.

    On top of this low-level service request brokering scheme, higher-level abstractions may be provided a few of which are sketched below.

    Ensemble Communication

    Intra-ensemble communication is based on a one-to-many pattern where the leading instrument multicasts its control information to all followers. Communication may be based on several transmission protocols (connection-oriented/connection-less, reliable/unreliable, ...) depending on the demands of the particular instrument. For each of the required protocols, a corresponding low-level service class has to be implemented.

    For instance, a slide presentation ensemble might be based on connection-oriented reliable transmission channel for transmitting the signals controlling the presentation (whose content has been retrieved by each instrument independently via the network database). On the other hand, a real-time audio ensemble may be based on a connection-less unreliable multicasting scheme to forward the individual frames.

    In any case, it is important that the leading instrument must not be blocked or deferred by communication with any particular follower. In case of connection-oriented reliable transmission schemes this implies the buffering of all generated messages and the use of multiple independent threads for handling the individual communication channels.

    The main complication with the communication system arises when the execution mode of an instrument ensemble is changed, in particular by transferring leadership from one instrument to another. To preserve responsiveness, it is not acceptable to wait for all instruments to agree on the leadership change but it must suffice to establish agreement between the old leader and the new one. The protocol must ensure that even without reliable global notification the execution mode can be safely switched (e.g. by letting the old leader forward spurious requests to the new one).

    Beat Sequences

    Beat sequences are an abstraction of a reliable multicasting communication protocol for the transmission of messages whose information contents consist of simple character strings. Their primary role as a special concept is that of a nice interface to the player developing a concert that requires synchronization between different instrument ensembles.

    On the lower level they appear as a separate datatype:

    class BeatSequence
      Int bind(String);      // bind to a global name
      connect(BeatSequence); // connect another sequence to sequence
      signal(String);        // add beat to sequence
      String wait();         // wait for next beat in sequence

    This interface allows to create a new sequence with a unique global name, to connect a child sequence to a parent sequence such that the child receives all beats from the parent without removing the beats, to add a named beat to the tail of the sequence and to remove a beat from the tail of the sequence.

    On the higher level, the concepts of beat sequences as separate entities is hidden from the player by letting sequences appear directly attached to instrument ensembles and let each instrument directly access the beats generated by the respective leading instrument:

    class Instrument
      signal(String);       // add a signal to sequence (leader only)
      String wait();        // wait for next beat in sequence

    This illusion is created as depicted in the following figure:

    Each instrument is actually connected to its personal local stub of the corresponding ensemble with its own copy of the beat sequence connected to the "master copy". Each wait on a beat of the ensemble therefore removes the beat from its local copy only. Actually, in order to reduce network load, each host should probably accommodate a central "proxy copy" of the beat sequence to which the local copies of its various instruments can be connected.

    As sketched in the previous subsection, changes in the state of instrument ensembles must be handled appropriately by establishing agreement between old leader and new one only. One possibility for handling the attached beat sequences is to replicate the sequence in each follower instrument (as outlined above, "proxy" copies in each host are advisable anyway) and simply transfer information about all followers to the new leading instrument.

    Maintainer: Wolfgang Schreiner
    Last Modification: March 11, 1997

    \"\" \"\" \"\"