exploring db2 data access via web and...

Exploring DB2 DataAccess via Web and Internet 1

Exploring DB2 Data Access via Web and Internet

A HiT Software White PaperIn an era where data access is taking off in new directionswith public web applications and more private intranet use,HiT Software looks at the technology available and theissues that face DB2 data access application developers.

1. DB2 SQL Interfaces for Remote Data AccessODBCOLE DBJava/JDBC

2. Application ArchitecturesWhat is a Web Application Anyway?Client Server Data Access Models2-Tier Applications: Middleware on Client2-Tier Applications: Middleware on Server

3. Development Options for Web ApplicationsHTML and VBScript with ADOJava servlets/applets with JDBC

4. SecuritySSLAuthenticationPublic Key Encryption

5. PerformanceSQL Connections/PoolingThreadsPolling/Event AlertsApplication Logic

6. Conclusion

HiT Software, September 1999 2

Over the past year, many of our customers have been asking us for advice on designing applicationsthat access DB2 using the World Wide Web, or via Internet/intranet. Customers are either consideringapplications to run in Microsoft Windows environments, or trying to remain platform independentby using Java. This white paper addresses the core issues that project managers and developers facein designing and implementing a new, more complex generation of data access applications.

Here are some typical applications that we will refer to throughout this paper:

• Product and Inventory application: A corporation’s domestic sales offices need an application thataccesses product and inventory data stored in DB2 at corporate headquarters. The organizationwants a web application to accomplish this.

• Financial Application: US and European company headquarters need to access financial datastored in DB2, but the IS team is concerned about data security.

• Multi-platform application: A large corporation with applications running on multiple serverplatforms (Mainframes, UNIX, AS/400, Windows NT) wants to use a single standarddevelopment environment and a uniform way to access DB2 data that runs on any platform.

Before looking at the issues involved in designing and implementing web or Internet/intranetapplications for DB2 access, we review some of the software that is currently used for accessing datastored in DB2. This type of software is often called “middleware”.

1. DB2 SQL Interfaces for Remote Data AccessStandard interfaces like ODBC, JDBC and OLE DB, are available for accessing SQL databases fromexternal applications. Using a standard interface allows you to purchase “off-the-shelf” products forcommonly used databases and platforms instead of developing proprietary applications. Standardsspeed internal development and simplify IS support over the life of applications. For example, todevelop the product and inventory application example in our introduction, you might purchase OLEDB middleware for DB2 then write a simple script that accesses and displays data from DB2 in a webpage. Without standard middleware, you would need to develop your own connectivity software toconnect to the DB2 server in addition to retrieving data to display in the web page.

To ease development of Windows database access applications using OLE DB and ODBC, Microsofthas introduced a higher level programming interface known as ADO (ActiveX Data Objects). ADOprovides a set of objects that can be used from programming languages such as Microsoft’s VisualBasic and C++ or from scripting languages such as VBScript and JScript for connecting to a databaseand manipulating data.

OLE DBOLE DB is the foundation for Microsoft’s current data access architecture. OLE DB provides greaterflexibility over ODBC in that it allows access to non-relational data in addition to data stored inrelational databases such as DB2. It presents an object-oriented interface for generic data access. OLEDB is based on the Microsoft Component Object Model (COM) architecture for applicationcomponents. Third party developers, such as HiT, have created OLE DB middleware that managesthe lower level, procedural, database connectivity state management.


To implement an application using OLE DB, you typically use ADO methods and properties to callthe OLE DB interface. ADO provides a high-level interface that can easily be used from within C++,Visual Basic, VBScript and so on.

ODBCODBC (Open Database Connectivity) is a commonly accepted Application Programming Interface(API) for database access from Windows. It is based on the specifications from X/Open and ISO/IECfor database access and uses SQL as its database access language. Although Microsoft and othershave developed higher level interfaces over ODBC, it is fundamentally a low-level, procedural, state-managed interface.

ODBC middleware is available for all commonly used relational databases, and hundreds of third-party products are designed to work with ODBC. HiT has developed ODBC middleware for DB2 andDB2/400. To use an ODBC driver, you first define a data source (a set of parameters to connect to aspecific DB2 database using a specific network connection). Your application can then connect to aDB2 server using the ODBC Manager, which calls a database-specific ODBC driver in the Windowsenvironment.

JDBCIn the Java world, JDBC offers a set of classes for accessing relational databases from Java. LikeODBC, it is based on the specifications from X/Open and ISO/IEC for database access and uses SQLas its database access language.

