Chue Wai Lian's 2nd ICICS 1999 Research Paper

2nd International Conference on Information, Communications and Signal processing (ICICS) 1999

Distributed Multimedia Database:

Configuration and Application

Michael J. Hu, Thio Fu Wang, Tan Choon Boon and Chue Wai Lian

School of Electrical and Electronic Engineering

Nanyang Technological University, Nanyang Avenue, Singapore 639798

ABSTRACT

In this paper, we investigate the concept, configuration, and applications of distributed multimedia database. A standard three-tier client-server configuration is proposed in the paper, including 1) database server, 2) middleware and underlying network infrastructure, and 3) client design. We provide our evaluation of the latest technique developments related to different parts of the configuration, and discuss various options for distributed computing in heterogeneous environment. We also present a case study/application of concept and configuration discussed in the paper, and review our implementation of an object-relational multimedia database using Informix Universal Server (IUS), CORBA/Java, and a client interface developed by our team.

1. INTRODUCTION

In this paper, we investigate the concept, configuration, and applications of distributed multimedia database, using the latest technical development of middleware and application-oriented frameworks. The rest of paper is organised as follows. First, in Section 2, a standard three-tier client-server configuration is proposed. It includes: 1) database server, 2) middleware and underlying network infrastructure, and 3) client design. We provide in the section our evaluation of recent technique developments related to different parts of such a configuration, and discuss various options that are applicable as guideline for design and implementation of distributed multimedia database. Thereafter, we present in Section 3 a case study/application of concept and configuration discussed in the paper, by reviewing our implementation of an object-relational multimedia database using Informix Universal Server (IUS), CORBA/JAVA, and a client interface developed by our team. We shall discuss our future research direction and reach our conclusion in Section 4.

2. THREE-TIER CONFIGURATION FOR DISTRIBUTED MULTIMEDIA DATABASE

A standard three-tier client/server architecture is proposed in this paper for the development of the distributed multimedia database. It would allow a 'middleware gateway' approach, which conforms to distributed object platform. This configuration has the added incentive of having a 'thin' client concept, rather than providing dynamic feedback via the clients' machines through scripts, such as cookies, Java Scripts and Dynamic HTML (DHTML).

Figure 2.1 A three-tier client/server architecture

2.1 DATABASE SERVER

The back-end tier of the architecture involves the storage and retrieval of multimedia data on the database server. In this paper, the Object Relational Database Management (ORDBMS) is used for the development of multimedia database as it allows queries to be performed on complex data, e.g. video, audio, etc.. The following were used for the development of the database servers:

1.   Informix Dynamic Server ver 9.14 with Universal Data Option
2.   ESQL/C Scripts
3.   Structure Procedural Language (SPL) routines.

The multimedia database is developed using the data model as shown in Figure 2.2. There are two groups of media objects in the data model: the atomic media object and composite media object. An atomic media object constitutes the smallest conveyer of multimedia. A number of media objects can be aggregated into bigger and more complicated composite media objects, according to certain syntactic and semantic grammar rules defined.

Figure 2.2 The multimedia data model

The following multimedia database shown in Figure 2.3 has been developed on the Informix Universal Server (IUS). It consists of the hierarchical model that is based on the concept of supertype and subtype. The model is developed using the complex data type; row type and it followed closely on the multimedia data model described earlier. The typed table is then created from this row type, producing the supertables and subtables relationship. Both this row type and the typed tables support inheritance, which conform to the object-oriented architecture.

Figure 2.3 A hierarchical model of multimedia database

The design of multimedia database starts by a process called a generalisation. This process is necessary to find out the most generalised attributes from all other attributes and then, group these generalised attributes into a parent table. The parent table would form a supertable. All its operation and function would be inherited by the subtables. The next process is called a specialisation process. It refers to how attributes of a specific nature or domain can be grouped into a common table. Thus, the subtables are resulted from the process of specialisation. If there is a need to extend the hierarchy further, the generalisation and specialisation process is repeated again.

2.2 MIDDLEWARE

