A Java-based, 3-tier framework for stateful database applications

Document Sample
A Java-based, 3-tier framework for stateful database applications Powered By Docstoc
					A Java-based, 3-tier Framework for Stateful Database Applications on the WWW
Ioannis Aggelis, Stathes Hadjiefthymiades and Drakoulis Martakos
Department of Informatics and Telecommunications, University of Athens TYPA Building, Panepistimioupolis, 15784 Athens, Greece
jaggel@ath.forthnet.gr, shadj@di.uoa.gr, martakos@di.uoa.gr

Abstract. The WWW is currently the dominant software technology for the deployment of telematic applications as well as corporate intranet applications. It is based on a stateless model of operation that causes substantial problems in the adaptation of legacy, stateful information systems (and related applications). A number of issues pertaining to the porting of systems like DBMSs to the WWW are investigated. The practices that have been followed are reviewed. We propose a CORBA based architecture that operated behind a Servlet-enabled WWW server. Database related operations are performed statefully while the relevant objects are persistently handled across hits belonging to the same session. We show how the suggested scheme deals with stateful applications through a series of examples.

1. INTRODUCTION Currently, the WWW is viewed as a very promising technology and used vastly for the deployment of applications in the Internet and corporate intranets. This client/server information system owns its great success in the standardization of the communication between clients (browsers) and information servers. The work presented in this paper was mainly motivated by the stateless character of the HTTP. HTTP is a fairly simple set of rules optimized for hypermedia systems distributed across wide area networks. The WWW server fulfills each individual request for information independently from (without remembering) the previous ones. The problem is twofold. Apart from the performance handicap that the stateless operation of WWW presents, the WWW server has no way of associating “logically” related requests and maintaining information for them as part of a “user session”. The performance handicap is attributed to the fact that httpds require a completely new TCP connection for each request they serve. The disadvantages of the HTTP TCP combination (3-way handshake, slow start) have been quantified [Spe94] and several new proposals were made to overcome the performance handicap [Fie97], [Pad95]. Regarding the second fold of the HTTP problem, a method for porting stateful applications to the WWW has been proposed in [Per94]. It is based on a Translation Server; a software component that accesses the original (stateful) user interface of a legacy system triggered by the WWW browser. The Translation server interprets application output intended for a conventional terminal (e.g., IBM 3270, VT100) to HTML code. On the reverse direction, the Translation Server relays the HTTP request issued by the browser to the original interface of the legacy system. According to the 1

WWW middleware taxonomy proposed in [Per95], Translation Servers are classified as “Interface Gateways”. The Translation Server doesn‟t handle insertions or updates of information well. Moreover, its dependence on specialized files, called schemata, renders the propagation of application changes to the WWW quite difficult. RDBMS gateways have attracted the interest of the WWW community during the past years. Such connectivity has been a research issue since the early stages of the WWW [Eic94], [Eic95], [Per95] while many commercial tools appeared [All97], [Mic96]. Issues associated with the deployment of database gateways encompass: portability among systems, generality, compliance to standards, performance as well as the stateful operation discussed in this paper. In [Had96] a framework for the deployment of databases on the WWW was proposed. The main characteristics of this framework were generality and compliance to existing standards. The performance problem of database gateways was addressed in [Had97]. The advantages of a new, client/server architecture for the deployment of database WWW applications were assessed in a series of experiments through the use of an HTTP pinger. In this paper we propose a new, Java-based architecture for the development of stateful database applications. Our architecture tries to overcome several of the problems reported in previous paragraphs. We introduce a specialized software component termed the Dispenser. The Dispenser allocates threads of the database application to active users and keeps track of their use. In our architecture, there is an one-to-one mapping between application threads and user-sessions. Stimuli from the browsers reach the database application through Java Servlets. Servlets communicate with the database application through CORBA. The rest of the paper is structured as follows. Section 2 discusses the problem of statefully running a WWW-DBMS gateway. The state management mechanisms, which are currently available for the WWW, are briefly outlined. Such mechanisms are not adequate for DBMS gateways. A software architecture with specialized components (like the Dispenser) is needed in order to render the operation of the gateway as efficient as conventional, stateful database applications are. In Section 3 we present the newly designed architecture. In Section 4 we discuss details of the architecture‟s implementation. In Section 5, we discuss the suitability of our architecture for several transition scenarios. In Section 6, we conclude this paper by summarizing the presented work. 2. STATEFUL DBMS GATEWAYS State preservation in the WWW can be accomplished in several ways and be based on various software components [Bro96], [Smi96]. Some approaches suggest that only the server tracks users‟ actions while others require the active involvement of browsers. State preservation on the server is quite difficult due to the stateless character of HTTP. In the 1.0 version of HTTP [Ber96] several solutions can be considered:  One could rely on header fields like “From” and “Referer” in order to associate distinct hits into a user session.  State preservation could also benefit from the definition of security realms within the server. In this case, user identification information is conveyed in the HTTP re2

