A Web based Distributed System Model
13
Joshua Okuthe
Department of Computer Science
University of Transkei
Private Bag X1
Unitra, Umtata 5117
South Africa
Judith Bishop
Department of Computer Science
University of Pretoria
Pretoria 0002
South Africa
13
Abstract
13
For the enterprise that is large and geographically dispersed, there can be no better tool for distributing content than the Web. We used the Web and the Internet as the transport and communication agent for distributing the objects created. The system is based on Internet Inter-ORB Protocol (IIOP) which provides pre-configured interoperability for object request brokers (ORBs) running over the TCP/IP protocol. IIOP allows the Internet to act as a backbone ORB accessible to other ORBs. Initially, we established the most efficient implementation of 3-tier client/server model among the three popular models: HTTP/CGI, RMI and CORBA/IIOP. In addiition to efficiency and flexibility, CORBA/IIOP results in greater system interoperability, which is a basic requirement of the Internet, and hence was our choice in designing and implementing the Web based distributed system model described in this paper.
1. INTRODUCTION
With the advent of workstations, personal computers and efficient networks, distributed systems are becoming a common business solution to the computing problem in the enterprise. The paradigm shift from the monolithic architecture of mainframe based systems to the distributed architecture of client/server based systems allows some components to be offloaded to computers on the desktops. These systems typically distribute the components of the application so that the database resides on the server, the user interface resides on the client, and the business logic could reside on either, or both, components.
1.1 Shortcomings of the client/server architecture
Despite solving problems with mainframe-based applications, client/server based systems are not flawless. For example, because database access functionality and business logic are often contained in the client component, any changes made to the business logic, database access or even the database itself, often requires the deployment of a new client component to all users of the application. The problems with traditional client/server systems, referred to as, “2-tier client/server”, were addressed by the 3-tier client/server architecture. The 3-tier architecture partitions the system into three logical tiers: the user interface, the business logic layer, and the database access layer [8]. The beauty of the 3-tier client/server architecture is that it reduces application fragility by providing more insulation and separation between layers. The user interface layer communicates only with the business logic layer, never directly with the database access layer. Thus, changes in the database access layer do not affect the user interface layer because they are insulated from each other.
1.2 Distributed object model
Distributed systems are really multi-tier client/server systems in which the number of distinct clients and servers is potentially large. The next logical step in the evolution of application architectures is the distributed object model. Rather than differentiate between business logic and data access, the model exposes all functionality of the application as objects. Each object can use any of the services provided by other objects in the system or even objects in other systems. Since the client components can also create objects that play server-like roles, the distributed object model blurs the distinction between clients and servers. The distributed object model provides the ultimate in flexibility by enforcing the definition of specific component interfaces. Such an interface specifies to other components what services are offered and how they are used [7]. As long as the interface of a component is unchanged, that component's implementation can change without affecting other components.
In a distributed object model, a client requiring access to a resource sends a message containing a request to the corresponding object which in turn dispatches the message to the appropriate process able to perform the requested operation. The target object then sends a reply message to the requesting process. As an example, consider a bank service that has a checking account object consisting of an account number, account type and balance. If the object can implement methods such as get_balance, withdraw_amount or deposit_amount, then the client may send a message to
the checking account object and request a balance. This request goes to a local proxy object, which sends the appropriate message to the object request broker (ORB). Using an account object supplied by the client, the ORB locates the object occurrence and returns the balance [2].
ORBs facilitate communication between local and remote objects, eliminating many tedious error-prone and non-portable aspects of creating and managing distributed applications. The ORB functions like a "bus" that allows objects to communicate when they are on a network. Furthermore, the ORB helps objects find one another, enabling programmers to develop and deploy complex applications rapidly and robustly rather than wrestling endlessly with low-level infrastructure concerns [3].
2. THREE-TIER CLIENT/SERVER ARCHITECTURES
2.1 CGI
The predominant three-tier client/server model for the Internet today is the Common Gateway Interface (CGI). However, CGI over HTTP, which does not conform to the distributed object model, is slow, cumbersome, and stateless. CGI is no match for object-oriented Java clients. With CGI, we input information via a web page and invoke Java applets to download portions of a distributed application to a client workstation for execution.
2.2 RMI
The two other three-tier client/server architectures are Remote Method Invocation (RMI) and Common Object Request Broker Architecture/IIOP (CORBA/IIOP). Unlike HTTP/CGI, the two architectures are based on the distributed object model. RMI directly integrates a distributed object model into the Java language. It not only makes the ORB almost transparent to the client, but also extends Java’s security net to include the dynamic downloading of stubs. Furthermore, RMI provides ORB-like facilities from within the Java object model [1]. However, RMI objects can only talk to other RMI objects and do not support self-describing objects, dynamic invocations and interface repositories. Though proprietary and lightweight, RMI is not a suitable backbone for the Internet or Intranet as it lacks the universality of CORBA/ IIOP.
2.3 CORBA/IIOP
CORBA over the Internet provides one of the best solutions for new types of dynamic client/server interactions. A CORBA/Java ORB is a CORBA IIOP that is written entirely in Java for portability [9]. The ORB must be able to generate Java language bindings from CORBA IDL. More importantly, any code generated by the IDL compiler must be in pure Java. One should be able to download that code and run it on any machine hosting a Java run-time environment.
The major advantage of CORBA/IIOP stems from the fact that it permits client and server objects written in different languages, running on different operating systems, and on disparate networks, to collaborate [5]. Interaction is channeled through ORBs, which encapsulate the message-passing logic, eliminating the need for either client or server objects to be aware of each other's physical location. Clearly, location transparency is a bonus as far as Internet based applications are concerned.
Among the products that may be used to create CORBA augmented Java applications are; Sun's Joe, Iona's OrbixWeb, Visigenic's VisiBroker for Java and more recently Java Development Kit 1.2 (JDK 1.2). We used VisiBroker for Java to develop an automatic CORBA IDL-to-Java code generator that converts object interfaces into both client and server side Java code for the 3-tier XYZ Airways flight reservation system. The XYZ Airways Web based system allows clients to make reservations and cancel bookings remotely [6]. Further, clients may list flight details as well as provide the preferred modes of payment once the system has displayed the anticipated cost of the flight.
3. PERFORMANCE COMPARISON
We implemented a simple count client/server program using: HTTP/CGI, RMI and CORBA/IIOP. The server exports a single method increment whose purpose is to increment by one the value of sum. After each invocation, a new value of sum is returned to the client. The count client/server
system measures the time taken for a client to invoke a request on a server and then get back a response. In other words, it determines the average round trip from client to server and back.
3.1 The System Configuration
Figure 1 depicts the system model under which the three client/server models were implemented. The client Danet is a 100 MHz Pentium running Windows NT 4.0 in the Nlab laboratory, while the server Cos-lan is a busy Novell NetWare 0.1 File Server with a Pentium 150 MHz Processor and three 3COM 509 Network Interface Cards (NICs). The client and server are connected by a combination of 10 Mb/s Ethernet (Consisting of UTP and Coaxial cable) and Asynchronous Transfer Mode (ATM) infrastructure. Jupiter is a Unix server, shown here as part of a larger network.
Powerhub Powerhub module Counter
137.215.18 { interface Count
{ attribute long Sum;
Runner 5 Runner 4 long increment ( );
NLab };
};
Ethernet (UTP/Coaxial) 10 Mb/s
LISTING 1: Count.idl
Dos-Lan Jupiter
FIGURE 1: The System Configuration
In addition to the Windows NT 4.0 Workstation and Netscape Navigator 3.0 existing on the client, the following software were installed;
· JDK 1.1.5 - including Symantec Visual Cafe JIT Compiler, RMI and JDBC
· VisiBroker for Java [4]
3.2 Mapping CORBA IDL to Java
The first step in the CORBA development process is to create language independent IDL definitions of the server’s interface (see Listing 1).
To map the IDL file into Java code, we used VisiBroker’s idl2java compiler. The IDL-to-Java compiler generated four Java classes and one Java interface.
3.3 Results
Table 1 depicts the relative performance of the three architectures investigated. An immediate comparison can be made from figure 2. HTTP/CGI is the slowest of the three models. This is because of the HTTP/CHI client request has to traverse three processes namely:
· Locating the program identified by a URL, followed by execution of resource named.
· Passing the method request and its parameters to the back-end program using CGI.
· Forwarding results to the client.
RMI clients interact with remote objects via published interfaces. They never directly come into contact with classes that implement the interfaces. The comparative slowness of RMI may be attributed to the absence of both dynamic discovery and dynamic invocation [3].
COUNT TIME TAKEN (SEC)
HTTP/CGI RMI CORBA/IIOP
100 59 1.08 0.35
200 121 2.12 0.71
300 180 3.20 1.06
400 238 4.28 1.30
500 302 5.36 1.72
600 364 6.44 2.11
700 420 7.48 2.44
800 486 8.56 2.91
900 545 9.66 3.15
1000 600 10.8 3.71
TABLE 1: Comparative Performance
FIGURE 2: Relative Performance
WEB BASED DISTRIBUTED SYSTEM MODEL
The XYZ reservation system is a 3 tier Web based client/server system in which clients invoke operations on the CORBA middle tier objects via an IIOP ORB. Server objects provide the business logic and store their persistent data in a Java Database Connection (JDBC) – compliant SQL database. A Java applet places the controls of the client in the hands of a user manipulating visual forms. The forms become the source of CORBA method invocations allowing server objects to wait on requests from clients to trigger the execution of their methods. The interfaces to the server objects are defined in the CORBA IDL thus enabling persistent information in the XYZ Airways System to be stored in the SQL database. Figure 3, illustrates the operation of the XYZ Airways System viewed from the user, applet, CORBA server and the JDBC database.
The XYZ CORBA IDL
The XYZ server objects interact with client applets on the front-end and SQL databases on the back-end. The server’s interface, which provides a binding contract between it and its clients is defined in a CORBA IDL. Figure 4 shows how the XYZ client and server classes interact. Initially, the server creates a dispenser object, which in turn pre-starts a pool of server objects. The server objects connect to the database invoking the methods specified by the client.
User XYZ Applet CORBA Server JDBC
1
Start Applet
getFlights
Select from Flights
2
Pick a flight
Click on Reservation
getFlightPrices
3 Select from Prices
Fill Form
4
Submit Reservation
5
Confirm Reservation
addReservation
Select from Reservations
Insert
Commit
6
Display Reservation list
getFlightReservations
7 Select from Reservations
View Reservation
getReservation
8 Select from Reservations
Cancel Reservation
cancelReservation
Delete from Reservations
Client CORBA Invocations Server
FIGURE 3: Operation of the XYZ Airways System
An option exists for either running multiple client programs from the same machine or giving each client its own machine. To run a client, we execute the corresponding HTML file and obtain the XYZ selection form shown in figure 5. A sample of the reservation detail form (figure 6) shows that a new card layout object with a horizontal and gap specified is created in response to the client’s request. Further selections from within the form, is facilitated by Java applet buttons stationed at the bottom of the form.
XYZClient
XYZServer
XYZDispenser
XYZ Object
1
2 repeat n times
XYZDB
3
4 connect
5 reserveXYZObject
6 getFlights
getFlights JDBC
JDBC
7 getFlightPrices
getFlightPrices JDBC
XYZ
8 addReservation Database
addReservation
9 releaseXYZObject DBMS
CLIENT SERVER SERVER
FIGURE 4: XYZ Client/Server Scenario
RESULTS AND FUTURE DIRECTION
Results
Java and CORBA are two foundation technologies for Web based distributed computing applications. Our results show that currently, the two provide the best platform for creating Web-based client/server applications. The key unit of distribution in CORBA is its object reference. The object reference points to an object interface as opposed to RPC that returns a reference to a single function. The beauty of employing the interface is that a set of related methods operating on an individual object may be invoked. Furthermore, one can aggregate CORBA interface via multiple inheritance.