For the middleware, the concept of CORBA was utilised to transfer multimedia data (i.e. images, audio and video) in a 3-tiers heterogeneous environment. The following software were used for development:

a.   VisiBroker for Java Version 3.2 from Inspire.
b.   Java Development Kit (JDK) 1.1.7B from Sun Microsystems.
c.   Java Foundation Classes (JFC) Swing Version 1.1 from Sun Microsystems.
d.   Java Media Framework (JMF) Version 1.1 from Sun Microsystems.

Figure 2.4 CORBA as middleware

The servers comprised of servers' implementations that were responsible for executing an input query statement from the client(s) and returning the query results back to the client(s). Java was used as the programming language to implement the "servers" due to its portability. The connection between the servers' implementations and the Informix ORDBMS was accomplished via its native JDBC driver. These two "servers" were placed on the Intranet with VisiBroker acting as the middleware ORB.

The gatekeeper (provided by VisiBroker) serves as an IIOP server which can doubles as a Web Server (HTTP) supporting Secure Socket Layer (SSL). It also enables VisiBroker applets to communicate with servers' objects across networks while still conforming to the security restrictions imposed by Web browsers and firewalls. Thus, the gatekeeper serves as a gateway from an applet to server objects even if a firewall is restricting access. Note that all the servers' implementations, gatekeeper and osagent must be running within the same Intranet, while the client(s) may be located anywhere in the Internet in order to access the applet.

Figure 2.5 RMI as middleware

A 3-tier heterogeneous environment similar to the one described in the previous section was set-up. The main difference lies in the middleware used. The previous application used a CORBA compliant ORB called VisiBroker for Java from Inspire while the RMI version used a proprietary ORB called RMI and Object Serialisation from Sun.

Both the CORBA and RMI servers' implementations used similar instructions with the exception that the latter implements the Java's remote object instead of extending CORBA's object. In addition, the RMI version consists of additional "Broker" implementations that function as a broker between the servers and the client(s) (i.e. similar to the function performed by the gatekeeper in VisiBroker for Java). The "Broker" invokes any servers' implementations on behalf of the client. Note that the "Broker" must be located on the same host as the Web Server (HTTP) hosting the client implementations. Since Java's applet sandbox security in the web browser prohibits the client's applet to establish direct connection to other servers except from the host where it was downloaded, the client's implementations must bind to the "Broker's" implementations instead of the servers' implementations.

The following lists out the comparisons between the different implementations between CORBA and RMI.

Table 1 Comparison between CORBA and RMI

Areas	RMI	CORBA
Efficient and light-weight mechanism	RMI is a very efficient mechanism that uses a standard optimised protocol to communicate between remote Java objects. Data marshalling and object serialisation are done transparently. At the time of this writing, JavaSoft has released a beta version of RMI on top of IIOP.	Once Java applets are downloaded and running in the Web browser's Virtual Machine, they can talk directly to other distributed objects, bypassing the HTTP server. This transparent message routing is done through IIOP and frees the Web servers of extra communication management.
Legacy integration	RMI is a pure Java solution, which allows the Java model to be maintained all along. The "100% Java" policy has the evident drawback when compared with CORBA solutions, which it does not allow interaction with objects written in different languages.	Using CORBA IDL, programmers can encapsulate existing applications in wrappers and use them as objects on the ORB. CORBA-based systems allow developers to re-use legacy applications, therefore preventing them from rewriting everything from scratch.
Distributed garbage collection	The RMI system allows garbage collection of active objects. Remote objects that are no more referenced are automatically pull out of memory on both the client and server sides. The distributed garbage collection mechanism works transparently and therefore frees the programmers of all the memory management.	Some CORBA products implement automatic server deactivation after some time-out or some specific garbage collect mechanism, thus preventing memory leaks happening to CORBA objects whose clients unexpectedly disappear.
Passing object by value and by reference	RMI allows two communicating applications to handle a reference to an object, instead than its complete value. This can be done if the Java object implements the java.rmi.remote interface.	Like RMI, CORBA allows two communicating applications to handle a reference to an object, instead than its complete value This is done by declaring the object interface in the IDL.
Location transparency	Currently, RMI provides an URL-based naming service to locate remote object, but the service is very primitive and non-persistent. Therefore, once the server in charge of the naming context is down (i.e. hosts running rmiregistry), no more names or references to remote objects that had registered their service are available.	In contrast, CORBA provides location transparency. An object reference is independent of both the object physical location and a potentially change of this location. This means that developers can create robust CORBA-based systems where object can be moved without breaking all the applications that use them.
Dynamic Interface Invocation	No Dynamic Interface Invocation. In RMI, a client can't make invocation on a server if it doesn't have the server's stubs. But RMI supports dynamic class (and thus stubs) downloads. Application behaviour can actually be extended dynamically.	CORBA clients can both use static and dynamic methods invocations. They either statically define their method invocations through stubs at compile time via IDL, or have the opportunity to discover objects' methods dynamically during run time.
Load balancing	RMI does not provide load balancing. RMI only allows you to install your objects on the same machine as the web server, instead of on any machine in your network as CORBA allows it.	CORBA provides load balancing to distribute charge across multiple machines and persistence for both object states and object references.
Download time	No extra download time other than the servers' stub and client's implementation bytecodes.	To be able to communicate with another CORBA object, the Java applet running in a Web browser needs an ORB to talk to. Therefore, an "orblet" is downloaded along with the classes that form the applet.