The JDBC class library provides methods that mirror the ODBC API. There are several types ofJDBC middleware, including a JDBC-to-ODBC bridge (Type 1), and direct JDBC connectivity to therelational database (Type 4). HiT offers type 4 JDBC drivers that allow you to connect directly toDB2 or DB2/400 without intermediary ODBC middleware.

2. Application ArchitecturesLet’s look at the most commonly used architectures for database access applications in the context ofthe Internet and the World Wide Web.

What is a Web Application Anyway?Before describing some possible application architectures for database access, we define how we usesome crucial terms:

A web application is accessed via an HTML page from a web browser such as Netscape Navigatoror Microsoft Internet Explorer. The web application usually runs on a web server or applicationserver.

An Internet application uses the public networks to communicate information or distributeapplication logic. Internet applications do not necessarily use a web browser as their client. Webapplications can be Internet applications if they are publicly accessible via Internet. Traditional client-server data access applications can be Internet applications if the client connects using the Internet.For example, an ODBC-enabled application such as Microsoft Access could use ODBC middlewareto connect to a DB2/400 database server via a TCP/IP connection.


An intranet application uses a private network, secured by a firewall or other access-limitingtechnology, within a single organization to communicate information or distribute application logic.Intranet applications do not necessarily use a web browser as their client. In most cases, however, theterm intranet is synonymous with an organization-wide web site, which probably also has a numberof web applications. For the purposes of this paper, an intranet application is a type of webapplication. A product and inventory application that displays data from the corporate database in anHTML page for sales offices across the country, is both an intranet (private network) and web (runsin a browser) application.

Client-Server Data Access ModelsRemote data access models usually present two-tier or three-tier architectures.

• Two-tier applications formulate SQL calls on one system and send the calls directly to the databaseserver. This model is commonly used for Internet, intranet and web applications.

• Three-tier applications distribute SQL call formulation across two systems, typically a ‘thin’ clientand its database access server. The database access server sends the completed SQL call to thedatabase server. From a remote DB2 access perspective, formulation of the SQL call is the onlydifference between a two-tier and three-tier application. Since formulation of the SQL call is outsidethe scope of this white paper, we do not discuss this model further.

Two-tier Applications: Middleware on ClientRemote data access applications often consist of a client running an ODBC-enabled application withODBC middleware and connecting via a TCP/IP network to a DB2 server. This is a two-tierapplication where SQL calls are formulated on the client and sent to the server. Figure 1 shows abasic 2-tier application architecture.

Figure 1: Two-Tier Intranet or Internet Application Architecture


The financial application from our introduction falls into this category: both US and Europeanheadquarters could install ODBC or OLE DB middleware on clients and use a query tool, or a customVisual Basic application, to access the common financial database.

However, data passing over the Internet/intranet is open to corruption or unauthorized access. Addinga product that encrypts data and authenticates origin and destination systems provides much-neededdata security. Many Internet and web products use the SSL (Secure Sockets Layer) standard forencryption and authentication. For data access applications, SSL-enabled middleware communicatessecurely with an SSL server, protecting data between the middleware component and the systemwhere the SSL server is installed.

Figure 2 shows a 2-tier intranet application architecture with SSL added. For more information aboutsecurity for data access applications, see section 4, Security.

Figure 2: Two-Tier Intranet Application with SSL Security

Two-tier Applications: Middleware on ServerWhen you have a large number of clients that need to access DB2 data, an effective solution is toinstall a DB2 access middleware on a web or application server. By writing a server application suchas a Java servlet or an ASP script, you allow web browser clients to access data using the serverapplication. Figure 3 shows this approach.

The product and inventory application we discussed earlier falls into this category. An organizationmight use Microsoft IIS as its web server. It already has a number of ASP applications, written usingVBScript. A developer writes a script using VBScript and ADO to access product and inventory datain the DB2 database via OLE DB. The OLE DB middleware is installed on the server where IIS isrunning. Now each web browser client can connect to the DB2 database via the web/OLEDB server.


Figure 3: Data Access Middleware on Server

For this application, data needs to be secure between the browser client and the HTML server, thenbetween the web server and the DB2 server. Most generally available browser/HTML server productsoffer SSL authentication and encryption services. Data traffic between the web server and the DB2server can be made secure by using SSL-enabled middleware and an SSL server on the systemrunning the DB2 server. Section 4, Security, describes SSL in more detail.

Figure 4 shows how SSL fits into this application architecture.

Figure 4: Data Access Middleware on Server with SSL Security

