Interfacing DB2 to Web ApplicationsDocument Transcript
Exploring DB2 Data Access via Web and Internet
A HiT Software White Paper
In an era where data access is taking off in new directions
with public web applications and more private intranet use,
HiT Software looks at the technology available and the
issues that face DB2 data access application developers.
1. DB2 SQL Interfaces for Remote Data Access
2. Application Architectures
What is a Web Application Anyway?
Client Server Data Access Models
2-Tier Applications: Middleware on Client
2-Tier Applications: Middleware on Server
3. Development Options for Web Applications
HTML and VBScript with ADO
Java servlets/applets with JDBC
Public Key Encryption
Exploring DB2 DataAccess via Web and Internet 1
Over the past year, many of our customers have been asking us for advice on designing applications
that access DB2 using the World Wide Web, or via Internet/intranet. Customers are either considering
applications to run in Microsoft Windows environments, or trying to remain platform independent
by using Java. This white paper addresses the core issues that project managers and developers face
in 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 that
accesses product and inventory data stored in DB2 at corporate headquarters. The organization
wants a web application to accomplish this.
• Financial Application: US and European company headquarters need to access financial data
stored in DB2, but the IS team is concerned about data security.
• Multi-platform application: A large corporation with applications running on multiple server
platforms (Mainframes, UNIX, AS/400, Windows NT) wants to use a single standard
development 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/intranet
applications for DB2 access, we review some of the software that is currently used for accessing data
stored in DB2. This type of software is often called “middleware”.
1. DB2 SQL Interfaces for Remote Data Access
Standard interfaces like ODBC, JDBC and OLE DB, are available for accessing SQL databases from
external applications. Using a standard interface allows you to purchase “off-the-shelf” products for
commonly used databases and platforms instead of developing proprietary applications. Standards
speed internal development and simplify IS support over the life of applications. For example, to
develop the product and inventory application example in our introduction, you might purchase OLE
DB middleware for DB2 then write a simple script that accesses and displays data from DB2 in a web
page. Without standard middleware, you would need to develop your own connectivity software to
connect 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, Microsoft
has introduced a higher level programming interface known as ADO (ActiveX Data Objects). ADO
provides a set of objects that can be used from programming languages such as Microsoft’s Visual
Basic and C++ or from scripting languages such as VBScript and JScript for connecting to a database
and manipulating data.
OLE DB is the foundation for Microsoft’s current data access architecture. OLE DB provides greater
flexibility over ODBC in that it allows access to non-relational data in addition to data stored in
relational databases such as DB2. It presents an object-oriented interface for generic data access. OLE
DB is based on the Microsoft Component Object Model (COM) architecture for application
components. Third party developers, such as HiT, have created OLE DB middleware that manages
the lower level, procedural, database connectivity state management.
HiT Software, September 1999 2
To implement an application using OLE DB, you typically use ADO methods and properties to call
the OLE DB interface. ADO provides a high-level interface that can easily be used from within C++,
Visual Basic, VBScript and so on.
ODBC (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/IEC
for database access and uses SQL as its database access language. Although Microsoft and others
have developed higher level interfaces over ODBC, it is fundamentally a low-level, procedural, state-
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 and
DB2/400. To use an ODBC driver, you first define a data source (a set of parameters to connect to a
specific DB2 database using a specific network connection). Your application can then connect to a
DB2 server using the ODBC Manager, which calls a database-specific ODBC driver in the Windows
In the Java world, JDBC offers a set of classes for accessing relational databases from Java. Like
ODBC, it is based on the specifications from X/Open and ISO/IEC for database access and uses SQL
as its database access language.
The JDBC class library provides methods that mirror the ODBC API. There are several types of
JDBC middleware, including a JDBC-to-ODBC bridge (Type 1), and direct JDBC connectivity to the
relational database (Type 4). HiT offers type 4 JDBC drivers that allow you to connect directly to
DB2 or DB2/400 without intermediary ODBC middleware.
2. Application Architectures
Let’s look at the most commonly used architectures for database access applications in the context of
the 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 use
some crucial terms:
A web application is accessed via an HTML page from a web browser such as Netscape Navigator
or Microsoft Internet Explorer. The web application usually runs on a web server or application
An Internet application uses the public networks to communicate information or distribute
application logic. Internet applications do not necessarily use a web browser as their client. Web
applications 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 middleware
to connect to a DB2/400 database server via a TCP/IP connection.
Exploring DB2 DataAccess via Web and Internet 3
An intranet application uses a private network, secured by a firewall or other access-limiting
technology, 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, the
term intranet is synonymous with an organization-wide web site, which probably also has a number
of web applications. For the purposes of this paper, an intranet application is a type of web
application. A product and inventory application that displays data from the corporate database in an
HTML page for sales offices across the country, is both an intranet (private network) and web (runs
in a browser) application.
Client-Server Data Access Models
Remote 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 database
server. This model is commonly used for Internet, intranet and web applications.
• Three-tier applications distribute SQL call formulation across two systems, typically a ‘thin’ client
and its database access server. The database access server sends the completed SQL call to the
database server. From a remote DB2 access perspective, formulation of the SQL call is the only
difference between a two-tier and three-tier application. Since formulation of the SQL call is outside
the scope of this white paper, we do not discuss this model further.
Two-tier Applications: Middleware on Client
Remote data access applications often consist of a client running an ODBC-enabled application with
ODBC middleware and connecting via a TCP/IP network to a DB2 server. This is a two-tier
application where SQL calls are formulated on the client and sent to the server. Figure 1 shows a
basic 2-tier application architecture.
Figure 1: Two-Tier Intranet or Internet Application Architecture
HiT Software, September 1999 4
The financial application from our introduction falls into this category: both US and European
headquarters could install ODBC or OLE DB middleware on clients and use a query tool, or a custom
Visual Basic application, to access the common financial database.
However, data passing over the Internet/intranet is open to corruption or unauthorized access. Adding
a product that encrypts data and authenticates origin and destination systems provides much-needed
data security. Many Internet and web products use the SSL (Secure Sockets Layer) standard for
encryption and authentication. For data access applications, SSL-enabled middleware communicates
securely with an SSL server, protecting data between the middleware component and the system
where the SSL server is installed.
Figure 2 shows a 2-tier intranet application architecture with SSL added. For more information about
security for data access applications, see section 4, Security.
Figure 2: Two-Tier Intranet Application with SSL Security
Two-tier Applications: Middleware on Server
When you have a large number of clients that need to access DB2 data, an effective solution is to
install a DB2 access middleware on a web or application server. By writing a server application such
as a Java servlet or an ASP script, you allow web browser clients to access data using the server
application. Figure 3 shows this approach.
The product and inventory application we discussed earlier falls into this category. An organization
might use Microsoft IIS as its web server. It already has a number of ASP applications, written using
VBScript. A developer writes a script using VBScript and ADO to access product and inventory data
in the DB2 database via OLE DB. The OLE DB middleware is installed on the server where IIS is
running. Now each web browser client can connect to the DB2 database via the web/OLEDB server.
Exploring DB2 DataAccess via Web and Internet 5
Figure 3: Data Access Middleware on Server
For this application, data needs to be secure between the browser client and the HTML server, then
between the web server and the DB2 server. Most generally available browser/HTML server products
offer SSL authentication and encryption services. Data traffic between the web server and the DB2
server can be made secure by using SSL-enabled middleware and an SSL server on the system
running 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 large
corporation that has applications running on multiple server platforms (Mainframes, UNIX, AS/400,
Windows NT). For maximum flexibility, the corporation wants to set a platform-independent
language and development environment for all applications. Java is now available on most common
platforms, and an application written in Java for UNIX should also run on an AS/400, or on Windows
NT. Using Java and JDBC, the corporation has a uniform, platform-independent way to access DB2
HiT Software, September 1999 6
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 Applications
Numerous languages and programming environments for web application development have
emerged. The list includes, but is not limited to:
• 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 to
access DB2. These options have in common that they use SQL standard middleware to access DB2
HTML and VBScript with ADO
Many 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 are
looking for solutions that allow them to replace fat client applications with browser-based server
If your PC web server is running Microsoft Internet Information Server (IIS), or some other web
server that supports ASP, you can use Microsoft Active Server Pages (ASP) and write your
application in VBScript (very similar to Visual Basic) or JScript (closer to Netscape’s original
Figure 5: Using VBScript with ADO for a Web Data Access Application
Exploring DB2 DataAccess via Web and Internet 7
Java Servlets/Applets with JDBC
Where flexibility of server and client platforms is critical, it makes sense to write a Java program that
runs on any platform where the Java Virtual Machine (JVM) is available. For web applications, you
might write a Java servlet or a Java applet. A servlet is called from an HTML page and runs on an
application 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 more
effective to write a servlet where you can manage the number of concurrent connections. The Java
servlet code and JDBC driver reside on the web server or application server and the browser client
can 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 engine
works with a web server to interpret JSP tags that generate dynamic HTML pages. JSP tags allow you
to 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 design
and content generation. If your web server supports JSP, consider this option in place of a Java
Securing data traffic is necessary for transmission over public data networks. The components of
preventive security are:
• access control (controlling and auditing who is accessing data, and the data streams being used—
achieved using a firewall),
HiT Software, September 1999 8
• authentication (ensuring that users are who they say they are and have appropriate privileges to
access 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 using
certificates and public key encryption).
While firewalls provide general access control, authentication and encryption must be handled at the
application level. The Secure Sockets Layer protocol (SSL) has emerged as the Internet standard for
authentication and encryption. Initially developed by Netscape, the current version of the standard is
SSL 3.0. An implementation of SSL is included in almost all web browsers and many other Internet
products. The standard is flexible enough to support different security algorithms and protocols, and
uses the standard X.509 certification.
SSL implements secure communications between servers and clients by authenticating partners and
encrypting the communication session. Data integrity is also ensured using certificates and
encryption. Typically, data access intranet/Internet applications should include server authentication
to check that data is indeed coming from the expected source, and public key encryption to ensure
that data cannot be “sniffed” or corrupted en route. Alternative options are client authentication and
private key encryption. Client authentication is not yet commonly used, and user ID/password control
is 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 SSL
support, pass data ‘in-the-clear’ over public and/or corporate networks, subjecting data to falsification
and recording by third parties. SQL middleware that supports SSL protects data traffic between the
middleware and the SSL server (typically running on the DB2 server system). Figure 7 shows an
application where data stored in DB2 is accessed using a query tool over a corporate network.
Exploring DB2 DataAccess via Web and Internet 9
Figure 8 shows a web application where an HTML page calls a Java servlet, and the servlet accesses
confidential corporate data. The data between the web server and browser is protected by the
server/browser’s inherent security mechanism, but data between the web server and DB2 needs to be
protected using an SSL Server on the DB2 server.
Figure 8: Accessing Data with a Java Servlet using SSL for Security
Authenticating the DB2 server ensures that a web application is communicating with the proper
server. This is accomplished using certificates. The security administrator generates a server
certificate, signed by a well-known and trusted Certificate Authority (CA). When a client attempts to
connect, the certificate is returned and the client accepts or rejects the certificate.
Using an SSL product, you can increase security by encrypting data between the SSL Server and
SSL-enabled DB2 access middleware. The SSL 3.0 standard is flexible in that it supports different
implementations of public key algorithms and cryptography algorithms. SSL products implement a
subset of possible public key and cryptography algorithms. Look for DB2 middleware that provides
the best possible security in its public key algorithm and at least 128-bit encryption strength.
Consider the performance issues below in designing your web database access application. While
there are a number of environmental parameters at the DB2 host that can be optimized, we focus on
issues at the external application level. Your DB2 administrator should be able to help with DB2
optimizations for external application access including initialization settings, communication
bandwidth/servicing, memory allocations, table structures, indexing, stored procedures and so on.
HiT Software, September 1999 10
Whether you are writing a Java servlet, or using VBScript with ASP, you need to consider how to
optimize multiple concurrent database connections. Applications can take advantage of DB2’s
capability to service multiple, simultaneous requests by allocating multiple connections. Pre-allocated
database connections at the requesting web server, known as ‘pooling’, allow web applications faster
Connection pooling is handled differently for OLE DB and ODBC environments. ODBC connection
pooling is activated/deactivated by the Windows ODBC Driver Manager. Therefore, most ODBC
drivers support connection pooling. OLE DB providers can choose to implement specific interfaces
for connection pooling. If connection pooling is available, applications can make use of this feature to
Java and JDBC do not currently provide connection-pooling facilities. You need to handle this in
your application. JDBC 2.0 specifies an extension API that allows a standard API for implementing
Many operating systems and language environments allow applications to invoke multiple processes
simultaneously. These ‘threads’ can increase application performance by simultaneously working on
multiple client requests. In general, multi-threaded applications have better global throughput than
For best performance, find out if your middleware vendor uses appropriate threading models in its
Once an application has issued SQL to the DB2 server for processing, knowing when to retrieve
confirmation or results is important. Web applications that use ODBC or OLE DB can either poll the
DB2 connection for results or have the environment alert them.
Both OLE DB and ODBC provide asynchronous options in their APIs. Asynchronous features permit
polling to verify the state of the request being processed. Alternatively, with OLE DB, using
connection pointers, the OLE DB provider can generate alerts and send them to the calling
The JDBC API supports synchronous calls. Applications must send messages and then wait for
results. However, you can support additional application processing using threads in Java.
Try to make the best possible use of application logic at the DB2 server. Any stored procedures you
use on the server increase the performance of your application because you are not moving
unnecessary unprocessed data across the network.
DB2 database access from web applications is a rapidly growing concern for IS organizations
worldwide. E-Commerce solutions and the popularity of distributing corporate data over an intranet
Exploring DB2 DataAccess via Web and Internet 11
are just two areas in which HiT has seen enormous growth in the past year. If your organization is
planning 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 the
level 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.
HiT Software, September 1999 12
No part of this white paper may be reproduced or transmitted in any form or by any means, electronic
or mechanical, for any purpose, without the express written permission of HiT Software, Inc. Under
law, copying includes translating into another language or format.
1994-1999 HiT Software, Inc. All rights reserved.
Printed in the United States of America.
Information in this document is subject to change without notice. Although efforts have been made to
ensure the accuracy of this document, HiT Software, Inc. assumes no responsibility for damages
incurred directly or indirectly from errors or omissions.
HiT Software is a trademark of HiT Software, Inc. Java and all Java-based marks are trademarks or
registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All other marks are
used for the benefit of their respective owners and HiT Software, Inc. disclaims any interest in such
Hit Software, Inc.
4020 Moorpark Ave, Suite 100
San Jose, CA 95117
Phone: (408) 345 4001
Fax: (408) 345 4899
Web site: http://www.hit.com
Exploring DB2 DataAccess via Web and Internet 13