Go backward to Technological Assessments
Go up to Implementing CONCERT
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.
in a Java-based environment i.e. using the Java language and systems and related/compatible systems and technologies:
info.net): signal streams and general message passing abstractions can be based on this abstraction.
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).
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.
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.
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.
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.