Interfacing DB2 to Web Applications


Published on

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Interfacing DB2 to Web Applications

  1. 1. 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 ODBC OLE DB Java/JDBC 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 4. Security SSL Authentication Public Key Encryption 5. Performance SQL Connections/Pooling Threads Polling/Event Alerts Application Logic 6. Conclusion Exploring DB2 DataAccess via Web and Internet 1
  2. 2. 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 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
  3. 3. 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 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- 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 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 environment. JDBC 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 server. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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: • 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 to access DB2. These options have in common that they use SQL standard middleware to access DB2 servers. 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 applications. 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 JavaScript) using ADO and OLE DB to connect to DB2. Figure 5 shows the architecture of such a solution. Figure 5: Using VBScript with ADO for a Web Data Access Application Exploring DB2 DataAccess via Web and Internet 7
  8. 8. 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 servlet. 4. Security 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
  9. 9. • 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 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
  10. 10. 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 Authentication 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. Encryption 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. 5. Performance 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
  11. 11. SQL Connections/Pooling 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 SQL processing. 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 enhance performance. 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 connection pooling. Threads 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 single-threaded applications. For best performance, find out if your middleware vendor uses appropriate threading models in its middleware products. Polling/Event Alerts 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 applications. 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. Application Logic 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. 6. Conclusion 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
  12. 12. 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
  13. 13. Copyright 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. Disclaimer 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. Trademarks 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 marks. Contact Information Hit Software, Inc. 4020 Moorpark Ave, Suite 100 San Jose, CA 95117 Phone: (408) 345 4001 Fax: (408) 345 4899 Email: Web site: Exploring DB2 DataAccess via Web and Internet 13