As a further example of data access middleware running on a server, consider the case of a largecorporation that has applications running on multiple server platforms (Mainframes, UNIX, AS/400,Windows NT). For maximum flexibility, the corporation wants to set a platform-independentlanguage and development environment for all applications. Java is now available on most commonplatforms, and an application written in Java for UNIX should also run on an AS/400, or on WindowsNT. Using Java and JDBC, the corporation has a uniform, platform-independent way to access DB2


data. A developer can write a Java servlet to access data that runs on the web or application server,and an HTML page that requests the servlet.

3. Development Options for Web ApplicationsNumerous languages and programming environments for web application development haveemerged. The list includes, but is not limited to:

• HTML, ASP and scripting languages such as JavaScript, JScript and VBScript

• Java applets, servlets and, more recently, Java Server Pages

• CGI and perl or C/C++

HiT Software has seen a couple of these options emerge as the most popular for web applications toaccess DB2. These options have in common that they use SQL standard middleware to access DB2servers.

HTML and VBScript with ADOMany customers have been using PC clients for their database access applications for several years.With the popularity of the World Wide Web and, more recently, intranets, these customers arelooking for solutions that allow them to replace fat client applications with browser-based serverapplications.

If your PC web server is running Microsoft Internet Information Server (IIS), or some other webserver that supports ASP, you can use Microsoft Active Server Pages (ASP) and write yourapplication in VBScript (very similar to Visual Basic) or JScript (closer to Netscape’s originalJavaScript) using ADO and OLE DB to connect to DB2. Figure 5 shows the architecture of such asolution.

Figure 5: Using VBScript with ADO for a Web Data Access Application


Java Servlets/Applets with JDBCWhere flexibility of server and client platforms is critical, it makes sense to write a Java program thatruns on any platform where the Java Virtual Machine (JVM) is available. For web applications, youmight write a Java servlet or a Java applet. A servlet is called from an HTML page and runs on anapplication server or a web server. An applet is downloaded from the web server via an HTML page,and run locally.

For data access web applications, where numerous clients access DB2 simultaneously, it is moreeffective to write a servlet where you can manage the number of concurrent connections. The Javaservlet code and JDBC driver reside on the web server or application server and the browser clientcan request the servlet. Figure 6 shows this approach.

Figure 6: Using JDBC and a Java Servlet for a Web Data Access Application

More recently, Java Server Page (JSP) products have become available. A Java Server Page engineworks with a web server to interpret JSP tags that generate dynamic HTML pages. JSP tags allow youto integrate snippets of Java code that make calls to JDBC to display DB2 data on an HTML page.This option requires less Java programming experience and more flexibility by separating page designand content generation. If your web server supports JSP, consider this option in place of a Javaservlet.

4. SecuritySecuring data traffic is necessary for transmission over public data networks. The components ofpreventive security are:

• access control (controlling and auditing who is accessing data, and the data streams being used—achieved using a firewall),


• authentication (ensuring that users are who they say they are and have appropriate privileges toaccess information—achieved using certificates and user IDs/passwords),

• privacy (ensuring that data is seen only by those intended to see it—achieved by encryption),

• data integrity (ensuring that data is not corrupted by a third party in transit—achieved usingcertificates and public key encryption).

While firewalls provide general access control, authentication and encryption must be handled at theapplication level. The Secure Sockets Layer protocol (SSL) has emerged as the Internet standard forauthentication and encryption. Initially developed by Netscape, the current version of the standard isSSL 3.0. An implementation of SSL is included in almost all web browsers and many other Internetproducts. The standard is flexible enough to support different security algorithms and protocols, anduses the standard X.509 certification.

SSLSSL implements secure communications between servers and clients by authenticating partners andencrypting the communication session. Data integrity is also ensured using certificates andencryption. Typically, data access intranet/Internet applications should include server authenticationto check that data is indeed coming from the expected source, and public key encryption to ensurethat data cannot be “sniffed” or corrupted en route. Alternative options are client authentication andprivate key encryption. Client authentication is not yet commonly used, and user ID/password controlis usually substituted.

Figure 7: Accessing Data from a Query Tool using SSL for Security

Applications that access DB2 databases via intranet or Internet using middleware without SSLsupport, pass data ‘in-the-clear’ over public and/or corporate networks, subjecting data to falsificationand recording by third parties. SQL middleware that supports SSL protects data traffic between themiddleware and the SSL server (typically running on the DB2 server system). Figure 7 shows anapplication where data stored in DB2 is accessed using a query tool over a corporate network.


Figure 8 shows a web application where an HTML page calls a Java servlet, and the servlet accessesconfidential corporate data. The data between the web server and browser is protected by theserver/browser’s inherent security mechanism, but data between the web server and DB2 needs to beprotected using an SSL Server on the DB2 server.