2.3 CLIENT DESIGN

The client's implementations comprised of a Java graphical user interface (GUI) applet, which may be executed on any Java enabled web browser supporting JDK 1.1. Suitable web browsers include Netscape Communicator and Sun Microsystems HotJava. In addition, the client implementations would have the following features:

a.   Addition/removal of any data on the multimedia database dynamically.
b.   Administrative database security features.
c.   Displaying of the query results.
d.   Integrated media player.
e.   Indexing and retrieval capabilities.

The following software are used for the development of the client's implementations:

a.   Java Development Kit (JDK) 1.1.7B from Sun Microsystems.
b.   Java Foundation Classes (JFC) Swing Version 1.1 from Sun Microsystems.
c.   Java Media Framework (JMF) Version 1.1 from Sun Microsystems.

3. A CASE STUDY

In order to have a complete integrated framework of distributed multimedia database, a case study would be explored and the relevant implementations on each layer of the architecture would be briefly discussed.

An online music centre is best suited for the implementation of distributed multimedia database. This application would enable the prospective consumer to evaluate the sample songs from a particular album and view the MTV video clips 'on the fly', just simply by searching through the multimedia database. The musical store might have several stores and each one might have different collections of music to suit a particular group of consumers. All of the stores' CDs could be linked via a distributed multimedia database, thus, enabling the user to perform one complete search on several chain of stores, simply by selecting the musical stores website. Interactivity with the prospective consumer is permitted by enabling them to submit their preferred songs. This would, in turn, be processed through the multimedia index and matched the songs to the particular album, which belong to the songs. As such, the consumer does not even need to know the singer of the song, or the album of the song, in order to perform the search. Obviously, the consumer is prevented from meddling with the database by simply deleting the records. This is where the administrative database security features come in handy. On the other hand, the owner of the store could expand his business to include video-on-demand services to view the latest movies or VCDs. This would not need any new changes of configuration on the middleware side (CORBA/RMI). He would only need to extend his multimedia database to include that of video clips, trailers, etc. Instead of having just an online music centre, it could be easily transformed to an online entertainment centre.

The abovementioned case study is just one of the many applications that would be enhanced by implementing the distributed multimedia database.

4. CONCLUSION

The domain of distributed multimedia database is still evolving and remains a constant pursuit by many researchers all over the world. In this paper, we report our on-going project related to distributed multimedia database. In particular, we have presented our proposed architecture of distributed multimedia database and discussed the middleware implementations between CORBA and RMI. We are still working on the real-time streaming of the video clips and other modules, such as, multimedia indexing and searching/retrieval would be added into our system architecture in the near future to support automated queries on multimedia data.

Last updated on Wednesday, 26 December 2007

Please send all mails to wailian at hotmail dot com