Oracle Web Application Programming for PL/SQL Developers: Remote Server Access
This chapter is from the book
This chapter is from the book
This chapter is from the book
Chapter Objectives
After reading this chapter, you will be able to understand:
- Remote vs. Local
- The Server
- Telnet
- Basic UNIX Commands
- Basic Navigation
- Absolute vs. Relative Path and Filenames
- Transferring Files via FTP
Unit 3.1 Working with the Server
Remote vs. Local
For this book's purpose, there are two possible installation configurations: remote and local. A remote configuration uses your computer to access a remote server machine. A local configuration first determines whether you need to access a remote server machine.
You could be working locally, on a computer that has the Oracle database, application server, and client software all installed on the same machine, or you could be working remotely, using your computer to access a remote server machine. If you have installed Oracle9i Personal Edition on your computer, then you have a local installation.
Understand that most real-world databases are housed on a server machine, which is accessed remotely by client machines. If you have a remote configuration, like that often found in a corporate training environment or an educational setting, then you should find the information in this chapter immediately applicable to your work. You may have been granted access to a remote server machine on which you can complete the exercises in this book. In this case, check with the system administrator to see if you have access privileges needed to complete the exercises in this chapter. It is also possible that your company may have a development configuration where the client, Web server, and database server are on one machine, isolated from the rest of the network. This type of configuration is illustrated as you work through the exercises in this book.
The same holds true for Web sites; the majority of Web sites are also housed on server machines (commonly referred to as simply servers), with a connection to the Internet. Web applications, such as the one you build in this book, have many Web pages that are dynamically generated from database procedures, so there is not a great need to store static HTML files on a server. Yet image files can be stored inside the database or they can be stored on a Web server, as can any static HTML pages you wish to use in your application. It depends on how your database is configured. Documents that require a plug-in to view, and any files of other types other than HTML or image that are used in the application, such as Adobe Acrobat files or Word documents that are intended to be downloaded, can be stored on the Web server or in the database. Chapter 13, "Images," illustrates the method for storing and retrieving documents from an Oracle 9i database.
If you do not have access to a remote server machine, then refer to Chapter 2, "Oracle 9iAS," in which you learn that your local machine can be used as the server, the client, and the middleware necessary to complete the exercises in this book. Remember that if you install an Oracle9i database on your own machine, the installation includes a basic Oracle 9iAS. You can store static HTML pages or images in your own computer's file directory, and configure the Oracle HTTP Server component of the Oracle 9iAS to find the files you want. This is done by identifying the directory where your images and HTML files are stored in the Oracle 9iAS, and giving that directory a virtual name, as explained in Chapter 2, "Oracle 9iAS."
The Server
The server is a large file directory that you need to access in order to complete the exercises in this book. You store files there, such as HTML files or image files, that you wish to make accessible to users on the Internet. You must map specific directories on the server machine to virtual directories in the 9iAS so that the correct directories can be accessed, depending on the URL (Uniform Resource Locator) the user supplies.
About 80% of databases are stored on machines that run the UNIX operating system, and are familiarly known as "UNIX boxes." Since databases are also stored on machines running NT, many NT commands, where they differ from UNIX commands, are noted throughout this chapter.
Telnet
Telnet is software that provides a user or developer a way to connect to a server machine. It is a terminal emulator, which means it gives users the ability to log in to a server machine and work on it remotely. When a developer connects to a server via Telnet, the developer begins a Telnet "session" on the server. Telnet allows you to cross platforms, meaning that if you are on a Windows PC, you can Telnet to a UNIX server and vice versa.
Most computers running Windows come with a basic version of Telnet software installed. The quickest way to begin a Telnet session is to go to the Start menu and choose "Run…." You are asked to "Type the name of a program, folder, or document, and Windows opens it for you." Type the word "telnet" and click OK. A window should pop up that has the word "Telnet" in the title bar.
Once you have successfully invoked a Telnet session, the next step is to connect to a server. No matter what version of Telnet software you use, you must know three things ahead of time in order to be able to successfully connect to a remote server—the name of the server, a login ID, and a password. If you are going to be connecting to a server and working there, chances are the system administrator knows that you are going to be doing this, and has provided you with the name of the machine and a login ID and password. A sample server name might be server4.virgil.com, where server4 is the name of the machine on the virgil network. Some people prefer to call a machine by its numeric IP address, such as 111.22.33.44.
The method you use to connect to the server depends on the kind of Telnet software installed on your machine. If your Telnet window has a prompt, you can enter the words "open server4.virgil.com" to open a connection. If your version of Telnet does not have a prompt, then look on the menu bar for an item called "Connect." This is probably the first item on the menu bar. Click on Connect and you are provided with a place to enter the server name. The host name is another term for server name—the server you are connecting to hosts your guest connection.
You are then prompted for a login name (ID) and password. Enter the login name and password provided by your system administrator. Once you are connected, you should see a $ prompt, or possibly a % or # prompt. This is somewhat anticlimactic. However, be assured that you are connected. You may also see a list of environment or user settings, or a short message of greeting that was configured by the system administrator.
Basic UNIX Commands
Once you have connected to the server, you need to know how to navigate around the directory structure of the server and handle your files. You accomplish this using basic UNIX commands.
The first step in navigation is to know where you are. When a user logs in, the user will always begin from the same initial directory, called the home directory. This home directory is determined when a user account is created by the system administrator, and is included in the configuration for each user who will be accessing the server. Different users are usually assigned different home directories. In order to find out which directory you are presently in, type the UNIX command pwd. This will print your present working directory. You see different values for pwd as you travel through the file system. In NT, your prompt is always inclusive of the present working directory.
To see a list of all of the contents of the present directory, type ls and enter. The names of all of the files and subdirectories in the current directory will be listed. To obtain a list with more details, type ls -l and press the Enter key. The -l after the ls is called an argument. Supplying arguments after UNIX commands is a way to supply more specifics about what you want the UNIX command to accomplish. Arguments are listed after the command, and the syntax is a minus sign followed by one or more letters that indicate what options you'd like. The -l is a valid argument for the ls command, which tells the server to display a longer description of each file and subdirectory.
As you navigate through directories, pwd and ls -l (or simply reading the prompt itself and typing dir in NT) will probably be the commands you use most often, to find out where you are and what is in the directory where you are.
If the ls -l command returns more file and directory names than fit on the screen, enter ls -l | more instead. The screen fills one page, so to speak, with data, and then UNIX waits for you to press a key before displaying another screen page of data. The same is accomplished in NT by including /p after the command, to indicate that the computer should pause and wait for a key to be pressed before displaying more information.
Take a look at the results from ls -l in more detail. Here is some sample output from running the ls -l command in UNIX:
-rw-r--r-- 1 bobo devel 118253 Jul 17 12:05 1stlog1.wav drwxr-xr-x 2 bobo devel 4096 Nov 14 18:30 gfx -rw-r--r-- 1 bobo devel 1036 Nov 14 19:04 index.html -rw-r--r-- 1 bobo devel 973 Nov 14 18:32 index_old.html -rw-r--r-- 1 bobo devel 17451 Sep 5 00:35 syllabus.html -rw-r----- 1 bobo devel 0 May 24 2001 test.htm
The first column shows the file permissions, which are discussed in more detail later. Note that the first character is either a "d" or a dash. You could also see an "l" here (indicating a symbolic link). A "d" in the first spot indicates a directory. The second column (denoted here by a list of numbers) shows the number of links to a file. The third column shows the owner of this file or directory; in this case, the owner is bobo. The owner is the user who has control over the file. The fourth column shows the group that the user bobo belongs to; in this case, devel. The fifth column shows the size of the file in bytes. The sixth column shows the date and time the file was created or last changed. Finally, the name of the file is displayed in the seventh column.
One of the most important columns to pay attention to when developing Web applications or documents is the first column. It indicates what permissions its owner has granted on the file. These permissions are powerful; they determine how much access users can have to each file, and what users can do with each file. Through permissions, files are made accessible on the Internet, or blocked from being accessible on the Internet, so it is important to understand and check file permissions, and to apply them carefully.
Table 3.1. File Permissions
| Permission | Character | Number Equivalent |
| read | r | 4 |
| write | w | 2 |
| execute | x | 1 |
| none | - | 0 |
| (Note that a hyphen symbol, "-", is the character displayed when none of the other three permissions is granted for a file.) | ||
There are three types of file permissions that can be granted on a file or directory. Table 3.1 outlines these three types. Though "none" is listed in Table 3.1 in the "Permission" column, it is not a permission type, per se. Rather, it is the option available to you if you do not choose to enter one of the other three.
There are four levels of users when granting permissions, however. These four levels are outlined in Table 3.2.
Listed in Table 3.3 are some examples of different types of granted permissions. Take a look at the permissions listings in the left column. After the first character, which indicates whether the current file is actually a directory or just a file, the other nine characters indicate the permissions for each type of user. The second, third, and fourth characters show permissions at the user level. The next three characters show permissions at the group level, and the last three characters denote permissions for everyone else, the other level. These last three characters govern whether the public can read, write, or execute a file. These permissions examples provide a description of what each set of permissions permits, and to whom.
Table 3.2. Levels of Users
| Level | Letter | Who is This |
| user | u | The owner of the file, not just any user |
| group | g | A group of users—users can be associated with groups by the system administrator |
| other | o | Anyone who is not already included in either of the first two levels |
| all | a | All users |
Table 3.3. Examples of File Permissions
| Sample Permissions | Access |
| -rwxrwxrwx | The user, group, and everyone else can read, write, and execute |
| -rwxr-xr-x | Only the owner can read, write, and execute. Everyone else can only read and execute. |
| -rwxrwx-- | Only the owner and group can read and execute. |
Remember that file permissions determine whether a file is accessible to the public on the Web. In the examples above, the public would be able to access files with the first two permission sets, but not the third set of permissions. The first file would also be writeable, that is, updateable, by the public.
Always check file permissions to make sure that they are correct for each file. Files that are not intended for public access on the Web should not be made accessible to the public. When it is time to "publish" a file, the permissions for all users must be changed to allow others to view the file.
Each set of permissions has a three-digit numeric equivalent. For example, the permissions -rwxr-xr-x are also known as 755. How is this determined? Each digit corresponds to one of the three levels of permissions; the three digits indicate the permissions for the user, group, and other levels, respectively. The number for each level is arrived at by adding the numeric equivalents for each level. As listed above, each permission—read, write, and execute—has a numeric equivalent. These numbers are added to arrive at each digit. In 755, the 7 in the user slot means the user can read (4), write (2), and execute (1) the file; 4 + 2 + 1 = 7 and 7 is used. The second slot has the value 5, meaning that at the group level, only read (4) and execute (1) permissions have been granted; 4 + 1 = 5, so 5 is used. The third digit is also 5, meaning that the permissions at the "other" level are the same as they are at the group level; everyone else has the ability to read (4) and execute (1), and 4 + 1 = 5, so 5 is used again.
The UNIX command to change a file's permissions, or "change mode," is chmod.
The 755 indicates what the file permissions should be for the file "myfile". A 755 is a popular choice for a file that is intended to be accessed by the public, since it prevents anyone but the owner from updating the file, while allowing everyone else to access it.
Be extremely careful not to make files accessible that should not be. To remove access from a level, use a zero (0) for the corresponding digit. This example gives full rights on the file to the owner, but revokes access from everyone else:
chmod 700 myfile
NT users, note that you may change permissions on your files using basic Windows Explorer functionality.
Basic Navigation
Now that you know how to determine which directory you are in and what its contents are, how can you navigate? The cd command lets you change directories in both UNIX and NT. Table 3.4 lists some basic navigation commands you can use for moving up and down in a directory tree.
Table 3.5 lists some additional commands you can use in a Telnet session on the server to manage your files.
The cp, or copy, command is particularly useful for making backup copies of documents before changing them or creating new versions of them. The convention is to keep the same name for the file, but append to the name the date that you are changing the file. If you are creating a backup file for myfile on March 1, 2002, you might create a copy called myfile20020301.
Table 3.4. Basic Navigation Commands
| Command | Description |
| cd directoryname | Navigates downward in the directory tree to the subdirectory "directoryname." If you are unable to move to that directory, use ls -l to see if you are using a valid subdirectory name. |
| cd .. | Navigates upward one level in the directory tree. |
| cd | cd without anything after it takes you to your own home directory (NOTE: In NT, entering this command by itself will simply print your current working directory onto the screen.) |
| cd /mydirectory | The forward slash means you want to skip to the highest level in the directory tree, start from there, and go to the subdirectory "mydirectory." This is the equivalent of typing cd .. repeatedly until you are at the topmost directory, and then typing cd mydirectory. |
Table 3.5. Additional Commands for File Management and Manipulation
| Command Example | Description |
| rm myfile | Deletes or removes the file called "myfile." |
| rm –i | Prompts the user before the system deletes the file (as a safety measure). |
| mkdir mydirectory | Creates a directory called "mydirectory." |
| rmdir mydirectory | Deletes or removes the directory called "mydirectory." |
| cp myfile mynewfile | Copies the file "myfile"; the copy is called "mynewfile" and is located in the same directory as the original "myfile" file. |
| cp myfile /home/app/mynewfile | Copies the file "myfile"; the copy is called "mynewfile" and is located in the /home/app/ directory. The cp command can copy files to another directory. |
| mv myfile mynewfile | Moves the file, or renames it. In this example, the file will be moved from its present location under the name "myfile" to the same directory under the name "mynewfile." This effectively renames the file. This is the way to rename a file in UNIX. |
| mv myfile /home/app/ | Moves the file "myfile" to the directory /home/app/. In moving the file, it is not also renamed, because no new name was specified. |
Absolute vs. Relative Path and Filenames
A full pathname, a pathname starting at the root or topmost directory, is also known as the absolute pathname. The pathname starting from where you are currently, wherever that may be, is known as the relative pathname. Consider the following directory structure as an example. classnotes is the topmost directory. homework is a subdirectory of classnotes, and homework_one is a subdirectory of homework.
Docroot>
classnotes
homework
homework_one
Absolute Paths
An absolute path contains the complete URL (Uniform Resource Locator) for a file. A URL typically consists of four parts: the protocol, the server/domain, the path directory, any subdirectories, and finally, the actual file name itself. An example of an absolute path listing is http://www.server4.virgil.edu/classnotes/homework/homework_one/hw1Answers.htm.
An absolute path is the same as the path in the address window of a browser (this address window is also referred to as a location). Absolute paths are fine for linking to files outside of your Web site. However, using the absolute path to link to other files within your Web site has disadvantages.
Say that a Web site uses absolute paths for all of its links and images. This prevents the Web site from being portable. The result is the site's files cannot be moved to another server without having to change each and every file path to reflect the new address. This really becomes an issue if there are different environments. A typical network infrastructure has multiple environments, each on its own server machine. These include:
- a development environment where the coding is done
- a testing environment where user-acceptance testing, among other tests, is done
- a production environment where the Web site will "go live" (be made available for its intended users)
Using absolute paths requires that the links be changed each time the site is moved to the next environment on the next machine. How can you avoid this and at the same time make a Web site portable? The answer is to use relative paths.
Relative Paths
It's preferable to use relative pathnames when linking to documents within your own Web site. There are two types of relative paths: root-relative paths and document-relative paths.
A relative path uses as its starting point either (1) the Web site's docroot, or (2) the location of the page that holds the relative path. Using this starting point, the browser is able to find a file.
Root-Relative Paths
A root-relative path always starts with '/' (a forward slash) and does not include the protocol and domain names. The starting point is the Web server's docroot based on the current document.
In this example the search begins in the docroot of the Web server on which the current page resides, or www.server4.virgil.edu. To reference the file, hw1Answers.htm, simply start at the topmost directory and drill down to the directory where the file resides.
Document-Relative Paths
A document-relative path does not begin with '/' (a forward slash) and, like a root-relative path, does not include the protocol and domain. The starting point is the current document displayed in the browser. Thus, these paths are relative to the document.
To reference a file in the same directory as the current browser document, just reference the name of the file:
Hw1Answers.htm
To reference a file located in a directory below the current page, reference the subdirectory and file:
subdirectory/file.htm
To reference a file located in a directory above the current page, type in two sequential periods, "..". If the current document is located in the directory "homework_one" and you want to reference a document in "homework", then the path would be written like this:
../file.htm
Add an extra set of ".." for each directory that you need to go up. For example, to reference a file located two directories up from the current document, you could write the following:
../../file.gif
In this case, navigating two directories up from the "homework_one" directory puts you in the "classnotes" directory.
Root-Relative versus Document-Relative Paths
Now that you understand that a relative path is preferable to an absolute path for linking to files within your Web site, which type of relative path should you use: root-relative or document-relative paths?
It depends. Both give you the desired portability. If a site has an images directory that will not be moved, then a root-relative path is preferable for such a directory since the path to the images contained in it will always be valid regardless if the Web document (that references this directory) itself is moved to another directory. Document-relative paths, however, tend to be shorter, and may be preferable for that reason alone. Both types of relative paths can become invalid if a file is moved. So, the choice of whether to use root-relative or document-relative paths depends on the particular Web site and Web developer.
Transferring Files via FTP
There are two options for delivering static files with Oracle 9iAS. You can store the files in the database or you can deliver them using the Apache Web server component. In the latter case, you are delivering, or serving, files from the file system of the server. When you have files that you want to make accessible on the Web, you must place them on the server. Files can be transferred to a remote server using FTP. FTP stands for File Transfer Protocol, which is an apt description of what it does.
You also use FTP to retrieve files for editing. This book does not discuss how to edit files directly on the server, since the editing tools available within the UNIX and NT environments (save for the book's discussion concerning Notepad) are outside the scope of this book. However, it is just as effective to transfer files from a server to a local machine, edit the files locally using Notepad or another plain text editor, and then transfer the edited file back to the server; in fact, there are developers who prefer to work this way.
To use FTP, you need the same three pieces of information you need when connecting to the server: the server name, a login ID, and a password for that machine.
You also need to know what type of transfer you want to accomplish. There are two modes for transferring files: binary and ASCII. The type of the file being transferred determines which mode should be used. ASCII is used strictly for plain text files only, such as files you open and read in Notepad without affecting the content. All other files, including word processing documents, images, and .pdf files, must be transferred in binary mode. If you are not certain what type of file you have, try opening it in Notepad and see if the content is displayed correctly. If not, use binary mode.
You use text commands to transfer files via FTP. Be aware that products exist that offer a graphical interface for using FTP, such as WS_FTP and Hummingbird. These can be easier to use if you find yourself transferring large numbers of files often.
To transfer files, you must first access a "command-line prompt" in MS-DOS. Go to the Start menu and choose "Run…" off the menu popup. Type cmd or command in the space provided and click OK. A window should pop up with a prompt such as C:\WINDOWS>.
The FTP utility can connect a Windows PC to a UNIX server, or a Windows PC to a Windows server. The example used here illustrates a Windows PC connection to a UNIX server. At the prompt, type ftp followed by the name of the server you wish to access.
FOR EXAMPLE
C:\WINDOWS> ftp server4.virgil.edu
You will be prompted to supply your user name and password. If successful, you see an ftp> prompt. To view a list of ftp commands available at this prompt, type help followed by the Enter key. To view help for a specific command, such as put, type help followed by the command, such as help put.
The pwd, ls, and cd commands introduced earlier in this chapter are also available at the ftp> prompt, so use them to navigate to the directory where the file should be placed. Be sure you are in the directory where you want to place the document before you proceed.
Set the transfer mode that you want, using either of the two commands, binary or ascii. Below is an example of switching to binary, and then to ASCII mode.
To transfer the file, use the put command and the path and filename for the file you are transferring. If you stored a file in C:\TEMP\DOCUMENTS called NEWPAGE.HTM, and you want to transfer it, you enter the following:
ftp> put c:\temp\documents\newpage.htm
Following are sample messages received after issuing the put command:
200 PORT command successful. 150 Opening ASCII mode data connection for NEWPAGE.HTM. 226 Transfer complete. ftp: 83 bytes sent in 0.6Seconds 1.38Kbytes/sec. ftp>
You can also retrieve a file from the server to work with locally. To accomplish this you use the get command:
ftp> get myserverfile.htm
The myserverfile.htm file is retrieved, and placed in the directory on your file system that you started from when you issued the ftp command.
If you wish to transfer many files at once, you can use different versions of the get and put commands: mget and mput. Since these are commands for many files, instead of specifying one file, use the asterisk (*) as a "wildcard" character. Using *.* indicates that all files should be transferred. Here is an example of mput that will put all files with the extension .htm on the server:
ftp>mput c:\temp\documents\*.htm
Here is the command with sample output. Note that there are two files, apple.htm and orange.htm, and that the ftp program prompts the user to supply a "y" or an "n" for each file before transferring it. The first file is confirmed for transfer while the second is not:
ftp>mput c:\temp\documents\*.htm mput c:\temp\documents\apple.htm? y 200 PORT command successful. 150 Opening ASCII mode data connection for orange.htm 226 Transfer complete. ftp: 7330 bytes sent in 0.6Seconds 1.38Kbytes/sec. mput c:\temp\documents\orange.htm? n ftp>
The mget command makes similar use of the asterisk as a wildcard character. Here is a sample of the mget command that retrieves all types of files from the server that begin with an "a":
ftp>mget a*.* 200 Type set to A. mget apple.htm? y 200 PORT command successful. 150 Opening ASCII mode data connection for apple.htm(11 bytes). 226 Transfer complete. ftp: 7330 bytes sent in 0.6Seconds 1.38Kbytes/sec. mget artichoke.pdf? n ftp>
Keep in mind whether the current transfer type is binary or ASCII. In the mget example, the transfer type was set to A or ASCII. The second file to be transferred was artichoke.pdf, which is not a plain text file. If the file had been retrieved from the server in ASCII mode, the resulting local file would have been unreadable. It would have to be transferred a second time, with the transfer mode set to binary. Be mindful of the transfer mode whenever you are transferring files. It is particularly easy to overlook the transfer type when working with multiple files, so the way the ftp program prompts the user to confirm transfer of each individual file is extremely helpful here.
Finally, to end the FTP session, type quit or bye and press the Enter key.
Once your files are transferred to the server, remember to connect to the server using Telnet, and check the permissions on the files, changing the permissions as necessary.