Brought to you by EarthWeb
ITKnowledge Logo Login Graphic Click NOW to join Planet IT!
Click NOW to join Planet IT!
ITKnowledge
Search this book:
 
Search the site:
 
EXPERT SEARCH ----- nav

EarthWeb Direct

EarthWeb Direct

EarthWeb sites: other sites

Previous Table of Contents Next


Chapter 9
Design Issues

In This Chapter

This chapter discusses design issues for the Internet and intranet, as well as implementation and platform choices. The issues discussed include:

  Intranet/Internet
  100 percent Java or non-100 percent Java
  Choosing a database management system (DBMS)

Although there are many issues that may be discussed regarding real-world applications for the Internet or the intranet, this chapter focuses on those that are likely to be the most important ones for your current and future projects.

Intranet/Internet

There are many differences between the Internet and an intranet. The main differences are:

  The Internet is “wild.” There are millions of “netizens” on the Internet, all with different interests. Millions of users also means a heavy load on the Internet.
  Many different services are provided on the Internet, each using a dedicated protocol. In some cases, different implementations of the same service are not fully interoperable.
  Content, location, and free access are subject to change on the Internet, especially on the World Wide Web (WWW).
  The number of users within an intranet is usually stable and known. This environment is a trusted environment.
  Services provided on the intranet are clearly identified, documented, allowed or denied, and cached for performance. The most reliable protocols are used and they never conflict.
  Data content, information sources, authors, access, and privileges are better defined on the intranet.

As the foregoing shows, the intranet is a secure environment. The Internet, the network of networks, is not a secure environment. This lack of security engenders a number of problems that may affect Internet services using Java Database Connectivity (JDBC) to connect to corporate databases.

The Number of Simultaneous Users

While the number of simultaneous intranet users is somewhat predictable, it is not possible to determine the number of simultaneous users of a service on the Internet. Some sites record millions of hits a day on their Web pages and their hit-rate changes day after day. Consider an order-entry application used exclusively within an intranet and an online stock exchange information system on the Internet. It is very difficult to estimate the number of visitors interested in watching stock quotes, while it is very easy to locate the employees who will need to access the order-entry system. Among other problems, the following problems may appear on a system not entirely designed for the Internet:

  With too many users logged in at the same time, the database management system is unable to handle more sessions.
  With too many users simultaneously performing heavy queries, the response time is unacceptable.
  Users log in on a per-user basis, are assigned a new nickname, and choose a personal password. There is one database user-identifier per new user. The database may not be able to handle millions of log-in entries in its system tables.

There are solutions to these problems, but they may not be best suited for your purposes. One solution is to replicate the databases.

Replication

Replication allows more users to log in at the same time, while spreading the load on different servers. In such an architecture, multiple sites replicate the data. A Java application can try to connect to one of these replication servers. If it does not succeed, it can try to connect to the next one, continuing until it connects. From a programming viewpoint, the Java application can be implemented using successive try-catch blocks, each passing a different JDBC Uniform Resource Locator (URL) using the DriverManager getConnection() method. Consider these four URLs:

jdbc:dbdrv://www.mydomain.com:8192/db1
jdbc:dbdrv://www2.mydomain.com:8192/db2
jdbc:dbdrv://relay1.mydomain.sf.ca.us/db3
jdbc:dbdrv://relay2.mydomain.sf.ca.us/db4

Assume your enterprise has a fast backbone linking the different sites and database replication occurs real-time. If the successive try-catch blocks are used to try to connect to a data source, there is a greater chance the user will connect to a database and the application will behave independently of the actual data source. It may not work with applets. Some Web browsers do not allow an applet to connect to another server other than the server it came from.

Latency

The Internet is quite crowded today. Even upgrading a provider’s lines every day will not increase its throughput significantly until gigabit backbones become available. As a result, the response time to obtain a connection to a server may be long. The data transfer rate may also be very slow. Like many other Internet services, database servers suffer from this inherent and unpredictable latency. Indeed, the connection context consumes a fair amount of database resources, and the more waiting users on a system, the more load on the database server.

There is only one solution to this problem: keep the database transactions as short as possible. Do not keep an unnecessary connection open. Many users function in a stateless manner, and most of them will probably interrupt their connection by simply switching to another WWW site.

One Login Per Type of Application

Even for services that are customer-customized, it may not be a good idea to assign a different database user ID for each user. A better approach is to assign specific database IDs per group of users or, if possible, a unique database login for the whole application. In other words, it may be feasible to handle as many different user profiles as possible using a few or even a single database login. In the latter case, the application would be responsible for storing in dedicated tables everything that is user-dependent. In many situations a unique application login will suffice.

The reason is that managing thousands of users, changing every day, may be hell for a database administrator. This is not so for a service administrator, so delegate all identification, authentication, and authorization issues to the service administrator. This information will lay in a table along with connection information, and a billing application, for example, could exploit it.

Security Issues

Security issues apply to stand-alone applications, JDBC and untrusted applets, and firewalls.


Previous Table of Contents Next
HomeAbout UsSearchSubscribeAdvertising InfoContact UsFAQs
Use of this site is subject to certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.