Figure 8: Accessing Data with a Java Servlet using SSL for Security

Authentication

Authenticating the DB2 server ensures that a web application is communicating with the properserver. This is accomplished using certificates. The security administrator generates a servercertificate, signed by a well-known and trusted Certificate Authority (CA). When a client attempts toconnect, the certificate is returned and the client accepts or rejects the certificate.

Encryption

Using an SSL product, you can increase security by encrypting data between the SSL Server andSSL-enabled DB2 access middleware. The SSL 3.0 standard is flexible in that it supports differentimplementations of public key algorithms and cryptography algorithms. SSL products implement asubset of possible public key and cryptography algorithms. Look for DB2 middleware that providesthe best possible security in its public key algorithm and at least 128-bit encryption strength.

5. PerformanceConsider the performance issues below in designing your web database access application. Whilethere are a number of environmental parameters at the DB2 host that can be optimized, we focus onissues at the external application level. Your DB2 administrator should be able to help with DB2optimizations for external application access including initialization settings, communicationbandwidth/servicing, memory allocations, table structures, indexing, stored procedures and so on.


SQL Connections/PoolingWhether you are writing a Java servlet, or using VBScript with ASP, you need to consider how tooptimize multiple concurrent database connections. Applications can take advantage of DB2’scapability to service multiple, simultaneous requests by allocating multiple connections. Pre-allocateddatabase connections at the requesting web server, known as ‘pooling’, allow web applications fasterSQL processing.

Connection pooling is handled differently for OLE DB and ODBC environments. ODBC connectionpooling is activated/deactivated by the Windows ODBC Driver Manager. Therefore, most ODBCdrivers support connection pooling. OLE DB providers can choose to implement specific interfacesfor connection pooling. If connection pooling is available, applications can make use of this feature toenhance performance.

Java and JDBC do not currently provide connection-pooling facilities. You need to handle this inyour application. JDBC 2.0 specifies an extension API that allows a standard API for implementingconnection pooling.

ThreadsMany operating systems and language environments allow applications to invoke multiple processessimultaneously. These ‘threads’ can increase application performance by simultaneously working onmultiple client requests. In general, multi-threaded applications have better global throughput thansingle-threaded applications.

For best performance, find out if your middleware vendor uses appropriate threading models in itsmiddleware products.

Polling/Event AlertsOnce an application has issued SQL to the DB2 server for processing, knowing when to retrieveconfirmation or results is important. Web applications that use ODBC or OLE DB can either poll theDB2 connection for results or have the environment alert them.

Both OLE DB and ODBC provide asynchronous options in their APIs. Asynchronous features permitpolling to verify the state of the request being processed. Alternatively, with OLE DB, usingconnection pointers, the OLE DB provider can generate alerts and send them to the callingapplications.

The JDBC API supports synchronous calls. Applications must send messages and then wait forresults. However, you can support additional application processing using threads in Java.

Application LogicTry to make the best possible use of application logic at the DB2 server. Any stored procedures youuse on the server increase the performance of your application because you are not movingunnecessary unprocessed data across the network.

6. ConclusionDB2 database access from web applications is a rapidly growing concern for IS organizationsworldwide. E-Commerce solutions and the popularity of distributing corporate data over an intranet


are just two areas in which HiT has seen enormous growth in the past year. If your organization isplanning DB2 access via web and Internet, consider carefully:

1. Using a standard interface such as OLE DB, ODBC, or JDBC,

2. Designing an application architecture that supports the number of connections you need and thelevel of security your organization requires,

3. Choosing a simple, flexible, cost-effective development language and environment,

4. Designing and optimizing your application for best performance in heavy network traffic.


CopyrightNo part of this white paper may be reproduced or transmitted in any form or by any means, electronicor mechanical, for any purpose, without the express written permission of HiT Software, Inc. Underlaw, copying includes translating into another language or format.

1994-1999 HiT Software, Inc. All rights reserved.

Printed in the United States of America.

DisclaimerInformation in this document is subject to change without notice. Although efforts have been made toensure the accuracy of this document, HiT Software, Inc. assumes no responsibility for damagesincurred directly or indirectly from errors or omissions.

TrademarksHiT Software is a trademark of HiT Software, Inc. Java and all Java-based marks are trademarks orregistered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All other marks areused for the benefit of their respective owners and HiT Software, Inc. disclaims any interest in suchmarks.

Contact InformationHit Software, Inc.4020 Moorpark Ave, Suite 100San Jose, CA 95117

Phone: (408) 345 4001Fax: (408) 345 4899Email: [email protected] site: http://www.hit.com

exploring db2 data access via web and...

Documents