Page 1217
Page 1218
Applications on the Web are really applets. These applets are programs, usually written in Java, that are interpreted by the end user 's browser. When you learn to integrate Oracle with applet programming, you can not only create applications to do business on the Web, but you can create intranets , which are companywide Web domains. With the foundation of the applet, you and your company get a de facto standard for front-end graphics and network communication. With Oracle, you can integrate this new standard with the back-end standard of relational databases to make your Web or intranet system an open one.
In the first years of the World Wide Web, HTML was used as basically a Web publishing tool. The initial mission of the Web was to allow researchers to work on projects together, viewing information regardless of what machine it resided on. Once the business world stumbled on the Web and saw its common protocol HTTP and its common front-end language HTML, and, of course, its accessibility to the world, the Web took on the characteristics of a virtual "flea market." Today you can order books, airplane tickets, and even food using the World Wide Web. To do this, Web pages have gone beyond simple publishing features and now run full-fledged dynamic applications that interface with the Web client and software residing behind the Web pages.
A Web application is an application that you place behind your Web page that interfaces with the rest of the world. Most applications that were designed before Web applications resided on a computer that only a given set of users could access. Not so with the world of Web applications ”this software resides behind your uniform resource locator (URL), your Web address, which is registered with the Internet and can be accessed by anyone on the Internet. This should be the primary criteria for deciding to put an application online: Is your application appropriate for the whole world to see?
With the new advent of intranets, which are mini-Internets that reside within a particular organization, many Web applications are built that do not need to meet that criteria. If you are building a Web application for an intranet, then your criteria should be whether the application is appropriate for anyone on your intranet to see. Regardless of whether you are developing an application for an intranet or the Internet, you must define the user domain.
You must determine the user domain before building an application. The user domain is the complete set of users that might potentially use your Web application.
Consider your user domain before you design your system ”who will be able to use it?
Not only must you determine the user domain, but you also need to determine the way in which these users access your Web application. Accessing the Web via a modem, a T1-line, or an internal cable gives users a different application bandwidth. Table 54.1 shows some of the more common ways that users access a Web application and the bandwidth they will enjoy.
Page 1219
Table 54.1. Common connection methods and their speeds.
Method of Access | User Profile | Bandwidth Measured in Bits per Second (bps) |
Modem | Home PC user or maybe corporate user with remote connection. | 14,400 to 56,000 bps |
ISDN connection | Sophisticated home PC user or organization branch with ISDN line | 128,000 bps |
T1, T3 lines | Corporate wide-area network. Users within an organization with these fast lines in place. | 1,500,000 to 4,500,000 bps |
Cable | Future home NC users hooked up through cable. Private cable lines for corporate intranet users. | 10,000,000 bps |
The application bandwidth for modem users is narrower because data moves at a maximum of 56,000 bps for this type of interface to your Web page. One the other hand, if your organization has laid cable for an intranet within the corporate headquarters, the bandwidth is wide, allowing 10 million bytes to pass through the cable per second.
The user's bandwidth should be the primary consideration in Web application design. If you have a wide bandwidth, using more graphics, sound, or multimedia does not force the user to wait forever to receive your Web page. If the user is a remote PC user hooked up through a modem via his ISP (Internet service provider), you need to design an application that will not send complex Web pages with too much data traveling through a narrow path .
Sometimes you might have many different kinds of users logging on to your system, but it is helpful when defining the user domain if you can narrow the profile. Not only should you know the methods of access for your users, but you also need to get an idea regarding the hardware and operating environments they are running.
In the world of Web programming, you can decide to unload a number of processing burdens on the user community and their client machines as they log in. In the world of the Internet
Page 1220
and intranets, the client is not simply a dumb terminal, but a remote CPU running a browser that can perform much of your application's processing. Some of the things that a client can process are
Designing a Web application is similar to designing any software project. The difficulty in designing an application for the Web is due primarily to the infancy of today's development tools. Web applications are a new concept. There is no clear direction for developers to follow in designing a Web application. Microsoft is forging ahead with its DCOM/ActiveX strategy. The de facto standard is embracing Java/JavaBeans and CORBA/IIOP. Oracle offers the sophisticated Web Application Server, which attempts to unify these and other standards into the Network Computing Architecture (NCA). Although no single approach is the best for everyone, this chapter focuses more on the Java and NCA approach to Web development. These architectures are best suited for an Oracle database and do not mandate that users be on a Microsoft operating system. The code discussed in this chapter is designed to run on any client-side computer.