Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
BADA-III/Web: Integration of the Web and an OODBMS Wan-Seok Kim Jang Sun Lee Myung-Joon Kim ETRI, Computer & Software Technology Labs. Data Engineering Department 161 Kajong-Dong, Yusong-Gu, Daejon 305-350, Korea
[email protected] [email protected] [email protected]
Abstract We believe in terms of information service systems that one of the best ways to develop a large scale database service system is to integrate the service capability of the Web and the data management facility of database systems in a complimentary fashion. In such integration a database gateway is the core component; the database gateway accesses database systems to serve the requests represented by using the Web technology. BADA-III/Web is a gateway that integrates the service capability of the Web and an OODBMS called BADAIII in a complementary manner. In this paper we describe our design and implementation experience in integrating the Web and BADA-III, and also explore the e ects of BADA-III/Web with some synthetic queries.
1. Introduction Since the World Wide Web (WWW) [1] was developed at CERN in 1991, it has been growing in the internet community as a large scale internet-based hypermedia information system. The Web consists of a server and a client (see Figure 1). A Web server is typically equipped with CGI (Common Gateway Interface) [5] and hypermedia documents that are written in HTML (Hyper Text Markup Language) [2]. HTML is based on tags rather than presentation, which makes it possible to present the documents in many heterogeneous platforms. The documents typically contains links to other related data or other hypermedia documents. A Web server supports HTTP (HyperText Transfer Protocol) [3] as its communication protocol between a server and a client. A Web server accesses documents or multimedia data with URL (Uniform Resource Locator) [4] from a client, transforms the documents into
an HTML documents with CGI if it is required, and sends the documents to a client. A client interprets and presents the documents to users through a Web browser or an external viewer. The Web solves the following technical problems to provide a global information sharing environment: 1) identi cation of data spreaded over the world [4], 2) description of hypermedia documents [2], and 3) communication protocol for transferring documents through networks [3]. However the Web has still problems to be solved for a large scale internet-based hypermedia information system. Firstly, it is not easy to organize and manage a lot of heterogeneous data, because the main storage of the Web is a le system. That is, the features, for organizing and managing a large scale of data, provided by le systems are so limited that it is not easy to develop database service systems. Secondly, HTML has limited capability to specify query forms; it is not easy to access HTML documents by specifying complex query forms. Thirdly, it is not easy to support stateoriented service, because the characteristics of HTTP communication protocol. On the other hand database systems provide a variety of features for organizing and managing a lot of data. But they have disadvantages in delivering or presenting data in a large scale internet-based hypermedia information system. Therefore, in terms of information service systems, we believe that one of the best ways to develop a large scale database service system is to integrate the service capability of the Web and the data management facility of database systems in a complimentary fashion as shown in Figure 1. In such integration a database gateway is the core component; the database gateway accesses database systems to serve the requests represented by using the Web technology. BADA-III/Web is a gateway that integrates the service capability of the Web and an OODBMS called BADA-III in a complementary fash-
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
1
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
World Wide Web client Web browser
external viewer
HTTP/URL/HTML CGI executable CGI Web server
DB application
. . . CGI executable
database gateway
file system
DB engine
database server
database system
Figure 1. Integrating the Web and database systems
ion. We designed BADA-III/Web be independent from the Web and DBMS as much as possible, which minimizes the performance overhead caused by connecting database systems (process creation). BADA-III/Web incorporates TCL [6] into a library of it and handles concurrent requests eciently. In this paper we describe our design and implementation experience in integrating the Web and BADA-III, and also explore the e ects of BADA-III/Web with some synthetic queries. The rest of this paper is organized as follows. In the following section we review some database gateways and analyze the strong and weak points of them. In Section 3 we describe the architecture of a database gateway we designed, including the design principles of the gateway. The implementation details and the experimental results are presented in Section 4 and 5, respectively. Finally, we make some concluding remarks.
2. Survey of database gateways Kim proposed a taxonomy for the architecture of database gateways in [9]. In the taxonomy the architecture of database gateways is classi ed into various categories based on the place where database accesses are accomplished: databases can be accessed from a sever- or client-side. In other words, we can integrate the Web and database systems by extending a server or client side. In the server-side extension a database gateway can be invoked by using CGI or API. Using CGI is further divided into CGI executable, where a database gateway
is a CGI executable itself, and CGI application server, where CGI just passes requests to separate database application servers. In the client side a database system can be directly accessed by extending a browser or using an external viewer of browsers, like an MPEG player. We are not interested in the architectures designed by extending the client-side, because the communication cost to connect database systems from the client is high. In this paper we only review the architectures which are included in the category of the sever-side extension. In the CGI executable architecture the integration of the Web and a database system is simple and straightforward because a database gateway can be implemented by using a development environment that is speci c to the Web or databases. It requires no changes in the Web servers or browsers. For each database request, in this architecture, the server spawns a database gateway process and then connects a database system through the process. The server terminates the gateway process after receiving the results from the process. This makes the optimized features of many DBMSs for repetitive database queries useless. In addition to that, in a large scale service environment where a large number of simultaneous requests to connect database systems should be handled, the performance degradation can be serious, because of the limitations of the system resources and the costs of process creation and communication between database gateways and the Web server. WebDBC [18], Cold Fusion [14], Web/Genera [19], GSQL [15], and WDB [13] are representative example products that have the CGI executable architecture. In the CGI application server architecture a database gateway is divided into two separate modules: dispatcher and application server. The dispatcher module is a CGI executable, which transfers a request to an appropriate application server. The application server module usually works as a daemon process that connects to the database system and waits for requests from dispatchers. The number of application server processes may be determined by considering the available system resources. This architecture can take the advantage of optimized features of DBMS mentioned above. On the other hand there can be extra costs caused by communications between processes. UniWeb [10], O2Web [11], and MARS [16] are example gateways that have this architecture. Some of proprietary Web servers, such as NSAPI of Netscape [20] and ISAPI of Internet Information Server [17], provide an extensible API that allows users to extend the functionality of the Web server. Thus a database gateway can be implemented by the extensi-
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
2
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
ble API and it is dynamically linked to the Web server process, which reduces the cost of process management in CGI. However, in this architecture, the implementation of a database gateway depends on the API of a proprietary Web server. On the other hand a database gateway can be implemented as a database client program. In other words the client program can be considered as a Web server that is specialized for a DBMS. In this case the implementation depends on a particular DBMS.
3. The architecture of BADA-III/Web
BADA-III is a multimedia database management system which has been developed at ETRI. It is an object-oriented database management system and supports the functions for information retrieval such as automatic indexing and content-based retrieval for fulltext and images [12]. 3.1 Design principles of BADA-III/Web
We believe in terms of information service systems that one of the best ways to develop a large scale database service system is to integrate the service capability of the Web and the data management facility of database systems in a complimentary fashion. BADAIII/Web is a gateway to integrate the Web and BADAIII. From the survey of the existing database gateways and the characteristics of BADA-III, we believe that BADA-III/Web should be designed by considering the following factors:
Web and DBMS independence: One of the
primary design principles of BADA-III/Web is to isolate it from the Web, HTTP communication protocol [3], and DBMS as much as possible. It seems ironical to make BADA-III/Web be independent from the Web and DBMS, because the main purpose of BADA-III/Web is to integrate them. However, it is necessary not only to avoid the burden of modi cation caused by rapid growing of the Web and communication protocols, but also to develop a database gateway using the standard API and connect it to the existing Web servers in a natural way. This requirement can be met by designing BADA-III/Web into separate modules: 1) a module that can be implemented without the knowledge of database systems { CGI executable, 2) a module that can be implemented without the knowledge of the Web environment { database application sever, and 3) a module that connects the two modules { monitor.
Low performance overhead: Connecting a
database system may su er from the performance overhead caused by process creation and termination, if the same application program that accesses the same database should be executed (process creation) in every request from clients. However, the overhead can be minimized by running the database application sever and the monitor as daemon processes: the application server waits for the requests from clients and the monitor connects the Web server and the database system. Ecient handling of concurrent requests: Concurrent requests from multiple clients should be eciently handled. Only one database application server that accesses the same database system is not enough to handle concurrent requests eciently. Concurrent requests can be handled by multiple database application servers. The requests should be distributed to all servers evenly. Integrating script languages: Script languages, such as TCL [6] or Perl [7], should be supported to express BADA-III/Web methods.
3.2 BADA-III/Web architecture
The major components of BADA-III/Web are the b3gateway, b3monitor, and b3apserver (see Figure 2); they share a message queue. A b3gateway is a CGI executable. It puts the requests from clients through a Web server on the message queue. It waits for the database results from the b3apserver after writing a request on the message queue; it analyzes the results expressed in HTML, sets the MIME type for the results, and sends the results with the MIME type back to the Web server. When BADA-III/Web is started, the b3monitor is created. B3monitor then creates application servers, b3apservers, by referring the parameters for the system environment, such as the name of application server, the number of application servers, and the path to the servers. The b3monitor process never terminates. It monitors all application servers by periodically checking the status of them and recovers the error if a server is not normal. It checks the messages on the message queue whether a request is a state-oriented one or it should be broadcasted to all application servers. If a request should be broadcasted to all application servers, the b3monitor makes n copies of the request, modi es each request for each application server, and writes them on the message queue, where n is the number of application servers. If a request is a stateoriented one, such as a transaction processing request,
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
3
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
WWW client network
WWW server
b3monitor
b3gateway
b3apserver + TCL
b3apserver + TCL
TCL file
b3apserver + TCL
..... b3apserver + TCL
BADA-III DBMS
words the gateway commands allow users to use the Web technology in doing database related things, such as constructing or updating database schemas, controlling transactions, management of classes, objects, methods, attributes, indices and users, data access authorization, query execution, and so on. Table 1 summarizes the gateway commands of BADA-III/Web. The gateway commands can be represented in HTML document or URL using GET or POST method of HTTP. Following is the format to represent a gateway command as the query string of the URL using GET method: function=functionname&arg1=value1&arg2=value2&...
database
For example, accessing the URL
Figure 2. BADA-III/Web architecture
the b3monitor creates a cookie to identify each request (In the next section we describe how state-oriented requests are processed by BADA-III/Web in detail). It also creates a new application server and then the newly created server processes the requests that have the same cookie without intervention of the b3monitor. The execution of the application server is terminated after processing the state-oriented request. B3apserver is the server of BADA-III/Web as well as an application of BADA-III database system. All b3apservers created by the b3monitor when BADAIII/Web is started never terminate. Each b3apserver actively processes the requests. In other words it reads a request from the message queue at a time, processes the request, writes the results on a certain place ( le), and noti es the completion of the request to the b3gateway. Each b3apserver repeats this procedure as far as there is a request on the queue.
4. Implementation of BADA-III/Web BADA-III/Web integrates the Web and BADA-III in a complimentary fashion. It provides a gateway to database systems and a facility to transform the database results into HTML documents. It also supports the following database functions for the Web: data access authorization, automatic recovery from various failures, management of les and indices, transaction processing, organizing complex data types and relationships, security, and etc. 4.1 Database gateway
BADA-III/Web provides gateway commands to control BADA-III database or retrieve data. In other
http://bada.etri.re/b3gateway?function= CreateClass&classname=new class& sends the data included in the query string to the HTTP server running on the machine bada.etri.re. In the query string a gateway command, CreateClass, is represented to request the creation of a new class named new class. 4.2 Data transformation
A Web client program can access data from many di erent servers. However the data is able to be transformed into HTML documents according to the intention of the programmer before sending the data from a server to the client. The database results are transformed into HTML documents in a b3apserver of BADA-III/Web. The data can be transformed into a certain format of document or a user-de ned format of document. BADA-III/Web provides DBA (DataBase Administrator) commands and a script language, TCL (Tool Command Language) [6], to support both types of transformations. The DBA commands are for the manipulation of database systems, such as schema(), class(), object(), attribute(), method(), query(), and etc.. They support only GET method of HTTP. The execution results of the commands are transformed into xed formats of HTML documents. For example, by accessing the URL http://bada.etri.re/b3gateway?schema() a user can get the information of a database schema. A b3apserver gets the information by executing schema() and then transforms the information into a xed format of HTML document; Figure 3 shows the result document.
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
4
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Group Schema
Table 1. Gateway commands of BADA-III/Web
Commands CreateClass DeleteClass ConnectClass DisconnectClass SubclassCounter GetSchemaCounter GetSubclassName Class AddAttribute DeleteAttribute UpdateAttributeName UpdateAttributeType AttributeCounter GetAttributeName Method AddMethod DeleteMethod UpdateMethodName UpdateMethodPath MethodCounter GetMethodName Index CreatIndex DeleteIndex GetIndex IndexCounter Authority PriviliegeCounter GetPriviliege PutPriviliege UpdatePriviliege Object AddObject DeleteObject DeleteAllObject ObjectCounter GetObjectPoid UpdateObject GetAttributeValue Query QueryResultCounter GetQueryResult Transaction TxBegin TxCommit TxRollback User RegisteUser DeleteUser UserCounter GetUsername UpdatePasswd
b3apserver kernel gateway commands
DBA commands
BADA-III C+++ API
TCL commands TCL C lib
Figure 4. Incorporation of TCL into the application server
Figure 3. Displaying a database schema through the Web server
BADA-III/Web allows users to de ne the format of HTML document they want to get from a server by supporting TCL. TCL is a high-level script language. It is similar to C shell [8] or Perl. It is interpreted, extensible, and embeddable in applications. To avoid describing the application server with TCL and the performance degradation caused by executing the TCL interpreter, we incorporated the main functions of the interpreter as a library, removed the shell structure of the TCL 1.17b1 and then reimplemented it as general functions in the b3apserver (see Figure 4).
The b3apserver kernel mainly consists of three modules: message interface, transformer, and scheduler (see Figure 5). The message interface reads one request at a time from the message queue and sends it to the transformer. It also noti es the completion of the request to the b3gateway. The transformer decodes the request. All requests but TCL les are processed through BADA-III API. If the request is to execute a TCL le, the kernel should map some interfaces for input/output into the corresponding ones of the b3apserver, because we deactivated them to incorporate TCL into the application server. Figure 6 shows an example TCL le that describes the procedure to get the attribute names of employee class from BADA-III database system and transform the information into a HTML document. The le shown in Figure 6 can be executed by accessing the URL http://bada.etri.re/b3gateway?function= tcl& lename=/getattribute.tcl& and the result is represented in Figure 7.
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
5
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
request transformer
result
message interface
scheduler
BADA-III C++ API database
TCL lib
b3apserver kernel
Figure 5. The architecture of b3apserver kernel
# le name :: getattribute.tcl # tcl scriptor le to get attributes put stdout \
attributes of employee class" set max [AttributeCounter employee] for fset i 1gf$i $maxgfincr igf put stdout "
$ith attribute name::" put stdout [GetAttributeName employee $i]
g
put stdout \
The names of $i attributes of employee class"
Figure 7. Result of the execution of a TCL file
the process is terminated after processing a transaction. Figure 8 shows how a transaction is processed in BADA-III/Web. b3gateway
b3monitor
TxBegin cookie
create a cookie create a b3apserver return a cookie
req. w/ cookie . . . req. w/ cookie TxCommit | TxRollback
message queue
b3apserver Initialization; if req. w/cookie{ copy request; } else if TxCommit{ process all reqs; } else if TxRollback{ remove all reqs; }
initial steps
Figure 6. An example TCL file
Figure 8. Processing transactions in BADAIII/Web
4.3 Transaction support
BADA-III/Web supports transaction processing. If a request written by the b3gateway on the message queue is a state-oriented one, b3monitor creates a cookie for the transaction to identify it from other requests. It returns the cookie to the b3gateway and creates a new b3apserver process with the cookie as a parameter of the process. The newly created server then processes the requests that have the same cookie without intervention of the b3monitor. Currently b3apserver processes all requests for a transaction in batch. That is, the requests are started to execute just after the b3apserver gets TxCommit or TxRollback request. The b3apserver make copies of the requests before TxCommit or TxRollback. The execution of
5. Performance evaluation of BADAIII/Web 5.1 Experimental design
In our experiments we con gured the system with a server machine that runs the Web server software, BADA-III/Web, and BADA-III DBMS, and a client machine that generates requests to the server as shown in Figure 9. Table 2 shows the machines we used in our experiments. In the client machine the main process creates child processes. The main process in the client waits
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
6
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
client
server Web server
main process
CGI executable
fork/exec
child process
child process
main process
child ... process
CGI executable
Web server
BADA-III/Web b3gateway
message queue
wait b3monitor
b3apserver
Figure 9. Testbed for performance evaluation
for the completion of all child processes. It collects the statistics, such as the number of requests that are generated by each process, average response time for each request even the response time mainly depends on the performance of a DBMS and network, and the failure rate of service. Each child process sends a request to the server with an URL using the HTTP protocol. It sends a request again after receiving the result from the server. In each child process this procedure is repeated 64 times. We varied the number of child processes, 1, 2, 4, 8, 16, and 32. In other words, the number of concurrent requests to the server is varied as many that of child processes, which is similar to varying the interarrival time of requests. Table 2. Computer systems for a client and server
System (Sun) CPU Memory OS Network
Client Ultra Enterprise 3000
Server Sparc 20
UltraSparc 4 (167 MHz) 1GB SunOS 5.5.1 10 MBPS
TI 1 (40 MHz) 256 MB SunOS 5.4 10 MBPS
In order to evaluate the performance of BADAIII/Web, it may be one of the best ways to implement representative database gateways on our testbed and compare the performance of them with that of BADA-III/Web. However it cannot be e ective in terms of cost and time. Thus, in our experiments, we implemented a database gateway that has the CGI-executable architecture rather than implementing/installing existing database gateways that have the
CGI application-sever architecture. In the BADA-III/Web a message queue is shared by b3gateway, b3monitor, and B3apserver. The b3gateway is a CGI executable and the b3monitor is a supervisor of b3apservers. Thus the number of concurrent requests being processed on the server will depend on the number of b3apservers. In our experiments we varied the number of b3apservers, 1, 2, 4, 8, and 16. 5.2 Results
The average response time for each request mainly depends on the performance of a database system and network. So it seems reasonable to measure the average latency of BADA-III/Web and CGI executable. In our experiments we de ned the latency of BADA-III/Web as the time taken to send a request to the server and receives a response. To eliminate the in uence of the network we run the client processes, BADA-III/Web, and the Web server on the same machine (Sun Ultra Enterprise 3000). In the experiments b3apserver of BADA-III/Web just returns an acknowledgement to a requester without accessing BADA-III to remove the a ect of the database system. Figure 10 shows the average latency of BADAIII/Web and CGI executable. For all cases the performance of BADA-III/Web is better than that of CGI executable. The average latency is decreasing as the number of clients increases, because the number of requests that can be concurrently processed at the server increases. Of course the latency decreases as the number of b3apserver increases. However, in the gure, even though it is di cult to represent the variation of the performance when the number of clients is varied from 16 to 64, the performance of both cases is gradually decreasing. It may be caused from the limitation of resources and context switching time of processes.
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
7
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
900
740 1 b3apserver 2 b3apservers 4 b3apservers 8 b3apservers 16 b3apservers CGI executable
800
700
Average Response Time (ms)
720
600 Average Latency (ms)
1 b3apserver 2 b3apservers 4 b3apservers 8 b3apservers 16 b3apservers
730
500
400
300
710
700
690
680
200
670
100
0
660 1
2
4
8
16
32
64
1
2
Number of Clients
4
8
16
32
64
Number of Clients
Figure 10. Average latency of BADA-III/Web and CGI executable
5.3 Sensitivity
To evaluate the sensitivity of BADA-III/Web to the network and a database system, it can be possible to vary the performance of the network and the database system. In our experiments we did not change the performance of the network, but we applied a simple query for accessing BADA-III. In the experiments the test database consists of a class, employee class which is shown in Figure 7. Following is the query we used in the experiments: select * from employee where salary > 80000 Figure 11 shows the average response time for the query. We did not compare the performance of BADAIII/Web with that of CGI executable, because we already noticed that the latency of BADA-III/Web is better than that of CGI executable. The graphs in Figure 11 have similar pattern to those shown in Figure 10. That is, the average response time is decreasing as the number of clients increases, because the number of requests that can be concurrently processed at the server increases. However the response time increases, as the number of clients increases over 32, because the number of requests on the queue is much more than that of b3apserver that process the requests. There is a little uctuation in the graphs, but that may be caused by the unstability of the network.
6 Concluding remarks and future work In terms of information service systems it is said that one of the best ways to develop a large scale database service system is to integrate the service capability of the Web and the data management facility of database
Figure 11. Average response time of BADAIII/Web
systems in a complimentary fashion. In such integration a database gateway is the core component; the database gateway accesses database systems to serve the requests represented by using the Web technology. BADA-III/Web is a gateway that integrates the service capability of the Web and an OODBMS called BADAIII in a complementary manner. We designed BADA-III/Web be independent from the Web and DBMS as much as possible, which minimizes the performance overhead caused by connecting database systems and makes BADA-III/Web portable. BADA-III/Web incorporates TCL into a library of it and handles concurrent requests eciently. In this paper we describe our design and implementation experience in integrating the Web and BADA-III: we evaluate the performance of BADA-III/Web by measuring and comparing the latency and average response time for a simple query with that of another database gateway. The performance comparisons emphasize the importance of the architecture of database gateways. Currently BADA-III/Web processes state-oriented requests in batch, but we are planning to support those requests more eciently. We are also planning to extend/modify BADA-III/Web to integrate with a CORBA gateway, and to access other database systems in the future.
References [1] T. Berners-Lee, R. Cailliau, J.-F. Gro , and B. Pollermann, \World-Wide Web: The Information Universe," Electronic Networking: Research, Applications, and Policy, Vol. 1, No.2 Westport CT, 1992, pp.52-58. [2] T. Berners-Lee and D. Connolly, \Hypertext
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
8
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
[3] [4] [5] [6] [7] [8] [9] [10] [11] [12]
[13] [14]
Markup Language Speci cation { 4.0," W3C's Recommendation, Dec. 1997. T. Berners-Lee, \Hypertext Transfer Protocol { HTTP/1.1," Internet RFC 2068, May 1997. T. Berners-Lee, \Uniform Resource Locators," Internet RFC 1808, Dec. 1995. D. Robinson, \The WWW Common Gateway Interface Version 1.1," Internet Draft, Jan. 1996. J. Ousterhout, Tcl and The Tk Toolkit, Addisonwesley, 1994. Larry Wall and Randal L. Schwartz, Programming Perl, O'Reilly & Associates, Inc, 1990. Martin R. Arick, Unix C Shell Desk Reference, John Wiley & Sons, 1993. P.-C. Kim, \A Taxonomy on The Architecture of Database Gateways for The Web," Proc. of the 13th ICAST and 2nd ICMIS, Shaumburg, IL, Apr. 1997. P.-C. Kim, \UniWeb { A Database Gateway for The Web," Database Journal, Vol. 3-1, 1996, pp. 65-84. L. Latham, \Client/Server Computing: Strategic Directions, Tactical Solutions," InSide Gartner Group This Week, Vol. X, No. 20, Gartner Group, May 18, 1994, pp. 1-5. M. O. Choi, M. Y. Lee, S. T. Jun, J. Kim, O. J. Cho, Y. K. Kim, and K. H. Hong, \Design of The Object Kernel of BADA-III: An ObjectOriented Database Management System for Multimedia Data Services," Proc. of the Workshop on Network and System Management, 1995. Bo Frese Rosmusen and Beno Pirenne, \WDB { A WWW to Sybase Interface," Proc. of the Workshop on Network and System Management, 1995. \Allaire ColdFusion Overview," 1995,
http://www.allaire.com.
[15] Jason Ng, \GSQL { A Mosaic SQL Gateway," Dec. 1993, http://www.ncsa.uiuc.edu/SDG/
People/jason/pub/gsql/starthere.html. [16] \Mars: Internet Transaction Processing," http: //www.progress.com/beta/internet/mars. [17] \Internet Server API Overview," http://www. microsoft.com/win32dev/apiext/ isapimrg.html. [18] URL: http://www.stormcloud.com. [19] URL: http://gdbdoc.gdb.org/letovsky/ genera/ genera.html. [20] URL: http://www.netscape.com.
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
9
