| Development Tools / Databases |
This final year project was designed and developed with the following tools and databases:
| Tested Platforms / Web Browsers |
It has been tested to run on the following platforms / browsers:
Two similar versions of this Distributed Multimedia Database Application were designed and developed. Figure 1 depicts the Open System Interconnection (OSI) 7 Layer Model for RMI and Common Object Request Broker Architecture (CORBA). Figure 2 depicts the architecture using Pure Java with CORBA (Visibroker for Java was used as the Object Request Broker (ORB)) while Figure 3 depicts the architecture using Pure Java with RMI.
| OSI 7 Layer Model for RMI and CORBA |
(Click on image to view the actual resolution)
Figure 1 OSI 7 Layer Model for RMI and CORBA
| Pure Java with CORBA as middleware |
Figure 2 Multimedia Application System Architecture (Pure Java with CORBA as middleware)
The concept of CORBA was utilised to transfer multimedia data (i.e. images, audio and video) in a distributed environment.
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). Since the Informix Database supports the storage of data as Binary Large Object Blocks (BLOBs), all the multimedia data were stored in their native binary format in a particular column of the database table. Owing to the fact that the Access Database does not support the storage of data as BLOBs, the multimedia data can only be stored as a string containing the filename (i.e. a pointer) to the multimedia files stored on the local harddisk. Java was used as the programming language to implement the "servers", owing to the "Write Once, Run Anywhere" credo. The connection between the servers’ implementations and the Informix Database was accomplished via its native JDBC driver while that with the Access Database was accomplished via its native ODBC driver and Sun’s JDBC-ODBC bridge. These two "servers" were placed on the Intranet with VisiBroker acting as the middleware ORB.
The following features were provided by the client's implementations via a Graphical User Interface (GUI):
The client’s implementations comprised of a Java 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. Note that Netscape Communicator Versions 4.03 to 4.05 require an additional patch for JDK 1.1 support while Versions 4.06 and later have the JDK 1.1 support built in.
The gatekeeper (provided by VisiBroker) serves as an IIOP server which also 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.
All the user interfaces were created using JFC Swing APIs while JMF APIs were used to display multimedia clips. The applet presents a GUI for any client(s) to search through two tables residing in two different databases (i.e. Access and Informix Databases) running on two different operating systems (i.e. Windows 95 and Solaris). After searching the selected database(s), a Results Table will be displayed containing record(s) matching the search criteria. The user may then view the desired multimedia clip by selecting a particular row of the Results Table.
| Pure Java with RMI |
Figure 3 Multimedia Application System Architecture (Pure Java with RMI)
The concept of Java’s RMI was utilised to transfer multimedia data (i.e. images, audio and video) in a distributed environment.
A 3-tier heterogeneous environment similar to the one described earlier was set-up. The main difference lies in the middleware used. The previous version 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. Both the Access and Informix servers' implementations were then placed into the Intranet with the help of RMI registry.
In addition, the RMI version consists of an additional "RMIBroker" Server that functions 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 RMIBroker invokes any servers’ implementations on behalf of the client. Note that the RMIBroker Server must be located on the same host as the Web Server (HTTP) hosting the HTML page (i.e. ClientMultimediaApplet.htm) embedding the ClientMultimediaApplet.class.
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 RMIBroker's implementations instead of the servers' implementations.
In contrast to the CORBA version, the servers' implementations and the RMIBroker Server can be located on any Extranet. The requirements for the client remain the same as before.
Copyright© 1999 by Chue Wai Lian and Tan Choon Boon
Last updated on Sunday, 14 November 1999
Please send all mails to wailian@singnet.com.sg or tancbcb@singnet.com.sg