System Architectures for Integrating Web-Based User Interfaces into (Legacy) Database Applications

Transcription

1 System Architectures for Integrating Web-Based User Interfaces into (Legacy) Database Applications Jun Han, Peninsula School of Computing and Information Technology, Monash University, McMahons Road, Frankston, Vic. 3199, Australia. Abstract The Web has been increasingly used for the user interfaces of software applications. There are a range of technologies that can be used for integrating Web-based user interfaces into software applications. To make informed decisions, it is important for the software engineers to be aware of the range of alternatives and their implications. In order to gain some insights into these alternatives, in this paper we present and analyse a number of scenarios in which the Web is used to provide (new) user interfaces for legacy database applications. In particular, we focus on the system architectures required to integrate the new Web-based user interfaces with existing components of the database applications through the use of the Web/Java technology and the CORBA distributed object technology. For each integration alternative, we identify the assumed technologies, outline the integration architecture, and highlight its characteristics. Topics: System integration and architectures, human-computer interaction. Keywords: Web-based user interface, (legacy) database application, system architecture, Java, CORBA. 1 Introduction The user interface is an essential component of any software application. Given the wide spread use of the Web, it is natural and advantageous to provide Web-based user interfaces for software applications. Doing so will give the users a look-and-feel similar to the Web, while still providing the specific functionalities that the applications are developed to provide. Many software applications are data-intensive and utilize a database, which we call database applications and are the focus of this paper. The user interface of such a database application usually involves presentation and manipulation of the information in the database. There may also be complicated transformations required between the presented format and the stored format of the information. For example, the software artifacts (including programs) maintained by and manipulated through a software development tool or environment take quite different forms in terms of their external presentation and internal representation. Transformation schemes (called parsing/unparsing schemes for software artifacts) are required to bridge the two forms. In general, the transformations are part of the user interface component of the application. Therefore, the transformation or conversion schemes should be considered in the process of providing Web-based user interfaces for database applications. There are a range of technologies that can be used to integrate Web-based user interfaces into software applications. The availability and adoption of different technologies results in different integration architectures with different system characteristics. For the relevant stakeholders to make informed decisions that are particularly suited to their application context, it is important that the available integration architectures, their characteristics and their relationships to the various technologies are identified. In this paper, we investigate the ways to integrate Web-based user interfaces into database applications. Such integration scenarios are based on the Web/Java technology and the CORBA distributed object technology. While we focus on the integration of new Web-based user interfaces with existing components of legacy database applications, the identified system integration architectures are also applicable to new database applications. In the following sections, we present four scenarios of integrating Web-based user interfaces into legacy database applications. For each scenario, we identify the assumed technologies, outline the integration

2 architecture and analyse its characteristics. 2 The gateway/database scenario As mentioned above, a database application is developed centring around a database system, for storing and managing the large amount of information to be used and manipulated by the users. In general, a database application has the following components: the user interface, the application logic and the database. To provide a Web-based user interface for such an application is to realize the user interface component using the Web. In particular, the recent object database systems such as O2 facilitate direct connectivity to the Web, through the gateway technology on the Web server side (i.e., the common gateway interface -- CGI) [Gundavaram96]. That is, objects (or information/data) in the database can be viewed and edited through the Web browser. In essence, the gateway carries out the conversion task between the Web-page format required by the browser and the object format in the database. In the case of O2, the gateway works according to a default conversion scheme, and the scheme can be customized globally or on an object/class basis [O2Web96]. In this integration scenario (see Figure 1), the user uses the Web browser to interact with (view and edit) the database information according to the format of the generated Web pages. In effect, the Web browser forms the user interface of the integrated database application, supported by the gateway conversion capability. Since the gateway and the default conversion scheme are provided with the database, it simplifies the user interface development task. While the provision of a default conversion scheme is convenient for simple (data) conversion, the default conversion framework may prove to be too restrictive for complicated conversion requirements. As mentioned earlier, the data/objects in the database may not be suitable for direct presentation under the default conversion scheme. Often, data need to be transformed, merged, selected and re-structured for presentation. For example, the presentation of software artifacts (e.g., programs) often requires the merge of many artifact objects (at different nesting levels) into one Web-page in a specific format. Furthermore, some parsing and unparsing scheme is required during this conversion process. In general, therefore, object/class level customization is required. In certain cases, such detailed customization may prove to be too restrictive, and consequently new conversion schemes need to be implemented in the gateway. Figure 1. Integration Architecture of the Gateway/Database Scenario