quest message. Such information can be retrieved by CGI scripts through the REMOTE_USER parameter [Coa98]. The Cookie mechanism [Kri97] is an extension to the HTTP protocol proposed by Netscape. The Netscape Navigator browser and many of the WWW servers (Apache, etc.) originally supported Cookies. When a browser requests a resource from a server for the first time, the server responds with a Cookie (special field within the HTTP header), which the browser stores and sends back as part of the next query. Thus, gateways are able to link up individual requests into a session. Hidden variables within HTML FORMs [Rag97] could also be employed for preserving state information on the browser. Such information is re-posted to the server upon FORM‟s submission. On the server‟s side, the information carried in the HTTP request needs to be parsed and decoded in order to retrieve the state-relevant values. The same scenario could be realized by directly appending name-value pairs to the requested URL. Hidden FRAMEs [Fla97] are also an alternative for keeping state information within a FRAME-capable browser. Imagine an invisible FRAME which stores state information in a set of variables. Such variables are accessed (set or read) by the embedded code of adjacent, visible FRAMEs using the capabilities offered by scripting languages like JavaScript or VBScript. In a typical database application, an array within the hidden FRAME could host the primary keys of an entire set of result tuples. The visible FRAME could easily implement “next-previous” functionality by referencing the hidden array. Although the problem of state preservation can be resolved using standardized mechanisms like Cookies, it is not guaranteed that the operation of the gateway will be as efficient as it should be. Imagine, for example, the browsing of a list of query results. The server, upon submission of the relative query, stores a cookie in the browser in order to identify future requests from the same user. The content of the cookie is the actual query issued by the user. Each subsequent HTTP request conveys the cookie value plus the current position (e.g., 22) in the browsed list. Each request results in the presentation of a new list entry (previous-next browsing). A short-lived gateway (e.g., a typical CGI script spawned upon the reception of the request at the server) needs to re-execute the query, process the list of results, locate the current user position and display the previous-next entries as needed. As shown in [Had97] reestablishing connections towards a database system involves a substantial time delay and overhead which degrades the speed at which the service is offered. Solutions where the initial query results are temporarily stored in the file system of the server (or some database system) for further processing by subsequent requests are not too elegant, hide considerable risks and still do not resolve the efficiency problem. The short-lived gateway was the most crucial factor in the problem discussed in the previous paragraph. Short-lived processes need to re-execute part of the program logic in order to reach the point at which their predecessor (i.e., the script or gateway instance triggered by the previous request of the same client) generated output and completed execution. In [Had97] we addressed the performance problem of database gateways through the introduction of a long-lived process that interacts with the short3

lived processes (CGI scripts or other gateway instances that receive input from the WWW server). The role of the long-lived process in this scenario can be assigned to conventional database applications that are slightly extended to comply with the specifications of the WWW. The resulting architecture is shown in the Message Sequence Chart (MSC) of Figure 1.
Env
REQUEST [Parameters1] [Parameters1]

httpd

database appl/tion GW

Request [Parameters1] Response

RESPONSE RESPONSE [Results1] REQUEST [Parameters2] [Parameters2] [Results1]

[Results1]

GW

Request [Parameters2]

Response RESPONSE RESPONSE [Results2] data flow instantiation (with parameter passing) GW: Gateway instance [Results2] [Results2]

