资源目录
压缩包内文档预览：
编号：438880
类型：共享资源
大小：2.81MB
格式：RAR
上传时间：2015-06-03
上传人：小***
认证信息
个人认证
林**（实名认证）
福建
IP属地：福建
20
积分
- 关 键 词：
-
求职
招聘
- 资源描述：
-
求职与招聘,求职,招聘
- 内容简介：
-
Future Generation Computer Systems 15 (1999) 417424Efficiency of standard software architectures for Java-based access toremote databasesN. Zingirian, M. Maresca, S. NalinDipartimento di Elettronica ed Informatica, University of Padua, Padua, ItalyAccepted 14 December 1998AbstractNovelclientserverarchitecturesforremotedatabaseaccessareincreasinglytakingadvantageofWebtechnology,adoptingWeb browsers as graphic user interfaces in the clients and traditional SQL database management systems (DBMSs) in theservers. The inter-operation between standard browsers and specific DBMSs is today supported by a number of softwarearchitectures based on the Java virtual machine embedded in last generation browsers. Unfortunately such software architec-tures, which appear excellent from the points of view of openness and flexibility, introduce conspicuous latencies in databaseaccess. The objective of this paper is to identify such latencies through the analysis of a number of experimental results. Thepaper describes four different software architectures supporting Java-based SQL database access, reports their performancemeasurements on different hardware platforms and compares the results obtained. c?1999 Elsevier Science B.V. All rightsreserved.Keywords: CORBA; Java; JDBC; Performance evaluation; Visual database access1. IntroductionThe traditional approach to clientserver database access is based on the combined action of a user interfacewritten in a visual language (i.e. the client) and a standard SQL engine (i.e. the server). Currently, this approach ischallenged by novel solutions based on the emerging Web paradigm 1.In the Web-based solutions the user interface, typically written in Java, is downloaded by a browser from theserver and runs on the browser virtual machine. The main point of such solutions is that the client software residesin the server system as a unique copy, rather than being replicated in the client systems. This fact allows the costsof installation, configuration and maintenance of the client software to be reduced thanks to the possibility ofcentralising all these operations at the server site 2.Web-based access to SQL databases can be supported by a number of software architectures 3 characterized bya different composition of a set of basic components 4. Unfortunately such software architectures, which appearexcellent from the point of view of openness and flexibility, introduce conspicuous latencies in database access.Corresponding author.0167-739X/99/$ see front matter c ?1999 Elsevier Science B.V. All rights reserved.PII: S0167-739X(98)00085-5418N. Zingirian et al./Future Generation Computer Systems 15 (1999) 417424Fig. 1. Software architecture 1: database access through Java sockets.TheobjectiveofthestudypresentedinthispaperistodescribefourdifferentsoftwarearchitecturesimplementingWeb-based SQL database access and to report and compare their performances, characterizing the sources of thelatencies introduced by each architecture.The paper is organized as follows. First we describe the standard software architectures for Java-based databaseaccess (Section 2). Then we present the testbed used and the methodology followed in our experiments (Section 3).Finally we present the results of the experiments (Section 4) and discuss the performance profile of the softwarearchitectures tested (Section 5). A brief summary (Section 6) concludes the paper.2. Software architectures for Java-based database accessIn this section we present the four software architectures for Java-based database access that we selected for ourinvestigation. Each architecture complies with the clientserver paradigm and consists of three main entities: theclient, the server and the inter-operability components. The client and the server are the same in each architecture;the inter-operability components are the distinctive feature for each architecture.The client is a Java-enabled browser, the server is a SQL database management system (DBMS) which acceptsremotenetworkconnectionsandqueries.WeassumethatthenetworkprotocolstackisbasedontheTCP/IPprotocolsuite.The inter-operability components of each software architecture are described in the rest of the section.2.1. Architecture based on Java socket connectivity modulesTheschemeofthearchitecturebasedonJavasocketconnectivitymodulesisdepictedinFig.1Theshadedblocksrepresent the software modules that the programmer has to develop to interconnect the existing components.The client (browser) downloads an applet from the server machine and runs it. The applet sends the queries andreceives the responses through the Java socket modules.The server (DBMS) exchanges data with the client through a software component that acts as an intermediatecustom agent. Such an intermediate custom agent receives the client queries and submits them to the databasethrough the database API library.The connectivity between the applet and the custom agent is based on TCP/IP. On the client side communicationis supported by the standard Java socket API; on the server side communication is supported by the standardUNIX socket interface. Inter-operation between the applet and the custom agent is based on a custom protocolwhich supports the fundamental database access operations (open database, submit query, retrieve response, closedatabase).2.2. Architecture based on proprietary DBMS JDBC driverThe Architecture based on proprietary DBMS JDBC driver is depicted in Fig. 2. Java dataBase connectivity(JDBC) is a standard interface which allows Java applets and applications to inter-operate with database. Like inN. Zingirian et al./Future Generation Computer Systems 15 (1999) 417424419Fig. 2. Software architecture for database access based on DBMS proprietary Java JDBC.Fig. 3. Software architecture for database access based on Java JDBC and request broker.the previous architecture, the client (browser) downloads an applet from the server machine and runs it. The appletaccesses the DBMS through the standard primitives of the JBDBC application programming interface (JDBC API).The JDBC API is available as a part of the standard classes of the Java developer kits and of the Java-enabledbrowsers compliant wit the latest versions of Java. The JDBC classes are not specific for any particular DBMS,except for one class, denoted the JDBC driver, which implements the communication protocol required by thespecific DBMS which it refers to. The specific JDBC drivers are provided by the DBMS vendors or by third partiesand are dynamically linked to the standard JDBC objects. Usually the JDBC driver is downloaded from the serveralong with the client applet.TheDBMSdriverinteroperateswiththeDBMSoverthenetworkbytranslatingtheJDBCmethodsinproprietarymessages to proprietary service request messages.Theserver(DBMS)receivesthequeries,sendstheresponsesandperformsalltheoperationsthroughitsproprietaryprotocol, with no need of additional inter-operability modules in the server machine.2.3. Architecture based on JDBC request broker middlewareThe architecture based on a request broker is depicted in Fig. 3. As in the previous architecture, the appletcommunicates with the database through the standard JDBC API and through a specific JDBC driver. As opposedto the previous architecture, the JDBC driver does not access the database directly but it access an intermediateobject, called the broker, running on the server machine, through a proprietary protocol. When the applet requestsa connection, the request broker dynamically instantiates two components: a JDBC agent, and a database agentspecific for the DBMS adopted.The server (DBMS) and the client inter-operate through the database agent and through the JDBC agent whichinteract by means of a proprietary protocol. The openness and flexibility advantages of using the request broker andthe agents are discussed in 5.420N. Zingirian et al./Future Generation Computer Systems 15 (1999) 417424Fig. 4. Software architecture for database access based on CORBA.Table 1Software products used as components of the tested software architecturesSoftware componentSoftware productVendorDBMS 1PostgreSQL 6.1.1University of California 7BrowserNavigator 4NetscapeJava socketclass .socketNetscapeDBMS JDBC driverclass postgresql.driverUniversity of CaliforniaRequest brokeroplrqbOpenlinkDatabase agentpgr95 svOpenlinkJDBC agentjdbc svOpenlinkBroker JDBC Driverclass openlink.driverOpenlinkClient ORBpackage org.omg.CORBAVisigenic/NetscapeServer ORBomniORB2Olivetti & Oracle Research Labs2.4. Architecture based on CORBA inter-operability componentsThe CORBA-based architecture is shown in Fig. 4. Even in this case the applet communicates with the DBMSthroughanobject-orientedAPI.ThisAPIinstantiatesandinter-operateswithadatabaseaccessobjectwhichresidesin the server machine. Inter-operability is supported by a pair of libraries called object request brokers (ORBs) 6which communicate through the Internet Inter-ORB protocol (IIOP). One ORB is a Java package located in theclient machine while the other ORB is a library located in the server machine.The server (DBMS) communicates with the database access object through the DBMS application programminginterface.The database access object is developed by the system integrator and its API is described through a formalspecification language denoted as inerface description language (IDL). The IDL supports reliable inter-operationbetween the client and the server in spite of the fact that the programs are written in different languages.3. Tested and methodologyIn this section we describe the testbed that we used and the methodology that we followed to carry out theexperiments. We installed the DBMS on a server machine (PC Pentium Pro, 200MHz, 32Mbytes RAM, Linuxoperatingsystem)andthedifferentsoftwarecomponentsinclientmachines(PCPentium166MHz,HP715100MHzand Sun Sparc5 75MHz, each equipped with 32MB and running Unix operating systems), choosing the productsreported in Table 1. We identified three database operations as the basic operations to be tested, namely databaseopening, query execution, database close. The query execution we adopted for our tests was a single selection of anitem consisting of a 34 byte long string from a table of more than 39000 rows of four columns each. Each latencymeasurement was obtained by repeating each experiment more than 6000 times and selecting the minimum result,in order to minimize the incidental overheads.N. Zingirian et al./Future Generation Computer Systems 15 (1999) 417424421Table 2Minimum times for database basic operations locally and remotely with Java socket for each platformLocalSocketPCHPSunOpen33373838Exec54606268Close67686869Tomeasurethetimeweusedthejava.util.Date.getTime()methodonJavaprograms,thegettimeof-day()systemcallonC/C+programswhenthesourcecodewasavailable,andthestrace-ttf-phprocessPIDi Linux command when the source code was not available. The first two commands read the system real-timeclock,thecommand straceinterceptsandrecordsthesystemcallsactivatedandthesignalsreceivedbythetracedprocess, reporting the time of each event. To keep the tracing overhead acceptable we limited the tracing only tothe system calls significant for our measures.4. Experiments and resultsThe experiments were carried to measure and characterize the database access latencies. In a preliminary setof experiments we measured the common latency components present in the four software architectures. In therest of the experiments we measured the latencies present in each software architecture and identified the specificoverheads as well as the sources of such overheads. We report the results of the preliminary set of experiments inSection 4.1 and the results of the rest of the experiments in Section . Preliminary experimentsThis section presents a preliminary set of experiments carried out to measure the latencies common in all thesoftware architectures based on Java-enabled clients, namely, (i) the database local access time and (ii) the Javasocket communication time.To measure the database local access time we developed a C program which activates the basic operations of thedatabaseaccesslibraryonthelocalmachineandmeasurestheirexecutiontime.Themeasurements,inmilliseconds,are reported in Table 2 (first column).We also measured the overheads due to the access of the library to the database, by tracing the internal TCP/IPcommunication between the library and the DBMS. We experimented that such overheads are negligible, namelyless than 2ms.TomeasuretheJavasocketcommunicationtime,wesetupthearchitecturebasedonsocketconnectivitymodules(See Section 2.1). The custom agent module in this architecture was obtained by making the C program developedfor the previous experiment accessible through TCP/IP connections. The timing measurements of this architectureare reported in the second set of columns of Table 2 (each column corresponds to a different hardware platformused in the test). The results reveal that the remote access through Java socket introduces latencies which are notnegligible with respect to the database access times, namely 1030% for database opening and query execution.It is noteworthy that the last results were obtained after optimizing the use of the Java socket interface. Theoptimization consisted of identifying the most efficient access methods to the Java socket buffers among the varietyof methods available (e.g. read/writeByte, read/writeInt, read/writeBytes, read/write, etc.), packing the messages inthe format required by the methods identified and sending them out by means of one method invocation. The effectsof such optimizations are relevant because the latency of socket I/O, which heavily affects the overall performance,is highly variable depending on the method used.422N. Zingirian et al./Future Generation Computer Systems 15 (1999) 417424Table 3Minimum query times for different software architectures and client platformsLocalJDBCJDBC/brokerCORBAPCHPSunPCHPSunPCHPSunOpen331431922187093160394244Exec54101104106778083667178Close6758100017275784.2. Experiments on standard software architecturesThissectionpresentsasetofexperimentscarriedouttoevaluatetheefficiencyofstandardarchitecturesdescribedin Section 2. The standard architectures evaluated are based on JDBC and CORBA inter-operability modules. Inthis section we present the measurements of overheads introduced by two architectures based on the JDBC standardand one architecture based on the CORBA standard.4.2.1. Efficiency of the architecture based on proprietary JDBC driverColumns 24 of Table 3 report the basic database access times, in milliseconds, measured on the architecturedescribed in Section 2.2.In the open operation we identified the following two sources of overheads: (i) a Java socket connection isestablished whenever the database is opened and (ii) each item necessary to the connection to the database (login,password, database name, etc.) is sent through separate read/write of messages on sockets. The first overhead isdue to the fact that in the JDBC standard the database close operation causes the close of the TCP/IP connection.The overhead is 18ms in the PC platform, 28ms in the HP platform and 37ms in the Sun platform1. The secondoverhead is due to the fact that the JDBC driver for PostgreSQL DBMS does not pack the information in a singlestring in order to minimize the number of read and write operations on Java sockets. This overhead, in addition, isextremely variable in the different hardware platforms (10ms for PC, 22ms for HP and 67ms for Sun).In the execution of the queries the main source of inefficiency derives from the fact that the JDBC standardrequires the preparation of a complex data structure (which is an object of class ResultSet) in response to the query.We found that the time required to build this structure is 10ms in all the architectures. In addition, we experimentedthat reading the results of the query from the network requires bytewise reading from socket which often causesabnormal overheads (typically 30ms) on the Netscape Java Virtual Machine implementation in HP workstation.4.2.2. Efficiency of the architecture based on JDBC request brokerColumns 57 of Table 3 reports the basic database access times, in milliseconds, measured on the architecturedescribed in Section 2.3.In the open operations we identified the following source of inefficiency by tracing the system calls of the requestbroker: (i) the applet creates two network connections to open the database, respectively toward the request brokerand toward the JDBC agent; (ii) the server requires long time to fork and to configure the two agents. The firstsource of overhead produces latencies from 36 to 74ms depending on the hardware platforms. The second source ofoverheadproducesalatencyofabout75ms.WeobtainedthisvaluebymeasuringtheintervalbetweentheconnectionrequesttimetotherequestbrokerandthequeryarrivaltimetotheDBMSandbysubtractingthenetworkconnectionlatencies.In the query execution the main source of inefficiency derives from the fact that the Database Agent opens thedatabasebeforesendingthequeryandclosesitaftersendingbacktheresulttotheJDBCAgent.Asaconsequence,theoverheadisduetotheopenoperation,whichtakes33ms,asweshowedabove.Inadditionthetimingmeasurements1This fact explains also the time measured for the close operation: the client does not wait for the termination of the database close operationbefore closing network connection.N. Zingirian et al./Future Generation Computer Systems 15 (1999) 417424423reveal that Java sockets are used efficiently, considering that the execution time is close to the sum of the timemeasured in the Java socket architecture plus the database opening time.The close time reveals that the database is closed after the network connection is closed. The close time includesonly the handshaking operations necessary before the termination of the agents.4.2.3. Efficiency of the architecture based on CORBAColumns 810 of Table 3 report the basic database access times in milliseconds measured on the architecturedescribed in Section 2.4. These measurements reveal that the architecture based on CORBA introduces negligibleoverheads with respect to the latency measurement of the architecture directly based on Java sockets, in all theoperations and in all the hardware platforms (see Table 2). It is worth recalling that the results obtained in thearchitecture based on Java sockets were the result of several optimizations on the communication protocol and onsocket method invocation. As a consequence our experiments reveal that CORBA inter-operability modules makeoptimized use of the Java sockets.5. DiscussionTheexperimentspresentedintheprevioussectionallowextractingaperformanceprofileofthestandardsolutionsfor Java-based access to databases. Such profile is valid in case of local environments (LANs) in which networklatencies are negligible with respect of the other system latencies.TheperformancecharacteristicsofJavasocketmodulesobtainedinourexperimentsare:highlatenciesinconnec-tionsandread/writeoperations,highvariabilityofsocketlatenciesversusthetypeofdatatransmittedanddependingon the hardware platforms used.The performance variability of Java sockets affects the performance of all the other Java-based solutions whichunavoidably rely on Java sockets. However we experimented that the solutions based on JDBC and CORBA aredifferently affected by such a variability.Some experiments revealed that the Java socket interface propagates its poor performance to the JDBC modules.In particular we experimented that the Java socket operations add an overhead which ranges approximately from30% to 100% and varies heavily according to the hardware platform used.On the contrary, other experiments revealed that CORBA is not affected by the poor performance of Java socketoperations. In particular we measured a performance close to the best performance obtained optimizing Java socketmethod invocations in the custom client, without exhibiting latency variations among different hardware platforms.The good performance of CORBA is due to the fact that the communication library (client ORB) performs anaccess to the Java socket interface specifically optimized to transport the (IIOP) protocol. In addition, unlike JDBCDrivers, the client ORB can be implemented in different ways according to the different hardware platforms. Theclient ORB is not downloaded along with the applet, as it belongs to the standard packages of Java.Finally we demonstrated that the CORBA standard inter-operability modules are the best suited database accesssolution for high performance LAN environments, because of the following reasons: theCORBAarchitectureactsatalevelwhichishighenoughtosupportreliableandeasilystandardizableinterfacesbetween clients and servers written in different languages and running in different environments. the CORBA architecture acts at a level which is low enough to belong to the standard library package of Java,which can be optimized to hide the performance problems of the Java socket interface.6. SummaryThe paper has presented a set of measurements aimed at characterizing the performance of four software archi-tectures, based on the Java socket interface and on JDBC and CORBA standards. These two standards are the most424N. Zingirian et al./Future Generation Computer Systems 15 (1999) 417424frequently proposed solutions to the system architects in order to make remote database servers accessible fromJava clients.The main contributions of our work are the performance evaluation and the comparison of the software architec-turestestedaswellastheidentificationofthebottlenecksinthemostsignificantdatabaseaccessoperationsforeacharchitecture. The most relevant results are the characterization of the inefficiency of the Java classes for networkaccess (Java socket), the impact of such a inefficiency on the architectures based on JDBC and the immunity of thearchitectures based on CORBA from such an inefficiency.References1 J. Gary, Evolution of data management, IEEE Computer Magazine 29(10) (1997) 3846.2 J. Hamilton, Java and JDBC: tools supporting data-centric business application development, IEEE Proc. 4th Int. Symp. on Assessme
- 温馨提示:
1: 本站所有资源如无特殊说明，都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
2: 本站的文档不包含任何第三方提供的附件图纸等，如果需要附件，请联系上传者。文件的所有权益归上传用户所有。
3.本站RAR压缩包中若带图纸，网页内容里面会有图纸预览，若没有图纸预览就没有图纸。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 人人文库网仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对用户上传分享的文档内容本身不做任何修改或编辑，并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容，请与我们联系，我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
人人文库网所有资源均是用户自行上传分享，仅供网友学习交流，未经上传用户书面授权，请勿作他用。
川公网安备: 51019002004831号