This paper discusses a database application development framework on WWW, considering composite database object handling. It is important to have access to database management systems for WWW applications because the WWW becomes to deal with information that is updated in run time or has complex data structure. However, there are some drawbacks to using conventional WWW-DB integration systems based on relational structure. First, RDBMSs can deal with only simple data (numerical values and strings), and they provide only a simple database access method such as SQL. Second, although Java technology can be used for compensating the poor expression in generated HTML text, WWW-DB integration systems have not been fully integrated with Java applets. Third, the generated HTML documents have only fixed forms because access rights cannot be given to elements in HTML template files. In this paper, a WWW-OODB integration system PERIDOT is proposed. Composite objects that have complex data structures are used effectively in PERIDOT in order to solve the above-mentioned drawbacks. A method, which converts composite objects to HTML text using extended HTML templates, and a mechanism that delivers composite objects from database access methods to HTML templates using unified interfaces, are provided. The API to access an OODBMS is also provided using Java technology in order to display formats that cannot be expressed in HTML texts. HTML templates are divided into their elements and stored in OODBs as composite objects. As the result of the approach, WWW content data with a complex data structure can be displayed in any format after they are acquired from databases with a suitable access method.
WWW (World-Wide Web) is expanding around the world. Although the WWW was originally developed for the purpose of sharing documents stored in various places, WWW technologies have recently been used for several network applications and intranet systems. Prototype systems can be rapidly developed using WWW technologies because simple standard protocols, such as HTTP (HyperText Transfer Protocol) and HTML (HyperText Markup Language), are used, and a WWW browser can be applied to all WWW applications as the I/O processor interacting with end users. Therefore, WWW application programmers can develop several programs only on WWW servers. There is an eager demand for integration with database management systems in order to dynamically generate information presented for end users in client sites. If the demand is realized, several services, for example news delivery, online shopping, and airline reservation, will be implemented on WWW.
WWW-DB integration systems have been developed by many database vendors and WWW server vendors. Almost all these systems are connected with RDBMSs (Relational Database Management Systems) [NgSr96]. The databases managed by RDBMSs have data structures based on a two-dimensional table, and the database access interface employed by RDBMSs is SQL (Structured Query Language). Various query statements to RDBs can be declared using SQL because SQL is a strong declarative query language based on relational algebra. In WWW-DB integration systems connected with RDBMSs, these query declarations are described in HTML template files. When users submit database requests on the systems, the results are converted to HTML text after accessing a database. Furthermore, Java technology is being applied to accessing RDBs through the WWW [Duan96]. So, various simple WWW applications can be easily developed using these systems.
However, conventional WWW-DB integration systems have several drawbacks with respect to connection with RDBMSs. Moreover, these systems are provided only for the development of database access parts, not the development of whole WWW applications. In this paper, the following facts are especially noted.
In this paper, a WWW application development framework, into which object-oriented technologies are introduced for database access, will be proposed. Although system architecture for accessing OODBs has been proposed, it is not fully integrated with object-oriented technologies [VNCK96] [YaKa96]. The framework provides a) composite object conversion, b) Java object retrieval, and c) content element management, in order to solve the above-mentioned drawbacks respectively. A WWW-OODB integration system based on the framework is developed. Although it has a similar system architecture to that of conventional WWW-DB integration systems, it can produce several flexible interfaces using composite objects.
The special features are: 1) converting composite objects to HTML text, and supporting a common interface between HTML conversion methods and database access methods; 2) displaying composite objects in an OODB on WWW browsers using Java technology; 3) storing HTML templates in an OODB, divided into elements. As a result of introducing these functions, flexible WWW-OODB integration systems can be provided. In section 2, an example of a WWW application integrated with a DBMS and the system structure of a WWW-OODB integration system is given. The major system features are mentioned in sections 3 (composite object conversion), 4 (Java object retrieval), and 5 (content element management). Comparisons between this system and other systems are discussed in section 6. Finally, section 7 makes concluding remarks.
The WWW-OODB integration system is developed as the middleware to run on WWW servers in order to provide internet database services. The system is the gateway software that is connected with an OODBMS for various WWW applications and includes object-oriented technologies using OODBMS PERCIO [TKNY96], developed by NEC Corporation. This project is named PERIDOT (PERcio Internet Database by Object Technology). In this section, the objectives and an example of a WWW application are described and the system structure is surveyed.
The system has the following objectives.
In the following sections, several technical methods of achieving these objectives are proposed.
In this paper, a corporate information system is used as an example of a WWW application in order to explain the methods for achieving objectives raised in the previous subsection. The class structure of the example system is shown by the OMT class diagram in Figure 1. A database generated using the class structure is composed of three kinds of data: organization data, plant data, and rail line data. Organization data is expressed with nested relations of business groups and departments in a corporation. Plant data consists of departments belonging to the plant, a nearby station, and route data from the station. Rail line data is a linked list between contained stations. These data are stored in an OODB relating them to each other by object pointers.
The following functions are provided in this system.
WWW-DB integration systems are usually implemented by using gateway interfaces provided in HTTP servers such as CGI (Common Gateway Interface) or server API (Application Programming Interface), for example ISAPI (Internet Server API) and NSAPI (Netscape Server API). These systems are gateway systems that exist between an HTTP server and a DBMS. The WWW-OODB integration system described in this paper is also one of them and its system structure is shown in Figure 2.
It consists of the following three components:
These components access three kinds of databases: application databases, administration databases, and content databases. Administration databases and content databases are used in the PERIDOT server. The former is used for managing user and session information, and the latter is used for storing various content data on WWW applications.
A rule has to be applied to converting composite objects into HTML text. A composite object is a cluster of objects that are related with each other by object referential relationships and object collection relationships. It is an important feature in OODBMSs because it is closely related to the data structures in OODBs. The multi-media data can be stored in an OODB as a composite object. Although composite objects are adequately dealt with in conventional WWW-DB integration systems, the conversion technology from composite objects to HTML text is not provided.
WWW applications access databases through database access methods. Users specify a target database access method by giving the name in URL parameters. This parameter is received by a HTTP server, and it is delivered to the PERIDOT server. The PERIDOT server creates a thread for processing the requested database access. The shared library that includes the target database access method is dynamically linked to the PERIDOT server with ActiveX technology, and the access method is called. After this database access is finished, some database accesses may occur if additional data is required to generate HTML documents.
Database access methods can be written in several languages, such as query languages or programming languages supported on PERCIO. The interface between the PERIDOT server and a database access module is the API provided by ActiveX technology. Therefore, database access methods are ActiveX controllers and PERIDOT server is an ActiveX container. There is a referential table between a method name and a method interface, and the database access method correspondence is kept using the table. In response to an access request, the method accesses databases guided by a procedure prepared for the method, which is developed by WWW application programmers.
The results of a database access are used as the object references to collections or as objects for a HTML template specified in the database access method. In the HTML template, the object references are described in the places filled by the result data. It is important to provide a common access interface for the results, because it is desirable for WWW application programmers to develop WWW applications without regard to differences between these methods.
The names (object variable names) and the values (object variable values) of the results, which are open to the HTML templates, are specified in the database access method in order to be able to access the received data in the HTML template. This correspondence relationship is managed by a table in the PERIDOT server. The object variables' signatures are registered in the table. The table is usually referenced when an HTML document is generated using the HTML template. Object variables described in the HTML template refer to object entities in the OODBMS object cache used by database access methods.
The variables bound to object variables are ActiveX controller properties of the database access method. These values are assigned to variables and methods (functions) that have returned the object reference for an object or a collection. Moreover, an interface to embed HTML text in the HTML template is provided. This text is generated using HTML library functions.
The HTML template specification is based on HTML extension files that are regulated in IDC (Internet Database Connectivity, developed by Microsoft Corporation). Many keywords and control statements are included in the template. HTML document generation is controlled by them. Moreover, the template specification is extended in order to support object references and object collections. The objects in an OODB is obtained from an object cache managed by an OODBMS while a HTML document is generated.
Each object access is specified by an extended tag in the HTML template. When the HTML document is generated, the extended tag is converted to HTML tags. It is necessary that the portions, in which data outputs from the database access method are embedded, are enclosed by <%begindetail%> and <%enddetail%>. Object variables and control statements are described in this part of the HTML template. Member variables that have strings or numeric values must be received through object variables because an object variable is a reference to an object or a collection. Thus, the dot expression is introduced. In the case of accessing a member variable of the object bound by an object variable, the following description is used.
<% (object variable name).(member variable name) %>
The value of a member variable is embedded in the HTML document after converting it to a string.
An object variable bound to a reference of a collection object cannot be converted to HTML text as it is. Therefore, elements in the collection object are taken out using the following control statements.
<% foreach (variable) in (collection) %>
<% do [(condition)] %>
(HTML text)
<% done %>
In the above statements, variable is any variable name, and collection is an object variable name bound to a reference of the collection object. condition has the format of ``(value1) (operator) (value2)'' or ``until (number)''. Every element in the specified collection is assigned to the declared variable one by one, and the variable can be used like other variables in the portion enclosed with <% do %> and <% done %>. Moreover, if condition is specified in <% do %>, elements in the collection can be divided up for processing by the condition.
The procedure for converting composite objects is shown in Figure 3. As shown in the figure, foreach statements can be nested, and the depth-first search is applied to access these composite objects.
Java technology has been used for displaying moving content data, such as an animation, or for interacting with users, such as a game, on WWW browsers. The technology has a feature that applets stored in a WWW server are downloaded to a WWW browser when a user requests the HTML document that includes them. In this section, OODBMS interfaces are mentioned in order to apply this feature to target WWW applications.
Java applets are used for display forms that cannot be expressed in HTML text. Data retrieved from databases are delivered to the Java applets, and displayed with any format on WWW browsers after processing them. Therefore, the object conversion method mentioned in the previous section is introduced.
It is possible to deliver data, retrieved by a database access method, to a Java applet by embedding it in a HTML template as applet parameters. When the applet is downloaded into a WWW browser and is started to run, data (numerical values or strings) in the parameters are read into the applet. The applet uses the data as its pleases.
Graph forms such as bar charts, pie charts, and line charts can be prepared in advance. For example, displaying the number of employees in every department can be described as the following template.
...
<APPLET CODE="BarChart.class" WIDTH="400" HEIGHT="400">
<PARAM NAME="title" VALUE="the number of employees">
<PARAM NAME="orientation" VALUE="horizontal">
<% begindetail %>
<PARAM NAME="columns" VALUE="<% result.cardinality %>">
<% foreach dept in result %>
<% do %>
<PARAM NAME="label<% dept.position %>" VALUE="<% dept.name %>">
<PARAM NAME="column<% dept.position %>" VALUE="<% dept.employees %>">
<% done %>
<% enddetail %>
</APPLET>
...
In this example, result is the object variable defined as the result collection in a database access method. While generating a HTML document, the number of result elements is embedded in columns parameter, and label? and column? parameters for the number are generated in foreach block. After BarChart applet is downloaded on a WWW browser and begun to run, these parameters are read in the applet, and the bar chart is shown using these data.
With the method in the previous subsection, it is difficult to show complex formatted data that are not formal. Furthermore, interactive database environments such as client-server systems are desired. So, we also provide an interface for directly accessing databases from Java applets, and the interface is called PERCIO-Java API (PJAPI). PJAPI is implemented using native methods provided by Java Developer's Kit (JDK, developed by JavaSoft). PJAPI is based on the ODMG Java binding [ODMG].
For example, a simple route search is described as the following program.
import percio.*;
class RouteSearch {
static {
System.load("odjava.dll");
}
public static void main(String[] args) {
String fromStationName = args[0];
String targetPlantName = args[1];
try {
Database database = Database.open("corpdb", Database.openReadOnly);
Transaction transaction = new Transaction();
transaction.begin();
Set stationExtent = (Set)database.lookup("StationExtent");
stationExtent.fetch();
Set result = (Set)stationExtent.
select("where name == "+"'"+fromStationName+"'");
Iterator iteratorResult = result.createIterator();
Station fromStation = (Station)Iterator.current();
Plant targetPlant = (Plant)database.lookup(targetPlantName);
fromStation.fetch(); targetPlant.fetch();
Station[] route = routeSearch(fromStation, targetPlant);
displayRoute(route);
transaction.commit();
database.close();
} catch (Exception e) {
}
}
static Station[] routeSearch(Station fromStation, Plant targetPlant) {
...
}
static void displayRoute(Station[] stations) {
...
}
}
odjava.dll is a dynamic linked library in Windows NT / 95, and functions of PJAPI are included in it. It is dynamically linked to a Java VM when the program is begun. The statements for accessing databases must be enclosed with database open / transaction begin and transaction commit / database close. Moreover, the members of an object retrieved from databases can be referred after fetch() method is called on the object.
PERCIO is an OODBMS based on the C++ programming language, and its data structure depends on the C++ data structure. There are several differences between C++ and Java. Of these differences, the type difference has the main effect on database structure managed by PERCIO. Therefore, type conversion has to be provided in PJAPI. There is a typical mapping of Java primitive types to C types, and each Java class is represented by a C struct. As the C struct is considered to be a C++ class, correspondence between a Java object and a C++ instance (a database object) is affected. Every member in the object is converted each other in the native methods.
Java objects that are converted in the Java application server must be transferred to Java applets. Java applets and the Java application sever are connected with HORB [Hira] (Hirano ORB, developed by Electrotechnical Laboratory).
The mechanism for transferring Java objects is shown in Figure 4. A database object retrieved from a database is converted to a Java object in PJAPI, and it can be accessed as a Java object in the Java application server. The client object on a Java applet and the server object on a Java application server are connected using a proxy object and a skeleton object. These objects are automatically created at run time, and they support communication between a client object and a server object.
The content data in a WWW application consist of HTML documents, images, applets and so on. Although conventional WWW-DB integration systems deal with them as dispersed files, they are uniformly managed by OODBMS in the WWW-OODB integration system.
HTML documents are expressed as inclusion relationships to HTML tags that are constructing elements. These documents are mapped to composite objects and are stored in the OODBMS because inclusion relationships can be described using a composite object structure. The other content data are stored in the same databases without manufacturing, by providing the corresponding classes or using the exclusive class libraries. The references that point from HTML elements to these content data are also maintained in databases.
The data structure for HTML document tag elements is shown as follows. (But member functions defined in these classes are omitted.)
class Element : public d_Object {
public:
d_String element_name;
boolean start_tag, end_tag;
d_Ref<Element> superior_element;
d_Ref<d_List<d_Ref<Element> > > subordinate_elements;
d_Ref<d_Set<d_Ref<Attribute> > > attributes;
d_Ref<Text> subtext;
boolean update_value;
};
class Attribute : public d_Object {
d_String attribute_name;
d_String attribute_value;
};
d_Object class is the base class of all database classes, and it is specified in ODMG-93 [Catt96]. Instances of database classes that inherit d_Object class can be stored in databases. d_Ref<T> class is the object reference class that is used for pointing any object. In this data structure, Element class is the class for all HTML document tags, and Attribute class is the class for all attributes included in the tags.
An element name, existence of start / end tag, layered relationships for tags, and a set of attributes are defined in Element class. Every Element instance of an HTML document is created and has pointers to a set of Attribute class instances and a Text class instance that is a partial context document.
When a user submits a request for retrieving content data, an HTML document is dynamically generated combining the needed HTML document elements stored in a database. However, generating an HTML document with all the elements whenever a user submits a request requires considerable overhead. Thus, the text is put together to a certain extent. The methods for combining or dividing HTML subtext are defined in Element class. If an element in the subtext is updated, all elements that include the element are marked updated, and their context documents are made void.
There are several advantages to dividing content data into content elements. Access rights can be given to each element in advance. When an HTML document is generated, all elements that exist lower than the element are controlled for outputting. That is, constructing user views. Moreover, content data that are presented to users can be dynamically decided after a query is submitted to these elements in a database access method.
The WWW application development framework is considered to have the following advantages.
According to these advantages, the development of advanced WWW applications that have been difficult to develop using conventional tools becomes easier. The content data stored in OODBs can be viewed on WWW browsers with various display formats by converting composite objects or using Java applets. Moreover, different users or the same user at different times can have different views of the content data, because HTML documents are dynamically generated with subcontent data that have been given access rights. Therefore, it is also possible to reduce the content data for mobile terminals.
In the past, although there have been some WWW-DB integration systems that used OODBMSs, these systems did not make full use of the OODBMS features. O2Web [O2T] is connected to OODBMS O2, and its main feature is that a database class is the template for generating an HTML document. That is, an instance of the class corresponds to a WWW page. An object reference between instances is converted to a link between WWW pages, and the link is embedded in the page as an OQL statement. However, it is difficult to modify the conversion rules because programmers have to use the O2C programming language in order to describe the rules. Furthermore, the system structure of ObjectForms [ODIa] connected to OODBMS ObjectStore resembles that of PERIDOT, and any user defined function can be called for a database access method. However, data that can be used in an HTML template are only values returned from these functions. Access to composite objects cannot be described in the HTML template.
ObjectStore PSE for Java [ODIb] is also an object storage product for Java. Java objects can be stored in a database as just Java objects, and there is no difference in programming between persistent objects and temporary objects. This is compatible with various machines because it is entirely described in Java. Although it can be used on Java applets and Java applications, the communication protocol between a Java applet running on a WWW browser and a Java application running on a WWW server is not regulated. Therefore, Java applets cannot directly access OODBs on a WWW server.
In this paper, a WWW application development framework, into which object-oriented technologies are introduced for database access, has been proposed. The WWW-OODB integration system PERIDOT has been provided in order to achieve the framework. The major features of the system are: 1) converting composite objects to HTML text, and separation of HTML conversion methods and database access methods; 2) transferring objects in an OODB to WWW browsers using Java technology; and 3) storing HTML templates in an OODB, divided into elements. As far as using the system in WWW application development, flexible WWW applications can be implemented. In the future, we would like to provide extensible WWW server functions accessing OODBs due to introduce the component technology.