Figure 1: Interaction of short-lived instance and stateful database processes The MSC notation (CCITT Recommendation Z.120) provides a very comprehensible way of denoting the sequence of message exchanges and process instantiations [Bra93]. MSCs are vastly used in the specification of telecommunication protocols. Figure 1 shows the progress for one instance of the database application. In a publicly available WWW server multiple instances are needed in order to accommodate more than one simultaneous users (Env in Figure 1). Such a requirement can be easily met by the introduction of a multi-threaded (MT) application. To control the interaction of multiple gateway instances with multiple application threads we introduce a specialized software component named Dispenser. The responsibilities of the Dispenser component will be further analyzed in Section 3. 3. PROPOSED ARCHITECTURE The suggested architecture adopts a 3-tier scheme, as shown in Figure 2. The middle tier encompasses the WWW server, a Servlet execution engine, the Object Request Broker (ORB) and the implemented CORBA objects for the communication with the database. This tier assumes a client/server organization where clients are the Java Servlets (Javasoft Servlet API 2.0). The role of the server is assigned to the combination of the Dispenser and the threads of the Java database application.

4

Java Servlets were adopted as they are capable of keeping session tracking between different HTTP requests of the same user (i.e., preserve state with the help of the Cookies mechanism [Hun98]). This demands a WWW server that can handle Servlet requests. Any server that has a Servlet engine practically fits into our architecture but our choice was the Apache Web server (release 1.3.x) along with its JServ module [URL1] intended for supporting Servlet execution. In the server part of the middle tier, CORBA IDL was used to specify component interfaces. Subsequently, the IDL  Java mapping of the chosen ORB was used to produce skeleton and stub classes [Omg95a] for the above mentioned interfaces. The ORB used in our architecture was ORBacus 3.2 [URL2] for Java from Object Oriented Concepts. The interfaces described in the middleware are two: the Dispenser and the database thread (dbthread). The Dispenser has a pool of database threads, each one maintaining a connection to the underlying database system. Database threads become available to the clients with the aid of the Dispenser. Each database thread of the pool has, in turn, a connection wrapper object which performs the actual communication with the database system. The wrapper receives the requests from the database threads and returns the relevant results to them. Both the Dispenser and the database threads have a set of methods that make available, through the ORB, to clients. The Dispenser has methods for reserving and releasing a database thread, while the database thread incorporates methods for accessing the information held within the database. The DBMS used in our implementation was ORACLE 8 (release 8.0.5) running on a Linux platform. The connection wrapper used Oracle JDBC drivers in order to communicate with the database (through the JDBC API ver. 1.0) and access the required information [Sun97]. The architecture was tested on two platforms to demonstrate its portability:  an Intel Pentium platform running SuSE Linux 6.2 and,  a HP-9000 server running HP-UX 11.00. Apache 1.3.x as WWW server and ported editions of Sun‟s JDK 1.1.7 as Java VM, were used on both platforms.

5

WWW browser
<HTML> <BODY> <FORM> …….. </FORM> </BODY> </HTML>

Coordinator (dispenser)
ORB JVM

wrapper

IIOP

HTTP

1st tier
IIOP

Database object (dbthread)

Client servlet

Database object (dbthread)

wrapper

ORB ORB

JDBC

JDBC

Apache 1.3.x

wrapper

Servlet Engine (Jserv)
ORB

ORB

Oracle 8
JDBC Database object (dbthread)

3rd tier

Database Objects’ Pool

2nd tier

Figure 2: Layout of the proposed architecture On the client side of the architecture‟s middle tier, the Servlet invokes a part of the ORB in order to locate and communicate with the Dispenser and the database threads. The server side contains an instance of the Dispenser and multiple instances of database threads. The Dispenser, in its initialization routines, apart from creating the pool of database threads, exports a name in the ORB‟s Name Service [Omg95b] and creates a thread named Invalidator. The exported name is useful when the Servlet wants to locate the Dispenser for the first time (through the ORB‟s Name Service). The invalidator thread prevents sessions from holding database objects locked, while idle, for a long time. Whenever a request arrives at the server for the database application, the relevant Servlet uses the Session API (part of the Servlet API [Hnu98]) either to identify an existing session or generate a new one. In the former case, the context of the Session (preserved on the Servlet side), contains a reference to the database thread that actually handles the current session. Depending on the request, the Servlet invokes the appropriate method within the database thread. To verify that the thread is still handling this session, the Servlet forwards its Session ID to the thread. In the latter case (i.e., a new Session context is created), the Servlet contacts the Dispenser in order to reserve a database thread to handle the current session, and then invokes the appropriate method within the recently assigned thread. The database thread internally holds a vector with all the open database cursors [Dat95] (ResultSets in the JDBC API) along with a pointer to the last one opened (all database operations are performed through JDBC). Whenever a non-empty SQL statement is sent to the thread, if it is a SELECT statement, the newly opened cursor is added at the end of the vector and the pointer is changed to this one (see Figure 3). On the other hand, when an empty statement arrives, the cursor indicated by the pointer is used in order to fetch the next results (row-by-row retrieval). Finally, when a cursor

