In his article What does it mean to share a World? , Bob Rockwell listed ten technical requirements that will have to be met by any interpersonal/interoperable VRML environment. These included the ability to:
Insert/Delete objects (e.g. avatars) in scenes at run-time (more generally : to modify the structure of the scene graph).
Merge multiple sound streams from distributed sources into the shared scene's current ambient sound (e.g. voices over music).
Track and communicate the state/behaviour of objects in real time (this implies a database of "who needs to know what how often?").
Allow (sets of) objects to be "driven" by users in real time (i.e. provide a UI as well as an API to runtime object control).
Let imported objects become persistent (i.e. make them a permanent part of the scene).
Protect the scene from damage by imported objects (ultimately, this implies the whole range of data-integrity issues).
Assign objects to a series of different " owners " (to insure control over access to object behaviour).
Support persistent roles (for people) and rules (for scenes) (i.e. a use-model for scene/object access controls).
Link objects dynamically to external data/functions (in particular, to support authentication certificates).
Support the free exchange of information among objects (from chat and business cards to arbitrary data containers/streams).
The concept of scene sharing includes not just multiple users but also multiple developers. It is the basis for all component-based applications, from the use of electronic cash to database access. One way to implement this concept is through sharing the scene graph by exporting it as a service in a federation and having downloaded code in the player be a client of the services provided by the federation.
In dataflow systems used in scientific visualisation, multimedia players are considered as sinks or terminal elements of the system. Here, we consider them as devices. In our terminology, a device is a software or hardware component being part of a federation. An MPEG-4 device is a device capable among other things to play mp4 files. We can think of MPEG-4 devices using many kind of networking technology (IP, Bluetooth, ) and willing to speak to various kind of devices (HAVi devices, ). The java2 world is in a good position to be the glue between them, but multimedia players are often embedded in an internet browser such as IE and consequently have access to a limited Java world specially with respect to networking. For example the SoNG 3D MPEG-4 player is a COM-ActiveX component. We have developed a bridge, specific to multimedia players, between the COM and Java worlds . This bridge could be reused for other players running outside of Internet explorer, on mobile devices without a JVM for example. To build this bridge, we have used the Jini surrogate architecture and the MPEG-J scene graph api. The original goal of MPEG-J was to have a parametric way to modify the multimedia content of the MPEG4 scene, but equally important is to be able to dynamically find and use external Java objects of all kind (directories, agents , servers, UIs, ).
A Jini federation brings together many different types of devices with Java technology as the common base. With the use of Jini connection technology, devices such as cell phones, pagers , PDAs, and TV set-top boxes can speak a common language. There are three basic parts to the Jini Network technology, which makes it simple to use. They include:
Lookup Service: where Jini technology enabled services announce their availability.
Discovery Protocol: a process to find the required lookup service.
Proxy Object: an interface to the Jini technology enabled service.
These three simple parts are enough to understand how an entire Jini federation operates. The figure above gives an idea of such a federation. We have build in the SoNG project a theatre demo , described later, which shows how such a federation can work. The federation comprises Javacards, PocketPCs and MPEG-4 3D players as shown below. MPEG-4 players are client of the SmartCards and PDAs are client of specific display services offered by the player. For mobile users, a local Lookup Service can be found with the help of a general Lookup Service using geographical coordinates.