Go backward to The Mental Model Go up to The CONCERT Architecture

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 :

• A concert score is represented by a program in Java VM format that is downloaded by every concert player and executed by a local JVM interpreter. The implementation in JVM secures portability for all kinds of player hosts.
• A concert is originated on a host where the Concert Manager is running. This program listens on some port for concert requests and answers them by transmitting the corresponding score registered by the lecturer (the "concert composer").
• Any player may request access to the session by starting a Concert Client on her local host with the address of some machine where a concert manager is listening. The concert client contacts the concert master that provides a list of available scores for downloading and the various player ensembles for each concert with the number of players connected.
• When the concert score starts execution on the player's host, it asks for the player ensemble where participation is requested and verifies the corresponding access permissions (password, ...). If successful, the score contacts the concert manager and registers the player as a new member of a particular ensemble. Thus connection to to the other players is established.

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

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

run()
{
  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:

• monitor, a monitor instrument that allows global concert control,
• audio, an audio instrument transmitting the lecturer's voice to the remote audience,
• slides, a slide presentation tool controlled by the lecturer,
• math, the computer algebra system Mathematica for notebook presentation and interactive exercises,
• whiteboard, a whiteboard utility for drawing and hand-writing.

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
{
  ...
  start();
  stop();

  async();
  leader(Instance);

  String wait();
  wait(String)
  ...
}

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
{
  ...
  hide();
  show();
  ...
}

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
{
   ...
   run();
   ...
}

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();
audience.add(localAudience);
audience.add(remoteAudience);

Ensemble all = new CompoundEnsemble();
all.add(lecturer);
all.add(audience);

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

• a monitor running on the lecturer host providing control over all of the concert,
• a instrument establishing audio connection between lecturer and remote audience,
• a slide viewer displaying the slides presented on the lecturer host to all of the audience,
• a Mathematica ensemble controlled by the lecturer and linked to the audience,
• an electronic whiteboard ensemble controlled by the lecturer and linked to the audience.

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:

Concert

A unique concert name.

Object

A unique object identifier (which may be again a structured identifier corresponding to a directory structure)

Variant

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.

Version

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:

• A concert score (running on the player host) needs to contact the concert manager (running on the host where the concert is initiated) to present its credentials and to get linked into the concert.
• An instrument needs to decide whether it is to be activated in the current player ensemble or not,
• An instrument needs to establish who the leader of its ensemble is.
• Facilities for starting and stopping instruments are required.
• Facilities for bringing a instrument into independent mode and back into leading mode have to be provided.
• A leading instrument must broadcast its activities to the follower instruments.
• Beat sequences have to be implemented.

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();
service.bind("instrumentensemble");
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.