6

close request arrives, the thread closes the last cursor of the vector (i.e., the one indicated by the pointer), changes the pointer to the previous cursor and returns the results the previous cursor lastly sent. It should be stressed that the persistence of cursors as described above, accomplishes the pursued state preservation in the Web environment.
Pointer to last cursor

Vector of cursors

n-1

n

Figure 3: Vector of opened cursors The database operation results are integrated, by the database thread, into an twodimensional array of strings and sent back to the appropriate Servlet through the ORB. This array practically holds a number of records retrieved by the RDBMS. The Invalidator checks the pool of the database threads in order to locate the ones that were accessed before a given time threshold. In [Cat95] a session time-out period of 25.5 minutes was first reported for the WWW. This time period gives us a clear indication of the time within which the server system should anticipate a new request from the same browser. After that period, the Invalidator considers the client inactive (i.e., assumes that its session is over) and returns the thread to the pool of available threads. 4. IMPLEMENTATION DETAILS The methods of the Dispenser and the database thread, that are made available through a well-defined API (described using CORBA IDL) are provided below:
interface Dispenser { struct DBThreadDesc { DBThread ref; boolean inUse; double startTime; }; DBThread reserveDBThreadObject(out short idx, in string sessionId) raises (DBServerException); void releaseDBThreadObject(in short idx) raises (DBServerException); }; interface DBThread {

7

typedef sequence<string> StringRow; typedef sequence<StringRow> StringResult; StringResult dbExec(in string sqlStmt, in short maxRows, in string sessionId) raises (DBServerException); StringResult rsClose(in string sessionId) raises (DBServerException); void initRs() raises (DBServerException); void setCurrentSession(in string sessionId) raises (DBServerException); double getLastAccessedTime() raises (DBServerException); };

The interface of the Dispenser object simply exports the two methods, one for reserving a database thread, named reserveDBThreadObject, and one for releasing it, named releaseDBThreadObject. The former method, returns a database thread instance, if available in the thread pool, otherwise it returns a null reference. In addition, it marks the thread with the Servlet‟s session ID for further use by the Invalidator and also returns the index of this thread in the pool. The second method simply takes the index of the database thread mentioned above and releases the thread by re-initializing its attributes. The information, that the pool maintains for each thread, is described in the DBThreadDesc structure which actually holds a reference to the thread, a Boolean value, denoting whether the relevant thread is in use or not, and the time the thread was assigned to a Servlet. The interface, of course, hides some attributes, needed for internal use, and the exact description of the Dispenser object can be found in its Java class definition of (DispenserImpl). The database thread interface describes multiple methods but only two of them are actually used by the Servlets, the others are used by the Dispenser in order to set or retrieve some of the internal attributes of the thread. This last category contains the following methods:  setCurrentSession, used for setting the attribute that holds the Servlet‟s session ID inside the thread,  getLastAccessedTime, used for retrieving the attribute that holds the last time this thread was accessed (this method is only used by the invalidator)  initRs, used for clearing the internal vector of cursors and initializing some attributes in order to reset the thread and make it available for use by another Servlet. This method is either invoked by the Dispenser in its releaseDBThreadObject, or by the Invalidator, but, in both cases, it is used for resetting the relevant thread. The methods that are used by Servlets are the dbExec and the rsClose. The former works as described in previous paragraphs. It receives, as input parameters, the SQL statement to be executed, a number defining how many rows should be returned from the opened cursor and the Servlet‟s session ID. The Servlet‟s session ID is used in order to check whether this thread actually corresponds to the relevant Servlet. If the session ID is not the one stored in the thread instance an error message is returned to 8

