There are a number of possible architectures of systems employing the X-VRML language. X-VRML can be used either on the server or on the client side, with or without a database. The database can be used either only for retrieval or for both retrieval and updating data. In this section, different architectures of interactive 3D/VR systems built with the use of the X-VRML language are presented.
A number of general-purpose X-VRML processors have been implemented for use in different systems. These include server-side implementations in form of a servlet and a standalone application, and client-side implementations in forms of plug-ins, ActiveX modules, and Java applets running in Web browsers. All X-VRML implementations share common implementation of X-VRML commands, which are independent of the processor used. New commands can be implemented separately as Java classes and added to the processors.
Fig. 4.11 Using X-VRML to create standalone scene templates
Fig. 4.12 Using X-VRML to define a library of external prototypes
Server-side Processing of X-VRML
The first case is presented in Fig. 4.11. The X-VRML file contains the whole template of a virtual scene. The use of X-VRML templates instead of standard models encoded in content representation formats, such as VRML/X3D, simplifies the virtual scene code, provides means of parameterization and enables selection of content to be displayed.
The X-VRML input file is read by an X-VRML processor that analyzes it and produces the final virtual scene code. Processing of X-VRML is performed by the use of X-VRML commands—software components responsible for interpreting particular X-VRML language elements.
A similar example is shown in Fig. 4.12. In this configuration, the X-VRML templates are used to create a library of prototypes that can be used by scene models encoded in standard content representation languages, such as VRML/X3D. The scene models use standard syntax and do not require any special processing.
Fig. 4.13 Using X-VRML for data visualization
Fig. 4.14 Using X-VRML to enable persistency
In Fig. 4.13, a configuration involving a database is presented. TheX-VRML language is used here not only to simplify the implementation and provide parameterization but also to retrieve and visualize data from the database. This configuration is often used in data visualization systems.
In Fig. 4.14, a configuration that enables implementation of persistency is presented. The state of the virtual scene is retrieved from a database during the virtual scene template processing on the server side. The virtual scene instance running in a 3D/VR browser can update information in the database by the use of Script nodes connecting to the database, either directly or, e.g., through Web Services (dashed line in Fig. 4.14).
Architecture of a dynamic X-VRML system employing server-side processor is presented in Fig. 4.15. The use of a dynamic X-VRML processor on the server-side is possible in streaming systems, e.g., based on the MPEG-4 standard. In such systems, updates to virtual scene instances are possible through BIFS Update commands [18, 26]. The dynamic X-VRML commands implementing interactivity cannot be used in this configuration.
Fig. 4.15 Dynamic X-VRML processor running on the server-side
Fig. 4.16 Using fixed X-VRML processor on the client-side
Client-Side Processing of X-VRML
In 3D/VR applications based on most of existing content standards, such as VRML/ X3D, there is no possibility of updating the virtual scene content from the server, as in case of MPEG-4 systems. Therefore, processing of dynamic X-VRML commands requires client-side interpretation. Client-side interpretation of X-VRML enables use of all dynamic X-VRML commands, including commands responsible for handling user interaction (such as Listen or SendEvent—cf. Sect. 4.4.6), which cannot be executed on the server side. Using X-VRML on the client side is also advantageous in virtual scene templates that apply algorithms for building complex content elements. Transmitting X-VRML program instead of the whole representation of a complex virtual scene, in most cases, results in considerable reduction of the bandwidth requirements.
In Fig. 4.16, a system configuration with X-VRML processor running on the client side is presented. X-VRML virtual scene templates are delivered to an X-VRML compliant browser. The browser contains implementations of the X-VRML processor and the X-VRML commands.
Fig. 4.17 Using downloadable X-VRML processor on the client-side
The dynamic X-VRML processor can continuously manipulate the virtual scene instance. The processor can react to events coming from the virtual scene instance and can cause updates to the virtual scene instance. A client-side X-VRML processor can also connect to a database (directly or through Web Services) in order to read or update the database content. This enables implementation of continuous data visualization and persistency. The disadvantage of this solution is that a specific X-VRML compliant browser is required.
In Fig. 4.17, a modification of the system architecture is presented. It also employs the dynamic client-side interpretation of the X-VRML code with all the advantages of this approach, but the application code of the X-VRML processor and the implementations of the X-VRML commands are dynamically downloaded from the server side (e.g., as an applet). This enables the use of a standard Web browser without the necessity to install any additional software. Also, it enables extending the capabilities of the system by adding new X-VRML commands on the server side without the need to change the client-side configuration.
Advanced Architectures
A mixed server-side and client-side architecture of an X-VRML system is presented in Fig. 4.18. There are two X-VRML processors in the system: one operating on the server side and one operating on the client side. The server-side interpreter uses one set of X-VRML commands interpreting some of the X-VRML elements in the X-VRML template. The output of the processing is also an X-VRML template (denoted here as X-VRML’) but containing only those elements that have not been interpreted by the server-side processor. The resulting X-VRML’ template is further interpreted by the client-side X-VRML processor.
Fig. 4.18 Mixed server-side and client-side interpretation of X-VRML
Fig. 4.19 Double processing of X-VRML meta models on the server side
Such configuration enables implementing features such as content selection, retrieval of data from databases and initial processing on the server-side, while enabling interpretation of the dynamic X-VRML elements on the client side (e.g., for implementation of persistency).
Another version of the system architecture that involves double processing of X-VRML templates is presented in Fig. 4.19. An X-VRML metamodel (metatemplate) is processed by the interpreter equipped with a set (A) of X-VRML commands. The result of parsing becomes an X-VRML’ template that is further processed by the same processor, but possibly using another set (B) of X-VRML commands. Some of the X-VRML commands can be used in both processing phases. Double processing enables retrieval of X-VRML templates from a database. The retrieved templates can be then processed by the X-VRML processor to produce final virtual scenes or, again, X-VRML templates for client-side interpretation (cf. Chap. 10).
