Go backward to Technological Assessments Go up to Implementing CONCERT

Implementation Roadmap

The proposed design relies on the fact that every concert player downloads and executes a program that starts the instruments relevant for the particular player and coordinates them among each other and with the instruments of other players (in particular of the lecturer). This coordination is based on a set of concert services that must be provided by an underlying runtime system and of which beat sequences are a high-level user abstraction. Furthermore, the components retrieve information from a global database filled during the preparation of the concert and may also put created objects there.

We intend to implement the proposed architecture i.e.

• an application framework for concerts,
• various concert instruments, in particular a Mathematica instrument,
• supporting tools, in particular a visual programming environment, concert manager, and concert client,

in a Java-based environment i.e. using the Java language and systems and related/compatible systems and technologies:

Concert Services and Ensemble Communication

We plan to utilize the CalTech Information Infrastructure (II) for implementing the application framework and providing the distributed services on top of which the higher-level abstractions can be provided. The II can be utilized for

• distributed communication based on the "mailbox" facility (II package info.net): signal streams and general message passing abstractions can be based on this abstraction.
• distributed services based on the "Djinn" abstraction (II package info.djinn): any service can be encapsulated as a Djinn (an encapsulation of a set of threads manipulating an internal state and using mailboxes for external communication).

When a downloaded concert score starts execution it invokes the so called "Djinn Master" that is in charge of forwarding service requests to Djinns, invoking the corresponding Djinn if necessary.

Since the II system still is in a beta-stage, it might however turn out that the basis is not yet stable enough for own developments (although we do not expect this, because the system is continuously developed and improved). In this case we can utilize the proved Nexus runtime system and to build the required distributed services and to use the JNI interface for integration into Java. Experiences of the Globus project (building a large-scale distributed infrastructure) on the basis of Nexus may aid such an approach.

As an supplement respectively alternative to the II mailbox abstraction for inter-process investigation we will also investigate the Java RMI (remote method interface) for direct invocation of Djinn methods. We expect this to provide a for many kinds of services a more suitable interface than the II message passing abstraction. Furthermore, for real-time multicasting services (i.e. audio and video) communication between Djinns has to be based on special protocols like the Internet-based MBONE; corresponding Java interfaces have to be developed.

Concert Instruments and Application Interfaces

As sketched in Section Embedding Mathematica we will use the JNI (Java Native Interface) for integrating Djinns with services that are only available in other languages (such as the MathLink communication library). For other application components, we expect the JNI interface to play an important role as well.

For case that CORBA-compliant services/components are to be utilized, the Java IDL interface is available. However, CORBA is basically more suitable for client/server applications than for general peer-to-peer frameworks; thus the necessity respectively suitability of its application in the proposed framework is questionable.

We do not yet see any purpose in utilizing distributed component technology (JavaBeans) for building the proposed components; their interfaces are closely bound to the architectural framework proposed in this paper, which makes their use in other application contexts unlikely.

Network Database

We intend to use the HyperWave hypermedia information system as the basis of the proposed global database services. HyperWaves structuring and indexing facilities, its multi-protocol facilities and its availability on many platforms with commercial support make it an ideal platform for out framework.

We have to develop appropriate Djinn servers mapping the abstract network database services into concrete HyperWave requests, a task that can be performed with Java's networking facilities.

Supporting Tools

The visual programming interface sketched in this paper can be implemented as a Java application using the AWT (Abstract Windowing Toolkit) either as a stand-alone application or as a WWW applet. The technical facilities are sufficient; the main challenge lies in finding the right visual abstractions and in generating the appropriate Java classes. On the same software basis, the concert manager and client can be implemented. The development of a visual debugging environment is technically more challenging since it requires close interaction with the Java VM and a Java breakpoint debugger.

While various technical details remain to be settled during the concrete development, the overall roadmap to an implementation of the proposed architecture based on well-supported technologies is clear.