Comparing Access Techniques on Databases in Distributed Application Frameworks Daniel Stuparu, Alina Andreica, Iulia Mantu IT Department, Babes-Bolyai University
[email protected],
[email protected] ,
[email protected] Abstract: The paper compares various access models on databases within distributed applications in order to give consistent solutions to application design problems. In this respect, we implement and compare 3 modules with similar to identical processing goals but based on different access principles, for handling the same database – containing an accounting plan, which is accessed by distributed applications. The implemented models are: classical standalone access, access using adapters and client-server access. The characteristics of each technique, its advantages and disadvantages are discussed in the paper – in respect with the database complexity, both from the design and especially from the run-time and efficiency points of view. We conclude that the overall most convenient model from the above mentioned ones is the one using adapters, since it balances runtime efficiency and design complexity 1. Introduction The present study addresses the problem of choosing an optimal access model on databases in distributed application design, mostly using ODBC connection protocol. We implement 3 access models, comparing their run times and design characteristics. The implemented models, described in the following section, are: the classical access model using ODBC protocol, a more advanced model using ODBC protocol and adapters, specific to .NET technology and the client server model, which uses JDBC connection protocol and client-server communication implemented by means of XML messages 2. Design Principles In order to gain flexibility, our implementations are based on a n-tier architecture [AnSt05], which elegantly supports model adaptation, requiring minimal code rewriting. All implemented models contain a user interface level (at the client-close side of the application) and a business layer, which interfaces with the database. The business layer is fairly similar in the classical and client-server models, while being significantly simplified in the adapter-based model, based on built-in adapter properties In order to benefit more of n-tier architecture advantages, we implemented in two dynamic libraries the processing related to the database management system connection - SQLStatement.dll, respectively to the server module - ClientXML.dll. SQLStatement.dll library is used by the classical standalone version and the adapter version, while ClientXML.dll is used by the client-server version. Our study is performed using PostgreSQL 7.3 database management system, the client applications being implemented in C# language, using Microsoft .NET Framework 1.1 technology. Within the client-server version, the server module is written in Java, 1
using jdk1.5.0_04. The client workstation runs Microsoft Windows XP SP2 and the database server runs FreeBSD 6.0 Current operating systems 2.1. Classical standalone and adapter versions 2.1.1. Design principles of the classical standalone version Within this version, as well as in the adapter based one, the remote database is accessed by SQLStatement.dll module. SQLStatement.dll implements the connection to the database using ODBC, brings from the database the data required by the client and sends all the processed data to the database within the same transaction (consequent to client data processing, the updates are temporary saved in order to be send to the database by means of a unique transaction) 2.1.2. Design principles of the adapter version An adapter creates a channel between a data source (the remote database) and a local memory mapping of the database – in .NET technology – the DataSet structure [Rob02] Given a table name, within SQLStatement.dll module, we construct its corresponding adapter. We build the adapter based on the corresponding table structure (columns and their types) obtained by interrogating the database server catalogues. In respect with the table constrains, the adapter constructs the necessary data access statements (SELECT, UPDATE, DELETE, INSERT). The adapter returns the table from the database in read-only format, therefore access and update operations on the table data are only made by means of the adapter’s methods; the Update method is used for saving the data modifications into the database. 2.1.3. SQLStatement module SQLStatement.dll is implemented as a communication interface between the clients and the database. The module is designed to encapsulate the server connection and the access methods implementation in order to facilitate multiple client connections to the database server. Up to the present stage of implementation, concurrence issues are treated only by the database management system but we intend to address the problem in our near future work, by using a client-server messaging system In order to use a connection, the client extends AbstractConnection class; consequent to the connection initialization, the client can use the access methods implemented within SQLStatement interface: public class AccountsPlanBL : AbstractConnection { public AccountsPlanBL() { client = base.getConnection(); } private SQLStatement client; ... }
2
A brief description of the implemented methods, which are available to the clients, is given below: - ExecuteNonQuery – the method executes an UPDATE, DELETE or INSERT SQL statement, given as a string, and returns the number of processed records - ExecuteSelectReader – the method returns the result of a SELECT query by instantiating the IdataReader interface offered within .NET Framework - ExecuteScalar – executes the query given as parameter and returns the first column from the first line in the query result (the others lines and columns are ignored). - MakeTabelFromSQL – returns the result of the query given as parameter as a DataTable - MakeTabelAdapter – is the most complex method in the library. It instantiates the IDataAdapter interface based on the table name given as parameter and returns an adapter object which implements the IDataAdapter interface and encapsulates all the methods implemented for processing the corresponding table
Fig.1. SQLStatement – class diagram
2.2 Client-server version
A client-server architecture [Hog03] divides application functionalities into 2 subsystems: the client – which emits the requests, and the server – which solves the requests providing the results; the architecture ensures client-server communication by standard methods (for example TCP/IP) in order facilitate information exchange between the 2 subsystems
3
2.2.1.Design principles of the client-server version Within the client-server implementation, the server application module accesses the database by means of JDBC protocol The server module implements concurrent access, the number of possible treated clients being equal to the one supported by the database management system. The server side is implemented in Java, a language that ensures portability. For the present study, it was installed on the database server (we used the same machine both for hosting the database and running the server module) The business layer in the client side uses ClientXML.dll module, which practically links the business layer to the server module. The client connects to the server module, sends its data requests and receives the results. Data modifications are temporary locally stored (similar to the classic standalone model – see 2.1.1.) and consequent to data processing all the necessary information is transmitted to the server module which connects to the database and transmits the data within the same transaction, in order to increase run-time efficiency Client-server communication is implemented by means of XML messages, a format with significant advantages: portability, transmission speed, efficient processing. We can place the server module either on the database server machine, or on a different machine (and from the client side machine) 2.2.2. ClientXML module ClientXML.dll library intermediates the communication between the clients and the remote server module. The communication implements TCP/IP socket technology and the messages use XML format, as further described We introduce the following format for the XML message that sends a request to the server:
We introduce the following format for the XML message that contains the server response to the client:
query
//for type UPDATE, INSERT, DELETE received message no of records //for SELECT type value … …
The client should perform the following steps: - initialize the connection to the server; client = new ClientSocket();
-
send the request to the server and receive the response; 4
result = client.SelectStatement(interogareSQL);
-
close the connection to the server client.CloseClientSocket();
A brief description of the methods offered to the client within ClientXML.dll is given below: - ClientSocket – initializes the communication with the server module in respect with the connection parameters; - SelectStatement – for a SELECT SQL query given as parameter, the method returns a table containing its result or an error message, if the query is incorrect; - UpdateStatement – executes an update-type statement (UPDATE, INSERT sau DELETE) on the database. The input parameters are the statement type and the SQL statement. The method returns a 2-dimension array in which the first line elements are set to 0 if correctly executed or –1 in error cases and the second line contains either the number of records involved, if correctly executed, or an error message otherwise. The SQL statement given as parameter may be an array of SQL statements delimited by “;”. All these statements are performed by the server module within the same transaction, in order to increase speed. - CloseConnection – closes the connection between the client and the server
Fig.2. ClientXML – class diagram
2.2.3. Server side The server module was implemented as a conccurent server, i.e. along the whole period of time dedicated to performing a service, it can respond to client requests. Therefore, the server module can solve requests from many clients simultaneously. Therefore, when a client connects to the server module, the server launches a process in order to solve the received request, and resumes waiting for requests coming from clients’ side For an efficient server exploitation, we defined a maximum number of users that may connect to the server (we defined the static variable MAXUSERS, whose value is set 5
using the configuration file of the database management system). Therefore, we also handle the number of current active users at any moment (using the variable usersNo). W handle the channels with existing / available threads in loggedUsers array: loggedUsers:[0, MAXUSERS)Æ {0,1} loggedUsers[i] = 0 – on channel i there is no active thread = 1 – channel i contains an active thread The client-server communication is implemented using sockets (communication channels between the server and the client) The server implements the following algorithm: While the module is active server waits for requests If a request appears Step A Analyze loggedUsers let l be the first free position in loggedUsers If l∈[0,MAXUSERS) //there is a free channel Create a socket between the server and the client Initialize a Thread on l Thread connects to the database on port port Thread solves the request and sends the answer Otherwise Emit a message to the client Go to Step A EndIf EndIf EndWhile 3. Comparing the Access Techniques For the benchmark presented in this section we used an AMD Sempron 2600+, 512 Mb RAM as client machine and a IBM NetFinity 5100, 2 procesoare 933MHz, 512 Mb RAM server machine. The PostgreSQL database is located on the same server and for the present study we accessed only one table from the database, containing 6 columns and a variable number of records, loaded in order to run-time behaviours of the 3 models. We intend to extend our study for a more extensive access on the database and for testing concurrent behaviour of the 3 models We denote with: T1 = the time necessary for bringing the table to the client once; T2 = the time necessary for bringing the same table to the client 10 times ; T3 = the time necessary for bringing the same table to the client 100 times; For all 3 versions, we experimented various table dimensions: 500 records, respectively 5000 records For the adapter version we supplementary measured Ta – the time necessary to create the adapter For the client-server version we supplementary measured Ts – the time necessary to create the socket
6
The client-server version implementing the socket technology cannot maintain open the same client-server channel, therefore each table request requires a new connection, fact that significantly decreases run-time speed when repeated requests appear for the same table The results are systematized in the following table: Table 1: Run-time comparisons for the 3 models: Classic, Adapter, Client-Server Model No records
T1
T2
T3
Ta Ts
500records 5000records 500records 5000records500records 5000records
CLASSIC 0.1875 ADAPTER 0.109375 Client-Server 0.2325
0.609375
0.5625
5.171875
5.578125
51.84375
0.359375
0.453125
3.28125
4.609375
35.765625 0.125 ---
0.2686
47.375
47.4375
---
---
-----
We observe that the adapter implementation (see 2.1.2) is the most efficient, since it can use the same communication channel between the client and the database, the connection being modeled by using the table adapter. Nevertheless, for accessing more tables from database, the run time will increase with Ta for each table. We intend to test such access types in the near future Although the client server implementation (2.2.1) is the fastest for large tables accessed once, it becomes tedious for multiple accesses since each access involves the creating of a new socket, repeatedly adding the time Ts The classical version (2.1.1) is the easiest to design and program (each data request may be directly send to the database) but slower than the adapter version since the built-in adapters ensure a more efficient communication and demand a resourceful application design We underline that all our implementations use a single database transaction in order to make the necessary updates, technique which decreases run time but adds more challenges in design and programming. Minimizing database access also enhances the problem of treating concurrency, which we are also going to address in the near future; in this respect, we intend to implement a client-server messaging system over the adapter version in order to communicate necessary updates to clients. 4. Conclusions and Future Work The paper addresses the problem of optimal database access within distributed application frameworks. In this respect, we implement and compare 3 models: the classical standalone version, the adapter one and the client-server version. We conclude that the overall most convenient model from the above mentioned ones is the adapter version, since it is the most efficient from the run-time point of view and it also displays a moderate design complexity In our future work we intend to test our implementations for more complex and dynamic access requests on the database and to implement another distributed version, based on the use of Remoting protocol (in order to reduce the run-time supplements generated by repeated socket construction). We are also going to deal with concurrency issues – in this respect, we intend to implement a client-server messaging system in order to communicate necessary updates to clients. Consequent to these implementations, we’ll extend our efficiency experiments in complex distributed access conditions 7
--4.5
5. References [AnSt05]
Alina Andreica, Daniel Stuparu – Advantages of Multi-Tier Architecture in Designing Complex Software Applications for Network Environments, Proceedings of RoEduNet International Conference “Networking in Education and Research”, 4th Edition, Târgu Mureş, May 20-21, 2005, Conference CDROM [AbHu95] S. Abiteboul, R. Hull, V. Vianu: Foundations of Databases, AddisonWesley Publishing Company, 1995. [Bo00] Bourret R. P.: XML Database Products: http://www.rpbourret.com/xml/ 2000 [CSN99] Client/Server and the N-Tier Model of Distributed Computing, Micromax Information Services Ltd. 1999 [Hog03] Hoganson, K., Guimaraes, M., „N-Tier Client/Server Course”, Consortium for Computing Sciences in College Conference, Dunwoody, Georgia, 2003 [McB00] McBrien P., Poulovassilis A. „Distributed Databases”, 2000 [Rob02] Robin A., “SOOP with Microsoft Visual Basic .NET and Microsoft Visual C# .NET step by step“, Microsoft Press, 2002 [Sce02] Sceppa D., “Microsoft ADO.NET “, Microsoft Press, 2002 [CSW] Client/Server http://www.iterrasoft.com/ClientServer.htm [3nT] 3- and n-Tier Architectures http://www.corba.ch/e/3tier.html
8