3 In this integration architecture, the gateway acts as the user interface management system for the entire application. The communication between the Web browser (the user interface) and the gateway is via the Web server and relies on the HTTP protocol. In addition to the direct interactions with the database, the gateway also communicates with other components of the application, to ask them to carry out computation/manipulation tasks as required by the system's functional design. In this process, these other components may interact with the database as well. For example, a user request may involve (1) the generation of a new set of data/objects from some existing data/objects in the database by the existing application components, and (2) this new set of data/objects being fetched from the database by the gateway and presented to the user in a specific format. It should be noted that one does not need to rely on an existing gateway. Rather, he/she may develop his/her own gateway with a specialized conversion scheme. But, much work is required. Besides, the database does not have to be an object database, as long as the gateway technology is available and possible for the integration. In fact, most legacy applications uses non-object databases. The gateway technology works well with these traditional (mostly relational) databases. It should be noted, however, that an advantage of using object databases is that the database and the application logic have a closer integration and hence the system integration is made much easier. 3 The applet/database scenario With the integration of the Java technology and the Web technology [Flanagan97] and that of the Java technology and the (object) database technology comes another scenario in which we can use the Web as the user interface for database applications. This scenario assumes that there exists a Java binding with the ODBMS (such as O2 [O2Java96]) and the application components are developed surrounding the ODBMS in such a way that newly written Java applets can interact with the components and access the information in the database. The application components may or may not be written in Java. In the latter case, the interaction with Java applets can be achieved through the ODBMS's capability of being able to bind to different languages in an inter-changeable manner (as in O2). In this setting, we can develop a Web-based user interface for the application based on the Java/applet technology, which interacts with the other application components and access the data/objects in the database. The execution of the applets in the Web browser provides the user interface for the application. In this scenario (see Figure 2), the Web-based user interface has to be properly structured and implemented to provide the required conversion functionality between the data/objects stored in the database and the useroriented Web-based presentation. One way to realize this is to codify the conversion scheme/functionality into the applets. However, this will make the applets "heavy-weight" and results in bad performance among other penalties. In reality, it is more appropriate to develop or customize the application's user interface management system (UIMS) as a Java server-side, to perform the conversion task and interact with other application components. The user interface applets will become light-weight and communicate with the UIMS. In comparison, the applets and the UIMS in this scenario replace the gateway and related customization in the above gateway/database scenario. In this scenario, there is no pre-existing default conversion scheme, the entire conversion functionality has to be implemented in the UIMS component. As indicated above, this may require more effort, but may prove to be necessary because of the complexity of the conversion. Compared to the development of a gateway, this applet alternative may prove to be more effective in terms of the flexibility it offers. In this integration architecture, the Java applets running in the Web browser (the user interface) interact with the Java server-side (the UIMS) through the TCP/IP protocol supported by the relevant Java APIs. The UIMS interacts directly with the database through the Java-database binding. The direct communications between the UIMS and other application components are limited by the compatibility between the languages

4 used. The legacy application components interact with the database and with each other as before. When the database is an object database, the integration between the application components (including the UIMS) is much easier and flexible in the sense that much of the integration can be done through the behaviourembedding objects and their interactions in the database. Figure 2. Integration Architecture of the Applet/Database Scenario Again, the database in this scenario does not have to be an object database as long as the database has a Java binding, which is usually available through, for example, the Java (relational) Database Connection (JDBC) APIs. As mentioned above, however, the interaction between the user interface component (i.e., the UIMS) and other application components are much convenient to implement when using an object database because of its closer integration between data and processing logic. 4 The applet/corba scenario In this scenario, the components of a database application are integrated through an object request broker (ORB) -- a CORBA implementation [OMG], including the database as a component. As in most cases, this cluster of components are not directly Web/Java-enabled. To provide a Web-based user interface for the application, we may use the Java/applet technology as in the applet/database scenario above. However, the Java server-side UIMS component is integrated to the ORB, interacts with the other application components via the ORB, and serves the user interface applets. This scenario does not require that the application components have Web/Java-enabled capability, and represents a more flexible integration scheme (see Figure 3). In fact, the environment components can be implemented in any language or database, as long as they are (or can be) integrated to the ORB. Same as in the applet/database scenario, the Java server-side UIMS has to implement the conversion between the data/objects stored in the database and the user oriented Web-based presentation. In this integration architecture, the interactions between the user interface Java applets and the UIMS Java server-side remain the same as in the applet/database scenario. As mentioned above, the availability of CORBA technology provides much more flexibility for the application's implementation. The application components (including the UIMS, the database, and other processing units) can be developed independently and integrated through the ORB. The ORB provides the means for all the components to communicate and