the relevant Servlet. The dbExec, if invoked with a valid, non-empty SQL SELECT statement, opens a new cursor, appends it to the cursor vector (of the thread) and changes the pointer to the last cursor. Every subsequent invocation of the dbExec method with an empty statement simply forwards the lastly opened cursor to the next set of results. In order to backtrack, from a current cursor, to the previous one, the rsClose must be invoked. Calling this method, simply closes the current cursor, indicated by the pointer, removes it from the cursor vector, and makes the previous cursor active. The last results that a cursor sent are stored in the vector so that, when backtracking, the lastly viewed results are sent back to the Servlet. Unfortunately, we were obliged to keep the whole array of results in the vector, and update it on every call of the dbExec, since the JDBC API 1.0 does not support backward scroll in cursors [Ree97], [Sun97]. There are two issues worth mentioning at this point.  Firstly, the thread does not implement the database functionality of the methods described in its interface. The database communication and statement execution along with the cursors‟ vector and pointer are actually held by the connection wrapper (part of the dbthread - see Figure 2). The thread simply renders available the methods of the wrapper to clients and forwards the commands / methods to the wrapper, which in turn, proceeds with their execution and provides the thread with results.  Secondly, the methods of the thread are exactly the ones of the wrapper, apart from those devoted to keep track of sessions. Consequently, in order to perform different actions on the database or exchange different data types, one should only implement the new wrapper‟s methods and update the thread‟s interface and implementation accordingly. The overall architecture will not be severely affected by the changes. The equivalency between the various components of the architecture is shown in the UML class diagram of Figure 4.

9

Figure 4: UML class diagram of basic components

5. TESTED TRANSITION SCENARIOS We have evaluated the suitability of the architecture described above through a series of transition scenarios. Such scenarios are briefly described below. It should be noted that the tested scenarios represent application cases that require state preservation across individual interactions of the same user. Scenario 1 (Figure 5.a: Page transitions / Figure 5.b: UML State Diagram [Rum99]): 1. Execution of a predefined query. 2. Presentation of query results. 3. Browsing of subsequent records in the results‟ set (same cursor) Scenario 2 (Figure 6.a: Page transitions / Figure 6.b: UML State Diagram): 1. Execution of a predefined query over a master-detail database schema. 2. Presentation of master results (browsing next capability). 3. Drill-down to detail records (using the key of the master record) 4. Browsing of subsequent records of the detail results‟ set 5. Return (back) to master results.

10

StartState

Query Criteria Form
...... ...... ...... Submit
Display Results [1..n] Perform Query/Display Results Press "Exit"
EndState

Query Results [1..n]

Query Results [n+1..2n]

Press "Exit"

Press "Next" Press "Previous"

Display Results [n+1 ..2n]

(a)

(b)

Figure 5: Scenario 1 (browsing of next records)
StartState

Query Criteria Form
...... ...... ...... Submit

Perform Query/Display Results

EndState

Query Results [1..n]

Query Results [n+1..2n]

Select item

Press "Exit"

Display Results [1..n]
Press "Exit"

Press "Return"

Press "Next"

Drill-down [1..m]

Drill-down [m+1..2m]

Press "Drill-down" Press "Previous" Display Results [n+1 ..2n]

Drill-down Query

(a)

(b)

Figure 6: Scenario 2 (drill-down, browsing next)

6. CONCLUSIONS In this paper we have discussed the implementation of a framework for the deployment of stateful, database-driven WWW applications. Our architecture has been based on open and emerging standards like the Servlet API, CORBA and the JDBC specification for database access. The core components lie behind the WWW server and include a Dispenser module that coordinates a pool of database threads that, in turn, incorporate database connection wrappers. Wrappers may be structured ad-hoc. Hence, our architecture fits into a wide variety of application cases. Additionally, our architecture, due to the adoption of CORBA technology, caters for both in-process as well as out-of-process implementations of the server side of the middleware (i.e., the database application logic). The out-of-process scenario has been implemented and tested in the context of this paper. The in-process implementation can be achieved by incor-

11