5 interact. Usually the legacy components (including the database) are integrated to the ORB using adapters and wrappers. As such, whether or not the database is object oriented does not have much architectural impact. 5 The orblet scenario Figure 3. Integration Architecture of the Applet/CORBA Scenario An orblet is a Java applet that can interact with (remote) CORBA objects. This technology relies on the direct integration of Java/Web technology and the CORBA technology. Example commercial implementations of such integration are Iona's OrbixWeb [Iona96], SunSoft's Joe [Sun98] and Netscape's Communicator. In this technology, one approach is to use dynamic download of the ORB client-side run-time library into the Web browser to provide the ORB environment for executing the orblet. Joe is an example of this approach. Another approach is to incorporate an ORB implementation in the Web browser. Netscape 4.0 is an example of this latter approach and it incorporates Visigenic's ORB. In both approaches, the orblet executes in the Web browser as a client of the ORB in the browser, and interacts with remote objects integrated to other ORBs on the Internet through the Internet Inter-ORB Protocol (IIOP) [OMG]. The orblet technology provides us with another Web-based user interface integration scenario (see Figure 4). In this scenario, the application components are integrated through CORBA implementations, as in the applet/corba scenario. However, the UIMS component does not need to be a Java server-side. Like any other components, the UIMS can be written in any language. The user interface orblets directly interact with the application components (mainly the UIMS) through IIOP connections (i.e., between the browser ORBs and the components ORBs). Note that the browser ORB may be a complete ORB or just the ORB client-side (ORB-c). This scenario provides even greater capability and flexibility than the applet/corba scenario in the sense that it does not require the UIMS to a Java server-side. Besides, the communication between the orblets and the UIMS is via the CORBA IIOP protocol, rather than the TCP/IP based Java APIs. Similar to the applet/corba scenario, whether or not the database is object oriented does not have much architectural impact on this orblet-based scenario.

6 Figure 4. Integration Architecture of the Orblet Scenario 6 Conclusions In this paper, we have presented four scenarios for integrating Web-based user interfaces into (legacy) database applications. While providing a commonly aware user interface, these integration scenarios also add the distribution capability to the applications. They assume the availability of different technologies and have their own distinctive characteristics in terms of flexibility and integration effort. For each of scenarios, we have identified the assumed technologies, outlined the integration architecture and analysed its characteristics. For a specific application, the decision of choosing a particular integration architecture should be made in terms of the available technologies and the nature of the application and project (such as the language/platform constraints, the requirements for integration flexibility and the available resources), as to how well they match the requirements of the integration architecture as presented in this paper. We are currently carrying out some further experiments on the integration alternatives to gain additional insights into them, such as their performance and evolvability. References [Flanagan97] D. Flanagan. Java in a Nutshell: A Desktop Quick Reference, second edition. O'Reilly & Associates, Sebastopol, USA, [Gundavaram96] S. Gundavaram. CGI Programming on the World Wide Web. O'Reilly & Associates, Cambridge, USA, [Iona96] Iona Technologies. OrbixWeb White Paper. <URL: [O2Java96] O2 Technology. Java O2 Binding: A Sneak Preview. Versailles, France, [O2Web96] O2 Technology. O2Web User Manual. Versailles, France, January [OMG] Object Management Group. OMG Technical Library. <URL: [Sun98] Sun Microsystems. Joe(TM): Developing Client/Server Applications for the Web. <URL: March 1998.