porating the server side logic into a Java thread that will be activated from the Servlet engine (i.e., thread will be running in the same context with the client Servlets). REFERENCES
[All97] Allaire, “Cold Fusion Pro 3.0, User Guide”, Allaire Corp (1997). [Ber96] Berners-Lee, T., Fielding, R. and Frystyk, H., “Hypertext Transfer Protocol - HTTP/1.0”, RFC 1945, Network Working Group, (1996). [Bra93] Braek, R., and Haugen, O., “Engineering Real Time Systems”, Prentice Hall, (1993). [Bro96] Brown, C., and Benford, S., “Tracking WWW Users: Experience from the design of HyperVisVR”, proceedings of WebNet 96, San Fransisco, CA, (1996). [Cat95] Catledge, L., and Pitkow, J., “Characterizing Browsing Strategies in the World-Wide Web”, proceedings of the 3rd International WWW Conference, (1995). [Coa98] Coar, K., and Robinson, D., “The WWW Common Gateway Interface - Version 1.2”, Internet Draft, February, (1998). [Dat95] Date, C. J., “An Introduction to Database Systems,” Addison Wesley, (1995). [Eic94] Eichmann, D., McGregor, T., and Danley, D., “Integrating Structured Databases Into the Web: The MORE System”, proceedings of the First International WWW Conference, (1994). [Eic95] Eichmann, D., “Application Architectures for Web Based Data Access”, proceedings of the Workshop “Web Access to the Legacy Data”, 4th International WWW Conference, Boston, MA (1995). [Fie97] Fielding, R., Gettys, J., Mogul, J.C., Frystyk, H. and Berners-Lee, T., “Hypertext Transfer Protocol HTTP/1.1”, RFC 2068, Network Working Group, (1997). [Fla97] Flanagan, D., “JavaScript: The Definite Guide”, O‟Reilly & Associates, Inc. (1997). [Had96] Hadjiefthymiades, S., and Martakos, D., “A generic framework for the deployment of structured databases on the World Wide Web”, proceedings of the 5th International WWW Conference, (1996). [Had97] Hadjiefthymiades, S., and Martakos, D., “Improving the performance of CGI compliant database gateways”, proceedings of the 6th International WWW Conference, (1997). [Hun98] Hunter, J., and Crawford, W., “Java Servlet Programming”, O'Reilly & Associates, Inc., (1998). [Kri97] Kristol, D., and Montuli, L., “HTTP State Management Mechanism”, RFC 2109, Network Working Group, (1997). [Mic96] Microsoft, “Microsoft dbWeb 1.1 Tutorial”, Microsoft Corporation, (1996). [Omg95a] Object Management Group, “Common Object Request Broker: Architecture & Specification”, (1995). [Omg95b] Object Management Group, “Common Object Service Specification”, (1995). [Pad95] Padmanabhan, V.N., and Mogul, J., “Improving HTTP Latency”, Computer Networks and ISDN Systems Vol.28, (1995). [Per94] Perrochon, L., “Translation Servers: Gateways Between Stateless and Stateful Information Systems”, The Network Services Conference 1994 (NSC ‟94), London (1994). [Per95] Perrochon, L., “W3 „Middleware‟: Notions and Concepts”, proceedings of the Workshop “Web Access to the Legacy Data”, Fourth International WWW Conference, Boston, MA (1995). [Rag97] Raggett, D., Le Hors, A. and Jacobs, I., “HTML 4.0 Specification”, W3C Working Draft, (1997). [Ree97] Reese, G., "Database Programming with JDBC and Java", O'Reilly & Associates, Inc. (1997) [Rum99] J.Rumbaugh, I. Jacobson, and G.Booch, “The Unified Modelling Language – Reference Manual”, Addison Wesley, 1999. [Smi96] Smith, K., “Server Side Javascript”, Netscape First Annual Internet Developer Conference, San Francisco, CA, (1996). [Spe94] Spero, S., “Analysis of HTTP performance problems”, (1994). [Sun97] Sun Microsystems Inc., "JDBC: Getting Started", (1997). [URL1] Java Apache Project, http://java.apache.org [URL2] Orbacus, Object Oriented Concepts, http://www.ooc.com/ob

12


				
DOCUMENT INFO
Jun Wang Jun Wang Dr
About Some of Those documents come from internet for research purpose,if you have the copyrights of one of them,tell me by mail vixychina@gmail.com.Thank you!