.com Not Listed in Regional Yahoo? Don’t Despair!

Killer Flow SEO Library
1000 Free Articles

Link to this page

<a href="http://www.killerflow.com/articles/index.html">Killer Flow SEO Library
<br />
1000 Free Articles
</a>

PayDay Loans

Web Programming College

Chapter 1
An Overview of Internet Programming
by Bill Anderson
CONTENTS
A Short History of the Internet l
The TCP/IP Protocol Model
The Network Layer m
The Transport Layer m
The Application Layer m
Telnet m
File Transfer Protocol (FTP) m
Trivial File Transfer Protocol (TFTP) m
Simple Mail Transfer Protocol (SMTP) m
Network News Transfer Protocol (NNTP) m
Gopher Protocol m
HyperText Transfer Protocol m
Multipurpose Internet Mail Extension m
l
LAN Topologies
Ethernet LANs m
Token Ring Topology m
Repeaters, Bridges, and Routers m
l
Internetworking-Linking LANs Together
Point-to-Point Links m
SLIP and PPP m
X.25 Links m
Frame Relay Links m
Integrated Digital Service Network (ISDN) Links m
Asynchronous Transfer Mode Links m
Routing in an Internetwork m
l
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (1 of 27) [4/22/1999 3:57:18 PM]
IP Addresses and Domain Names
What Is an IP Address? m
Special IP Addresses m
Resolving Names to Addresses m
l
The Client/Server Model l
Sockets and Socket APIs l
Applications, Plug-Ins, and Applets l
Summary l
Today, the Internet and intranets are exploding like wildfire. The article, "VISA Moves to Intranet
System," in the January 29, 1996, issue of Information Week states that "two thirds of all large companies
either have an internal Web server installed or are thinking about it, and industry analysts believe that
soon internal Web servers will outnumber external servers by a margin of 10 to 1. Forrester Research
predicts the intranet server business will hit $1 billion by the year 2000." The daily announcements about
new venture agreements, new application products, and new technology validate this prediction. In the
nearly 30 years that I have worked in the computer industry, I cannot remember such an explosive
period.
With all the excitement, one tends to forget that individuals laid the foundation for today's events in the
late 1960s. The next three sections of this chapter look at the history, future, and fundamentals of the
Internet, networks, and intranets. Then we devote four sections to the basics of TCP/IP networking. The
chapter ends with a brief discussion of various applications, plug-ins, and applets.
A Short History of the Internet
Most historical reviews of the Internet imply that networking began with ARPAnet. In a sense, digital
transmission of data began when Samuel B. Morse publicly demonstrated the telegraph in 1844. In 1874,
Thomas Edison invented the idea of multiplexing two signals in each direction over a single wire. With
higher speeds and multiplexing, Edison's teletype replaced Morse's manual system; and a few teletype
installations still exist today.
NOTE
In 1837 both Sir Charles Wheatstone in Great Britain and Samuel B.
Morse in the United States announced their telegraphic inventions.
The early telegraph systems were, in modern terms, point-to-point links. As the industry grew, switching
centers acted as relay stations and paper tape was the medium that the human routers used to relay
information from one link to another. Figure 1.1 illustrates a simple single-layer telegraphic network
configuration. Figure 1.2 shows a more complex multilayered network.
Figure 1.1 : A simple asynchronous network.
Figure 1.2 : A multilayered asynchronous network.
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (2 of 27) [4/22/1999 3:57:18 PM]
The links of these networks were point-to-point asynchronous serial connections. For a paper tape
network, the incoming information was punched on paper tape by high-speed paper tape punches and
was then manually loaded on an outgoing paper tape reader.
Although this activity might seem like ancient history to younger readers, let us put this story into a more
understandable framework. In early 1962, I built my first "computer"-a vacuum tube calculator-and spent
the following summer reading the latest book on designing transistorized computers. At the same time,
Paul Baran and his colleagues at the Rand Corporation were tackling the problem of how to build a
computer network that would survive a nuclear war. Yet when I joined the United States Air Force in
1968, I became an Automatic Digital Network (AUTODIN) programmer. At that time, the network was
only a few years old. In essence, AUTODIN replaced the human routers with computers without
changing the network model of the paper tape network.
The year 1969 was a year of milestones. Not only did NASA place the first astronauts on the moon but
also, and with much less fanfare, Department of Defense's Advanced Research Projects Agency (ARPA)
contracted with Bolt, Baranek, and Newman (BBN) to develop a packet-switched network based on Paul
Baran's ideas. The initial project linked computers at the University of California at Los Angeles
(UCLA), Stanford Research Institute (SRI) in Menlo Park, California, and University of Utah in Salt
Lake City, Nevada. The birth of ARPA is permanently engraved in my mind, because, as a young second
lieutenant, I presented a briefing on the future of the ARPAnet to a group of colonels and generals.
Looking back, my briefing was definitely short on vision. On the other side of the continent from the
ARPAnet action, Brian W. Kernighan and Dennis M. Ritchie brought UNIX to life at Bell Labs (now
Lucent Technologies) in Murray Hills, New Jersey.
Even though message switching was well known, the original ARPAnet provided only three services:
remote login (telnet), file transfer, and remote printing. In 1972, when ARPAnet consisted of 37 sites,
e-mail joined the ranks of ARPAnet services. In October 1972 ARPAnet was demonstrated to the public
at the International Conference on Computer Communications in Washington, D.C. In the following
year, TCP/IP was proposed as a standard for ARPAnet.
The amount of military-related continued to increase on ARPAnet. In 1975 the Defense
Communications Agency (DCA) changed its name to DARPA (Defense Advanced Research Projects
Agency) and took control of ARPAnet. Many non-government organizations wanted to connect to
ARPAnet, but DARPA limited private sector connections to defense-related organizations. This policy
led to the formation of other networks such as BBN's commercial network Telenet.
The year 1975 marked the beginning of the personal computer industry's rapid growth. In February 1975,
about seven months after Altair announced its microcomputer, I purchased an IMSAI 8080 (serial
number 25). In those days when you bought a microcomputer, you received bags of parts that you then
assembled. Assembling a computer was a lot of work, for a simple 8KB memory card required over
1,000 solder connections. Only serious electronic hobbyists, such as those who attended the Home Brew
computer club meetings at the Stanford Linear Accelerator Laboratories on Wednesday nights, built
computers. (I saw a demonstration of Apple I at one of those meetings.) Since that first computer, which
still works, I have changed microcomputers more often than I have changed cars. From their experiences
with the Altair, Paul Allen and Bill Gates founded Microsoft to develop BASIC for the new PC world.
In 1976, four years after the initial public announcement that ARPAnet would use packet-switching
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (3 of 27) [4/22/1999 3:57:18 PM]
technology, telephone companies from around the world through the auspices of CCITT (Consultative
Committee for International Telegraphy and Telephony) announced the X.25 standard. Although both
ARPAnet and X.25 used packet switching, there was a crucial difference in the implementations. As the
precursor of TCP/IP, the ARPAnet protocol was based on the end-to-end principle; that is, only the ends
are trusted and the carrier is considered unreliable (the section on TCP/IP later in this chapter covers this
technology in more detail).
On the other hand, the telephone companies preferred a more controllable protocol. They wanted to build
packet-switched networks that used a trusted carrier, and they (the phone companies) wanted to control
the input of network . Therefore, CCITT based the X.25 protocol on the hop-to-hop principle in
which each hop verified that it received the packet correctly. CCITT also reduced the packet size by
creating virtual circuits.
In contrast to ARPAnet, in which every packet contained enough information to take its own path, with
the X.25 protocol the first packet contains the path information and establishes a virtual circuit. After the
initial packet, every other packet follows the same virtual circuit. Although this optimizes the flow of
over slow links, it means that the connection depends on the continued existence of the virtual
circuit.
CCITT regulated input into the network by enabling transmission only when the sender received a credit
packet, thereby controlling the overall throughout the network. Although X.25 is now a dying
protocol, it played a very important role in the development of enterprise networks.
Therefore, the end-to-end principle of TCP/IP and the hop-to-hop principle of X.25 represent opposing
views of the data transfer process between the source and destination. TCP/IP assumes that the carrier is
unreliable and that every packet takes a different route to the destination, and does not worry about the
amount of flowing through the various paths to the destination. On the other hand, X.25 corrects
errors at every hop to the destination, creates a single virtual path for all packets, and regulates the
amount of a device sends to the X.25 network.
The year 1979 was another milestone year for the future of the Internet. Computer scientists from all over
the world met to establish a research computer network called Usenet. Usenet was a dial-up network
using UUCP (UNIX-to-UNIX copy). It offered Usenet News and mail servers. The mail service required
a user to enter the entire path to the destination machine using the UUCP bang addressing wherein the
names of the different machines were separated by exclamation marks (bangs). Even though I sent mail
on a regular basis, I always had problems getting the address right. Only a few UUCP networks are left
today, but Usenet News continues as NetNews. Also in 1979, Onyx Systems released the first
commercial version of UNIX on a microcomputer. As one of the consultants who worked with Onyx, I
received one of the first machines off the production line, and thus began my UNIX career. I learned
UNIX from a programmer who held to the old-time UNIX rule that if you don't know the answer, look it
up in the source code. The only problem was that the UNIX source code lacked comments, which meant
that I had to become a master at reading sometimes cryptic C code.
The traveler in me took me to a project in Nigeria for the next three years. I met many wonderful people
there, but moving to Nigeria was a major technology shock. I went from delivering messages by e-mail
to delivering messages via a human messenger, because that was the only reliable way to deliver
messages from one site to another. When I had to make one particularly dangerous trip, the local priest
sacrificed a goat in order to protect me from evil spirits. Upon returning to the United States in 1983, I
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (4 of 27) [4/22/1999 3:57:18 PM]
warped back into a world of BITNET (But It's Time Network), CSNET (Computer Science Network),
and many others.
The most crucial event for TCP/IP occurred on January 1, 1983, when TCP/IP became the standard
protocol for ARPAnet, which provided connections to 500 sites. On that day the Internet was born. Since
the late 1970s, many government, research, and academic networks had been using TCP/IP; but with the
final conversion of ARPAnet, the various TCP/IP networks had a protocol that facilitated
internetworking. In the same year, the military part of ARPAnet split off to form MILNET. As the result
of funding from DARPA, the University of California's Berkeley Software Distribution released BSD 4.2
UNIX with a TCP/IP stack. In addition, Novell released NetWare based on the XNS protocol developed
at Xerox Park, Proteon shipped a software base router using the PDP-11, and C++ was transformed from
an idea to a viable language.
During this period, I took a job with a new company called DESTEK to develop the drivers for its new
Ethernet card. As an employee of a true leading-edge company, I finished making some patches to the
drivers in my hotel room the night before the 1983 Comdex show opened. That was the year in which the
idea of building local-area networks (LANs) was new and hot. With the introduction of LANs, the
topology of networks changed from the representation shown in Figure 1.2, which ties legacy systems
together, to that shown in Figure 1.3, which ties LANs together.
Figure 1.3 : A LAN-based model for internetworks.
With the growth in number of organizations connecting to ARPAnet and the increasing number of LANs
connected to ARPAnet, another problem surfaced. TCP/IP routes according to the destination's IP
address. The IP address is a 32-bit number divided into four octets for the sake of human readability.
Whereas computers work with numbers, humans remember names better than numbers. When ARPAnet
was small, systems used the host file (in UNIX the file is /etc/hosts) to resolve names to Internet
Protocol (IP) addresses. The Network Information Center (NIC) maintained the master file, and
individual sites periodically downloaded the file. As the size of the ARPAnet grew, this arrangement
became unmanageable in a fast-growing and dynamic network.
In 1984 the domain name system (DNS) replaced downloading the host file from NIC (the section "IP
Addresses and Domain Names" discusses the relationship between the two in more detail). With the
implementation of DNS, the management of mapping names to addresses moved out to the sites
themselves. During this time I moved to Fortune Systems and took over the project management of a
new token ring product. Part of this new product included adding the Berkeley sockets technology to
ForPro (Fortune's version of UNIX). With the introduction of Sun Microsystem's UNIX-based
workstations in the same year, all the pieces of the technology needed to develop the Internet of today
were in place.
For the next seven years, the Internet entered a growth phase. In 1987 the National Science Foundation
created NFSNET to link super-computing centers via a high-speed backbone (56Kbps). Although
NFSNET was strictly noncommercial, it enabled organizations to obtain an Internet connection without
having to meet ARPAnet's defense-oriented policy. By 1990 organizations connected to ARPAnet
completed their move to NSFNET, and ARPAnet ceased to exist. NSFNET closed its doors five years
later, and commercial providers took over the Internet world.
Until 1990 the primary Internet applications were e-mail, listserv, telnet, and FTP. In 1990, McGill
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (5 of 27) [4/22/1999 3:57:18 PM]
University introduced Archie, an FTP search tool for the Internet. In 1991, the University of Minnesota
released Gopher. Gopher's hierarchical menu structure helped users organize documents for presentation
over the Internet. Gopher servers became so popular that by 1993 thousands of Gopher servers contained
over a million documents. To find these documents, a person used the Gopher search tool Veronica (very
easy rodent-oriented netwide index to computerized archives). These search tools are important, but they
are not the ones that sparked the Internet explosion.
In 1992 Tim Berners-Lee, a physicist at CERN in Geneva, Switzerland, developed the protocols for the
World Wide Web (WWW). Seeking a way to link scientific documents together, he created the
Hypertext Markup Language (HTML), which is a subset of the Standard Generalized Markup Language
(SGML). In developing the WWW, he drew from the 1965 work of Ted Nelson, who coined the word
hypertext. However, the event that really fueled the Internet explosion was the release of Mosaic by the
National Center for Supercomputing (NCSA) in 1993.
From a standard for textual documents, HTML now includes images, sound, video, and interactive
screens via the common gateway interface (CGI), Microsoft's ActiveX (previously called control OLE),
and Sun Microsystem's Java. The changes occur so fast that the standards lag behind the market.
How large is the Internet today? That is a good question. We could measure the size of the Internet by
the number of network addresses granted by InterNIC, but these addresses can be "subnetted," so the
number of networks is much larger than InterNIC figures suggest. We could measure the size of the
Internet by the number of domain names, yet some of these names are vanity names (a domain name
assigned to an organization, but supported by servers that support multiple domain names) and other
aliases. Vanity names and aliases result in a higher name count than the number of IP addresses, because
multiple names point to the same IP address. Ultimately, the only way to measure the size of the Internet
is by the number of accounts. In my opinion, a reliable study on the number of accounts does not exist.
On the other hand, one change indicates an important perceptual change by the general public. Starting in
the fall of 1995, companies and organizations began to include their uniform resources locator (URL),
along with their street address, telephone number, and fax number, in television ads, newspaper ads, and
consumer newsletters. Therefore, a company's presence on the Internet, as represent by its Web address
(the URL), reached a new level of general acceptance. The Internet emerged from academia to become a
household word. Even those not connected to the Internet now know of its existence.
The question arises as to where all this technology is going. Because my crystal ball is broken, please
don't hold me to what I say. The one technology that I have not mentioned yet is virtual reality. The
documents and images seen on the Web are only two-dimensional and have limited interaction. The
Virtual Reality Modeling Language (VRML) attempts to bring a three-dimensional image to our
two-dimensional systems. One of these days, we will have three-dimensional devices and will be able to
enter a three-dimensional virtual world. In his 1984 science fiction novel Neuromancer, William Gibson
coined the words cyperspace and cyperpunk. He defined cyperspace as a "consensual hallucination
experienced daily by legitimate operators." How the future plays out depends on you, the reader, who
develops the software of the future.
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (6 of 27) [4/22/1999 3:57:18 PM]
The TCP/IP Protocol Model
Many works on TCP/IP networking begin with a discussion of the seven-layer Open Systems
Interconnection (OSI) model and then map the TCP/IP model to the OSI model. This approach fails
because TCP/IP does not neatly map into the OSI model and because many application models do not
map to the OSI application layers. If the OSI model fails to correctly reflect the nature of TCP/IP, what is
the best model? Over the years, different authors have described TCP/IP with three-, four-, and five-layer
models. Because it most accurately reflects the nature of TCP/IP, the following discussion of TCP/IP
uses the four-layer model as depicted in Figure 1.4.
Figure 1.4 : The four-layer TCP/IP model.
The TCP/IP protocols have their roots in the Network Control Program (NCP) protocol of the early
ARPAnet. In the early 1970s, the Transmission Control Protocol (TCP) emerged without the IP layer.
Thus the three-layer model, consisting of the physical layer, transport layer, and application layer, was
created. By the time OSI published its seven-layer model in 1977, IP was a separate layer, the Network
layer. Some publications add a Data Link layer between the Network layer and Physical layer. However,
such an expansion is not necessary because the TCP/IP model treats the Physical and Application layers
as open-ended, thereby enabling each layer to have several different models. The following sections
explore the layers of the TCP/IP model in more depth.
In addition to describing the flow of information, the four-layer model (physical, network, transport, and
application) also organizes the large number of protocols into a structure that makes them easier to
understand. In Internet jargon, the Request For Comment (RFC) describes a protocol. Today, more than
1,900 RFCs describe protocols, provide information, or are tutorials. In part, the success of the Internet is
a result of the open nature of its organization. The Internet Activities Board (IAB) provides overall
direction and management (see Figure 1.5 for the organizational chart), and task forces manage the
development of new protocols. The Internet Research Task Force (IRTF) deals with the long-term
direction of the Internet, and the Internet Engineering Task Force (IETF) handles implementation and
engineering problems. The Internet Engineering Steering Group (IESG) coordinates the activities of the
many working groups. Membership is not controlled by any organization; instead, anyone who so desires
can participate. Anyone can submit an RFC, and anyone can participate in a workgroup. In many ways,
the Internet is a grassroots organization that is beyond the control of any organization or government.
Figure 1.5 : The organization of the Internet Activities Board.
To get the latest status of the Internet or to obtain a copy of an RFC, the fastest route is via
http://www.internic.net. In particular, RFC 1920 (or its replacement) describes the
organization of the IAB in more detail, provides the status of RFCs, and gives instructions on how to
submit an RFC.
The Physical Layer
As the lowest layer in the stack, the Physical layer has the task of transmitting the IP datagram over the
physical media. Unlike the other layers, this layer has specific knowledge of the underlying network. As
a result, detailed models of this layer depend on the transmission protocol being used. The sections
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (7 of 27) [4/22/1999 3:57:19 PM]
"LAN Topologies" and "Internetworking-Linking LANs Together" explain these protocols in more
detail.
In general, the Physical layer
Encapsulates the IP datagram into the frames that are transmitted by the network l
Maps IP addresses to the physical addresses used by the network (the MAC address for Ethernet,
token ring, and FDDI)
l
Performs the operations necessary to transmit the frame over a particular media (such as thick
cable, thin cable, telephone wire, or optical fiber)
l
The Network Layer
The Network layer is sometimes called the Internetworking layer, which is a more descriptive term for
this layer's main function. Three protocols are defined in this layer: the Internet Protocol, Internet Control
Message Protocol (ICMP), and the Address Resolution Protocol (ARP). Of these, IP is the most
important protocol.
Internet Protocol
RFC 791 defines IP as a connectionless and unreliable protocol. It is connectionless because a connection
to the destination host does not have to be made prior to sending an IP datagram. The header of the IP
datagram contains sufficient information for it to be transported to its destination over either
connectionless or connection-oriented transmission protocols. It is an unreliable protocol because it does
not perform any error checking. All error checking, if required, is the responsibility of a higher layer
protocol.
What then is the purpose of IP? As the heart of the Internet, the functions of IP include
Creating a virtual network for the user l
Performing fragmentation and reassembly of datagrams l
Routing datagrams l
By creating a virtual network, IP hides the Physical layer and its underlying subnetwork from the end
user. The user application needs to know only the destination IP address; IP hides the mechanics of
delivery. It does this by fragmenting the packet received from the Transport layer to fit the Protocol Data
Unit (PDU) of the transmission protocol. For example, the PDU for Ethernet is 1,500 octets; for SNAP, it
is 1,492 octets; for X.25, it is 128 to 256 octets. For each transmission protocol encountered on a
datagram's journey to the destination host, IP makes the fragmentation decision until IP reassembles the
packet for the Transport layer at its final destination.
IP also handles routing of the datagram to its destination. IP accomplishes this by passing to the Physical
layer the IP address of the next hop, where a hop is the distance between a device and a gateway or the
distance between two gateways. The following are the rules IP uses for determining the next hop:
For IP addresses on a local network, send the datagram directly to the host. l
For other addresses, check the routing table for the gateway IP address toward the destination
network.
l
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (8 of 27) [4/22/1999 3:57:19 PM]
For all other addresses, send the datagram to the default gateway. l
A gateway is any device that connects to two or more networks. The gateway then follows the same rules
to make a routing decision. Because gateways make the routing decisions, the movement of the datagram
from source to destination is independent of any transmission protocol. In addition, each datagram
contains sufficient information to enable it to follow a separate path to the destination.
Internet Control Message Protocol (ICMP)
ICMP (RFC 792) performs the error reporting, flow control, and informational functions for IP.
Following are the major characteristics of ICMP:
ICMP data units are encapsulated by IP for submission to the Physical layer. l
ICMP is a required protocol. l
ICMP does not make IP reliable, because it only reports errors. l
ICMP reports errors on IP datagrams but not on ICMP data units. l
ICMP reports an error only on the first IP datagram if the IP datagram is fragmented. l
ICMP is not required to report errors on datagrams. l
ICMP reports the following types of messages:
ICMP sends a source quench message to the host or gateway to indicate that the IP buffers are full.
However, if the message flows through a gateway, the originating host does not receive the
message. This ICMP message goes only to the gateway that is one hop away.
l
ICMP sends a destination unreachable message to the originating host when the net-work is
unreachable, the host is unreachable, the protocol is unavailable, or the port is unavailable. (See
the section, "The Transport Layer," for an explanation of ports.)
l
A gateway sends a redirection message to the originating host to tell it to use another gateway. l
An echo request message can be sent to an IP address to verify that IP is running. The destination
responds with an echo reply message. The Ping command uses this type of ICMP message.
l
Address Resolution Protocol
Address Resolution Protocol (ARP) and Reverse Address Resolution Protocol (RARP) present an
interesting problem regarding which layer to assign these protocols to. Because they are used only by the
multinode transmission protocols (Ethernet, token ring, and FDDI), ARP and RARP belong to the
Physical layer. However, because the transmission protocol encapsulates their packets, they belong to the
Network layer. To keep the encapsulation boundary clear, I have included them in the discussion on the
Network layer.
ARP (RFC 826) resolves IP addresses to MAC addresses (the "Ethernet LANs" section provides
additional information about the MAC address) by broadcasting an ARP request to the attached LAN.
The device that recognizes the IP address as its own returns an ARP reply along with its MAC address.
The result is stored in the ARP cache. On subsequent requests, the transmission protocol needs to check
only the ARP cache. To allow for the dynamic nature of networks, the system removes any ARP entry in
the cache that has not been used in the last 20 minutes.
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (9 of 27) [4/22/1999 3:57:19 PM]
RARP (RFC 903) performs a totally different function. If a device does not know its IP address (such as
a diskless workstation), it broadcasts a RARP request asking for an IP address. A RARP server responds
with the IP address.
The Transport Layer
The Transport layer provides two protocols that link the Application layer with the IP layer. The TCP
provides reliable data delivery service with end-to-end error detection and correction. The User
Datagram Protocol (UDP), on the other hand, provides an application with a connectionless datagram
delivery service.
NOTE
Applications can use TCP, UDP, or both. The needs of the application
determine the choice of protocols.
For both TCP and UDP, the port number defines the interface between the Transport layer and the
Application layer. The port number is a 16-bit value that identifies a particular application. The services
file, in UNIX /etc/services, connects application names with the port numbers and the associated
protocol. Following is a sample of the contents of the services file:
# Format:
#
# <service name> <port number>/<protocol>
#
echo 7/udp
echo 7/tcp
systat 11/tcp
netstat 15/tcp
ftp-data 20/tcp
fdp 21/tcp
telnet 23/tcp
smtp 25/tcp
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (10 of 27) [4/22/1999 3:57:19 PM]
time 37/tcp
time 37/udp
Port numbers between 1 and 255 are the "well-known services," which represent the port numbers to
common application protocols. The Internet Assigned Numbers Authority assigns the numbers for the
well-known services, and RFC 1700 contains the current list of assigned numbers. Port numbers between
256 and 1024 previously referred to UNIX applications, although a number of these now exist on other
platforms. BSD UNIX specifies that the numbers below 1024 require root permission. The remaining
numbers are assigned to experimental applications and to user-developed applications. The packets sent
by TCP and UDP contain both the source port number and the destination port number in the packet
header. The section "Sockets and Socket APIs" covers the use of port numbers in more detail.
The Transport layer is stream-oriented and not block-oriented. The Applications layer sends data to the
Transport layer byte-by-byte. The Transport layer assembles the bytes into segments and then passes the
segments to the Network layer. TCP and UDP use different methods to determine the segment size as
explained in the following sections.
Transmission Control Protocol (TCP)
The key to understanding TCP lies in the end-to-end principle. In a nutshell, the principle says that only
the ends can be trusted because the carrier is unreliable. The ends, in this case, are the TCP protocol of
the source and the destination hosts. Thus any error checking performed by the Physical layer is
redundant.
NOTE
Use TCP when an application must have reliable data delivery.
TCP uses a technique called positive acknowledgment and re-transmission (PAR) to ensure reliability.
After waiting for a time-out, the sending host (or source host) retransmits a segment (the name for a TCP
packet) unless it receives an acknowledgment from the destination host. The destination host
acknowledges only segments that are error free and discards any segments that contain errors. Because
an acknowledgment can arrive after the host resends the segment, the receiving host must discard
duplicate segments. Also, because segments can arrive out of sequence (because each IP datagram can
take a different route between the sending host and destination host) the destination host must resequence
the segments.
NOTE
The stream-oriented nature of TCP means that the responsibility for
management of blocks, frames, or records lies in the application.
TCP sequentially numbers each byte in the input data stream and uses this sequence number to track the
acknowledgments of data received by the destination host. To initiate the connection and establish the
initial sequence number, the source host sends a sync packet to the destination host. The destination host
responds with a sync acknowledgment that also contains the initial window size and, optionally, the
maximum segment size. The window size represents the maximum amount of data that can be sent
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (11 of 27) [4/22/1999 3:57:19 PM]
before receiving an acknowledgment. Because each acknowledgment contains the window size, the
destination controls the flow of information. This form of flow control is separate from the flow control
mentioned in the ICMP section. ICMP refers to IP buffers, whereas window size refers to TCP buffers.
ICMP flow control affects the device one hop away (which may be a gateway or the source host);
window size affects only the source host.
The acknowledgment message contains the highest consecutive octet received as well as the new window
size. The destination host does not acknowledge out-of-sequence segments until it receives the
intervening segments. After the time-out period elapses, the source host retransmits the unacknowledged
portion of the window. This sliding window provides for end-to-end flow control and minimizes IP
by acknowledging more than one segment.
Figure 1.6 illustrates the principle of the sliding window. For the sake of simplicity, the segment size
used in Figure 1.6 is 1,000 octets. The initial window size is 5,000 octets, as specified in the sync
acknowledgment message. The source host transmits segments until the window size is reached. The
destination host acknowledges receiving 2,000 contiguous octets and returns a new window size of
5,000, which enables the source host to send another 2,000 octets. Should the time-out period expire
before the source host receives another acknowledgment, the source host retransmits the entire 5,000
octets remaining in the window. Upon receiving the duplicate segments, the destination host trashes these
duplicates.
Figure 1.6 : TCP sliding window.
Upon receiving segments, the destination host passes the acknowledged segments to the receiving port
number as a stream of octets. The application on the receiving host has the job of turning this stream into
a format required by the application.
Just as the process to open a connection involves a three-way handshake, the closing process (fin) uses a
three-way handshake. Upon receiving a close request from the application, the source host sends a fin
request to the destination host, with the sequence number set to that of the next segment. To actually
close the connection requires the acknowledgment of all segments sent and a fin acknowledgment from
the destination host. The source host acknowledges the fin acknowledgment and notifies the application
of the closure.
As I explained, the PAR method used by TCP minimizes the IP over the connection. Furthermore,
it does not depend on the reliability of the carrier. On the contrary, a carrier that spends too much time
achieving reliability causes TCP to time out segments. For TCP/IP, a well-behaved transmission protocol
trashes, rather than corrects, bad datagrams.
User Datagram Protocol (UDP)
UDP (RFC 768) provides an application interface for connectionless, unreliable datagram protocol. As
mentioned at the beginning of "The Transport Layer" section, the protocol does not provide a mechanism
for determining if the destination received the datagram or if it contained errors.
NOTE
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (12 of 27) [4/22/1999 3:57:19 PM]
Because UDP has very little overhead, applications not requiring a
connection-oriented, reliable delivery service should use UDP instead
of TCP. Such applications include those that are message oriented.
The UDP packet reflects its simplicity as a protocol. The UDP packet contains only the beginning and
destination port number, the length of the packet, a checksum, and the data. It needs nothing else because
UDP treats every packet as an individual entity.
Applications that use UDP include applications that
Provide their own mechanism for connections, flow control, and error checking l
Produce less retransmission overhead l
Use a query/response model l
For each type of application, UDP eliminates unnecessary overhead.
The Application Layer
The Application layer is the richest layer in terms of the number of protocols. This section covers the
most popular protocols. The "Routing in an Internetwork" section covers the routing protocols, and "The
Client/Server Model" section examines various models for application protocols. Despite this broad
coverage, this chapter considers only a sampling of the many application protocols that have an RFC. An
even greater number of intranet applications do not have an RFC. Applications need only follow the rules
for interfacing to the Transport layer, and the socket APIs (covered in the "Sockets and Socket APIs"
section) hide from the programmer the details of this interface.
It is important to remember that every TCP/IP application is a client/server application. When it comes to
the well-known applications discussed in the following sections, the server side exists on every major
hardware platform. Except for revisions to old application protocols and the development of new
application protocols, much of the work in software development for the well-known protocols centers
around the client side of the equation. This situation applies even to the wild world of HTTP. The once
light Web browser now performs many tasks that once required the support of the server. Client-side
image mapping, Java applets, and scripting languages such as JavaScript and Visual Basic make the Web
browser the work horse. This transfer of processing to the client side leaves the server free to respond to
more requests.
Telnet
Telnet is one of the oldest and most complicated of the application protocols. Telnet provides network
terminal emulation capabilities. Although telnet standards support a wide variety of terminals, the most
common emulation used in the Internet is the vt100 emulation. Besides terminal emulation, telnet
includes standards for a remote login protocol, which is not the same as the Berkeley rlogin protocol. The
full telnet specification encompasses 40 separate RFCs. The Internet Official Protocol Standards RFC
(RFC 1920 as of this writing) contains a separate section that lists all current telnet RFCs. However,
telnet clients usually implement a subset of these RFCs.
Telnet remains the primary protocol for remotely logging into a host. Although the terminal emulation
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (13 of 27) [4/22/1999 3:57:19 PM]
features are important, other protocols use the remote login portion of the standard to provide
authentication services to the remote host. In addition to the traditional remote login standard, some
telnet clients and servers support Kerberos (the security method developed by the MIT Athena Project
and used in DCE) to provide a secure login capability.
File Transfer Protocol (FTP)
FTP (RFC 959) is another old-time protocol. It is unusual in that it maintains two simultaneous
connections. The first connection uses the telnet remote login protocol to log the client into an account
and process commands via the protocol interpreter. The second connection is used for the data transfer
process. Whereas the first connection is maintained throughout the FTP session, the second connection is
opened and closed for each file transfer. The FTP protocol also enables an FTP client to establish
connections with two servers and to act as the third-party agent in transferring files between the two
servers.
FTP servers rarely change, but new FTP clients appear on a regular basis. These clients vary widely in
the number of FTP commands they implement. Very few clients implement the third-party transfer
feature, and most of the PC clients implement only a small subset of the FTP commands. Although FTP
is a command-line oriented protocol, the new generation of FTP clients hides this orientation under a
GUI environment.
Trivial File Transfer Protocol (TFTP)
The trivial part of the name refers not to the protocol itself, but to the small amount of code required to
implement the protocol. Because TFTP does not include an authentication procedure, it is limited to
reading and writing publicly accessible files. Consequently, TFTP is a security risk and must never be
used to transfer data through a firewall.
TFTP uses the flip-flop protocol to transfer data. In other words, it sends a block of data and then waits
for an acknowledgment before sending the next block. It uses UDP and therefore performs its own
integrity checks and establishes a very minimal connection. In contrast to the richness of FTP, TFTP
defines only five types of packets: read request, write request, data, acknowledgment, and error. Because
TFTP is so limited, only a few applications (such as router management software and X-terminal
software) use it.
Simple Mail Transfer Protocol (SMTP)
The word simple in Simple Mail Transfer Protocol refers to the protocol and definitely not to the
software required to implement the protocol. Like telnet, many RFCs define SMTP. The two core RFCs
are 821 and 822. RFC 821 defines the protocol for transfer of mail between two machines. RFC 822
defines the structure of the mail message. The mail handling system (MHS) model describes the
components needed to support e-mail. As shown in Figure 1.7, the MHS consists of the mail transfer
agent (MTA), the mail store (MS or mailbox), and the user agent (UA).
Figure 1.7 : Components of a mail handling system.
The MTA (such as sendmail) receives mail from the UA and forwards it to another MTA. Because the
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (14 of 27) [4/22/1999 3:57:19 PM]
MTA for SMTP receives all mail through port number 25, it makes no distinction between mail arriving
from another MTA or from a UA. The MS stores all mail destined for the MTA. The UA reads mail from
the MS and sends mail to the MTA.
A UA executing on the MTA host needs only to read the MS as a regular file. However, the network UA
requires a protocol to read and manage the MS. The most popular protocol for reading remote mail is the
post office protocol version 3 (POP-3) as defined by RFC 1725, which makes RFC 1460 obsolete. So as
to enhance the security of POP-3, RFC 1734 describes an optional authentication extension to POP-3.
POP-3 transfers all of the mail to the UA and enables the mailbox to be kept or cleared. Because keeping
the mail in the MS means that it is downloaded every time, most users choose the clear mailbox option.
This option works when you have only one client workstation that always reads the mail. Users who need
a more sophisticated approach to mail management should consider the Internet Mail Access Protocol
(IMAP). RFC 1732 describes the specifications for version 4 of IMAP. With IMAP, the mail server
becomes the mail database manager. This method enables a user to read mail from various workstations
and still see one mail database that is maintained on the mail server.
Network News Transfer Protocol (NNTP)
In 1986, the year that Brian Kantor and Phil Lapsley wrote the Network News Transfer Protocol (NNTP)
standard (RFC 977), ARPAnet used list servers for news distributions, and Usenet was still a separate
UUCP network. With this standard, the door opened to establish Usenet news groups on ARPAnet. The
NNTP standard provides for a new server that maintains a news database. The news clients use NNTP to
read and send mail to the news server. In addition, the news server communicates with other news
servers via NNTP.
Gopher Protocol
The popularity of the Gopher protocol is without question. Because it provides a simple mechanism for
presenting textual documents on the Internet, Gopher servers provide access to over one million
documents. Nevertheless, RFC 1436, the only Gopher protocol RFC, is an informational RFC.
Gopher uses a hierarchical menu system, which resembles a UNIX file system, to store documents. The
Gopher client enables the user to negotiate this menu system and to display or download stored
documents. Before the popularity of the Web browser, Gopher clients, as separate applications, were
popular. Today, the Web browser is the most common client used to display Gopher documents.
HyperText Transfer Protocol
Although HTTP dates back to 1990, it still doesn't have an RFC. However, several Internet drafts reflect
the "work in progress." Although the Web uses HTTP, HTTP's potential uses include name servers and
distributed object management systems. HTTP achieves this flexibility by being a generic, stateless,
object-oriented protocol. It is generic because it merely transfers data according to the URL and handles
different Multipurpose Internet Mail Extension (MIME) types (see the following section for details about
MIME types). Because it treats every request as an isolated event, HTTP is stateless.
Although an HTTP server is small and efficient, the client bears the burden of the work. The client
processes the HTML-encoded document and manages all the tasks involved in retrieval and presentation
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (15 of 27) [4/22/1999 3:57:19 PM]
of the retrieved objects. The URL and MIME open the doors to a degree of flexibility not found in any
other document retrieval protocol.
Multipurpose Internet Mail Extension
The original MIME standard set out to resolve the limitations of the ASCII text messages defined in RFC
822. Using the content header standard (RFC 1049), the MIME standard defines the general content type
with a subtype to define a particular message format. MIME is an extensible standard, and RFC 1896
describes the latest extensions. Once again, the client (the UA for an MHS) must take care of building
and displaying MIME attachments to mail messages.
The simplicity and extensibility of the MIME standard led it to being used to extend the content of other
protocols beyond the limits of ASCII text. The notable uses are in the Gopher protocol and HTTP.
LAN Topologies
Although serial and parallel links between computers had existed for some time, multinode networks did
not become a serious commercial presence until the early 1980s. The growth of LANs came from two
different directions. On the one hand, the corporate need to share files and resources (printers, plotters,
and so on) among their PCs encouraged companies such as Novell, Banyan, and Microsoft to develop PC
networks. On the other hand, the development of workstations meant that part of the workload could be
moved from the server to the workstation. These contrasting developments led to the distinction between
server-based LANs and peer-to-peer LANs. (See "The Client/Server Model" section for more details.)
The physical topology of a LAN refers to the networking cabling layout of which there are three types:
bus (see Figure 1.8), ring (see Figure 1.9), and star (see Figure 1.10). However, there are only two types
of logical topologies: bus (Ethernet) and ring (token ring).
Figure 1.8 : An example of a bus topology.
Figure 1.9 : An example of a ring topology.
Figure 1.10 : An example of a star topology.
Ethernet LANs
The key difference between Ethernet and token ring is the method used to control access to the cable in a
multinode network. Ethernet uses Carrier Sense Multiple Access/Collision Detection (CSMA/CD),
which translates to "listen first, then send, and monitor for collisions." When a packet is placed on the
cable, every node listens to determine whether the packet is addressed to it. If a collision occurs, the
packet on the cable appears as garbage. The first node to hear the collision sends a jam packet, which
forces the transmitting nodes to randomly set a delay before attempting to transmit again. As the amount
of network increases, the probability of a collision increases. In general, a load between 20
and 40 percent of the bandwidth brings the network to a halt as it tries to resolve collisions.
The address used at this level is the MAC address and is not the same as the IP address. The MAC
address is a 48-bit address that the manufacturer programs into each network card. To ensure against
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (16 of 27) [4/22/1999 3:57:19 PM]
duplicates, each manufacturer is assigned a block of address by IEEE. As a media address, the MAC
address applies only to LAN addressing. On the other hand, the IP address is a logical address that is
independent of the media used in a particular network.
The multiplicity of Ethernet protocols confuses many newcomers trying to understand Ethernet LANs.
Two Ethernet protocols are in use today: Ethernet (also called Ethernet II or DIX Ethernet) and IEEE
802.3. Although IEEE made many changes to the Ethernet II format, its change of the type field to the
length field created a problem for TCP/IP, which uses the type field to define the type of IP packet. To
get around this problem, IEEE 802.2 defines the Sub Network Access Protocol (SNAP), which once
again includes the type field. Figure 1.11 illustrates the difference between Ethernet II and SNAP.
Figure 1.11 : Comparison of Ethernet II and SNAP protocols.
NOTE
DIX is an acronym for the three companies that defined the
standard-Digital, Intel, and Xerox.
Although Ethernet LANs support mixing these variations on a single network, two nodes must use the
same protocol to communicate with each other. Therefore, every node on a TCP/IP network uses either
Ethernet II or SNAP, but not both on the same network.
The 10Mbps bandwidth of Ethernet was fast 12 years ago; but with the increased use of multimedia in
user interfaces, it no longer meets the demands of modern LANs. Fast Ethernet (100Mbps) offers one
alternative, but a number of new hubs use a full-duplex technology to increase the effective utilization of
bandwidth.
Token Ring Topology
Instead of CSMA/CD, the token ring network passes a token from node to node. A node transmits only
when it has the token. The transmitting node marks the token as in use and then transmits a data packet
with the token attached. The receiving node acknowledges the receipt and passes the token back to the
sender, which then marks the token as free and passes to the next node. This deterministic process
ensures that each node receives equal access to the network under all load conditions.
Although the IEEE 802.5 standard defines the token ring architecture, IBM developed a revised standard
to which most token ring networks adhere. Although the topology defined by the standards is a physical
star, the logical topology is still a ring topology. The multistation access unit (MAU) acts much like an
Ethernet hub except that the MAUs are connected in a ring (refer to Figure 1.9).
Throughout the 1980s, token ring topology seemed poised to replace Ethernet. However, several factors
prevented this from happening. The token ring hardware and software were more expensive than
Ethernet components, but token ring cabling was cheaper. (Token ring uses unshielded telephone cable.)
The introduction of the Ethernet hub in the late 1980s erased token ring's price advantage. In addition,
even though token ring offered a 16-Mbps bandwidth (older versions used 4Mbps), the lack of standards
for cabling led to vendor-dependent solutions.
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (17 of 27) [4/22/1999 3:57:19 PM]
Fiber Distributed Data Interface (FDDI) also uses the token ring topology. Although the ANSI X3T9.5
committee started to define the FDDI standard in 1984, the standard did not stabilize until 1990. The
frame format is similar to IEEE 802.5 standard for token rings, but operates at 100Mbps. Because of the
high cost of fiber, FDDI networks often form the backbone to connect lower-speed networks (see Figure
1.12).
Figure 1.12 : Example of LANs connected by an FDDI backbone.
Repeaters, Bridges, and Routers
Repeaters, bridges, and routers perform their own unique functions in networking. The simplest device is
the repeater, which sole function is to link LAN segments to form a longer cable. It passes on everything
that it receives so that all the packets seen on one side of the repeater are repeated on the second side.
Figure 1.13 illustrates the operation of a repeater.
Figure 1.13 : Illustration of a repeater in a LAN.
Bridges are, in a sense, intelligent repeaters. Instead of passing all from one side to the other,
bridges pass only that is addressed to a node on the other side. The bridge accomplishes this task
by looking at the MAC address of the frame in question. Because the bridge does not alter the frame, the
LAN segments must use the same topology (Ethernet to Ethernet; token ring to token ring) on both sides
of the bridge. Figure 1.14 shows a transparent bridge in an Ethernet network.
Figure 1.14 : A transparent Ethernet bridge.
The transparent bridge looks at the frame, but does not modify it. On the other hand, a translation bridge
removes the frame encapsulation and then encapsulates the datagram with the frame protocol of the
destination network. Multiport bridges route according to the MAC addresses on each LAN
segment. Yet even these more exotic bridges tie together only segments of a single network.
A router, on the other hand, routes between separate networks. This capability earns a router the
title of gateway, which is any device with two or more network interfaces. To accomplish its task, the
router extracts the IP datagram from the frame, looks at the destination IP address, determines where to
route the packet, and then encapsulates the packet with the frame of the next transmission protocol.
Figure 1.15 illustrates the actions of a router.
Figure 1.15 : A model for routing IP datagrams.
The routing decision rules are the same as the Internet Protocol rules described earlier in the chapter. If
the MTU of the next transmission protocol is smaller than the size of the IP datagram, the router
fragments the IP datagram to fit the new MTU. Therefore, the destination host can receive many more IP
datagrams than the originating host created. The end of the next section covers the routing protocols used
to build the routing table.
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (18 of 27) [4/22/1999 3:57:19 PM]
Internetworking-Linking LANs Together
The original ARPAnet was a wide-area network (WAN), but it was not an internetwork, at least in
today's understanding of this term-LANs as we know them did not become popular until the 1980s. The
connection of LANs marked the true birth of internetworking, for then individual LANs could connect to
form an even larger network-an intranet. When LANs connect to the global network, they form the
Internet. This section looks at the technology that makes this connection happen.
Point-to-Point Links
The most basic link between two networks is a point-to-point line between them. The telephone
companies in the United States and Japan market these lines as T1, fractional T1, T3, and T4. A T1 line
consists of 24 channels, each with a 64Kbps bandwidth (actually 56Kbps, because 8Kbps of the channel
is for control signals) for a total bandwidth of 1.544Mbps. This scheme derives not from the needs of
digital signals, but from the need to stretch copper wire by multiplexing voice channels. Thus, a fraction
T1 line consists of one or more channels from a full T1 line. Going in the other direction, multiplexing
28 T1 lines forms a T3 (44.736Mbps) and six T3s make up a T4 (274.276Mpbs). In the rest of the world,
the E1 line contains 32 channels with a bandwidth of 64Kbps for a total bandwidth of 2.048Mbps.
As delivered by a telephone company, these lines are devoid of any Physical layer protocol. Companies
use three methods to transfer data between two routers:
Proprietary protocols l
Serial Line Interface Protocol (SLIP) l
Point-to-Point Protocol (PPP) l
To avoid depending on a single vendor for all your equipment, the preferred protocol is PPP. If PPP is
not available, SLIP becomes a good second choice.
SLIP and PPP
SLIP (RFC 1055) is an IP datagram encapsulation protocol that enables IP datagrams to be transmitted
over an asynchronous serial line. SLIP works on both dial-up lines or leased lines. SLIP is a simple but
crude protocol that works well with TCP. However, for protocols such as NFS that use UDP without
having an error correction mechanism, SLIP is a poor choice.
Originally, serial links were synchronous links using the high-level data link control (HDLC) protocol.
What PPP provides is an HDLC format over asynchronous serial lines. PPP offers many advantages over
SLIP in that PPP
Provides interoperability between products from different vendors l
Supports datagrams from different protocol stacks (such as IP, IPX, and DECnet) l
Provides monitoring of the link through the link quality monitoring (LQM) l
Provides an authentication mechanism through Password Authentication Protocol (PAP) l
PPP establishes a connection in two stages:
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (19 of 27) [4/22/1999 3:57:19 PM]
The two sides of the link exchange Link Control Protocol (LCP) packets to establish the link and
ensure quality via LQM.
1.
They then exchange Network Control Protocol (packets) for each configured protocol stack. 2.
PPP encapsulates the datagrams using a modified HDLC format. On a periodic basis, the two sides
exchange LQM packets to monitor the line quality. The network administrator configures the acceptable
quality levels. Because of its strengths, PPP is superior to SLIP or other proprietary protocols.
X.25 Links
Although ARPAnet publicly demonstrated the effectiveness of packet-switched networks in 1972,
CCITT did not define the X.25 standard until 1976. The X.25 standard takes a different approach to
reliability. Instead of depending on higher level protocols, X.25 uses hop-to-hop verification of a packet.
The standard's intent was to provide reliable delivery over lines with high error rates.
X.25 is connection oriented in that the sending party must initiate a connection to the receiving party.
This connection establishes a virtual circuit that remains throughout the session. Because the virtual
circuit is established at the time of connection, it is a switched virtual circuit (SVC). X.25 allows up to a
maximum of 32 SVCs at the same time, of which four can be to the same destination gateway. Figure
1.16 illustrates the workings of an X.25 "cloud."
Figure 1.16 : An X.25 WAN.
As Figure 1.16 illustrates, a WAN consists of a line, usually 56Kbps for IP, to the cloud, the SVC within
the cloud, and another line to the destination gateway. Because multiple users share the lines within the
cloud, X.25 regulates via a credit mechanism. The sender cannot send data unless it has a credit.
X.25 is not an ideal WAN protocol for TCP/IP networks for the following reasons:
The small MTU of 128 to 256 octets increases the amount of IP fragmentation. l
The hop-to-hop approach creates redundant error checking. l
The credit system for regulating results in time-outs and extra retransmission of datagrams. l
Frame Relay Links
In 1990, frame relay was the hottest new WAN protocol. Instead of an SVC, frame relay uses a
permanent virtual circuit (PVC). To identify each PVC, frame relay uses a data link connection identifier
(DLCI). As with X.25, frame relay requires a line to the cloud. The PVC exists within the cloud itself.
Figure 1.17 shows a typical frame relay setup.
Figure 1.17 : Example of a WAN using frame relay.
Two factors determine the speed of frame relay connections: the bandwidth of the line into the cloud and
the committed information rate (CIR). The bandwidth of the line into the cloud sets the maximum total
bandwidth for all PVCs assigned to the line. The CIR sets the guaranteed bandwidth within the cloud. If
the rate of transmission for a PVC exceeds the CIR, the excess frames are subject to being trashed if the
cloud needs the extra bandwidth to meet its committed rates, which is how frame relay regulates in
the cloud. This method fits with TCP's end-to-end principle. In addition, frame relay supports an MTU of
4,500 octets, which eliminates fragmentation.
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (20 of 27) [4/22/1999 3:57:19 PM]
Integrated Digital Service Network (ISDN) Links
After years of standards and more standards, ISDN is hot news. But despite all the media attention, is
ISDN really a viable technology for building intranets or connecting to the Internet? Telephone
companies offer ISDN as either a basic rate interface (BRI) or a primary rate interface (PRI). BRI consist
of two 64Kbps channels (referred to as B channels) and one control channel (called a D channel) or
2B+D. The rarely used PRI consisted of 23 B channels plus a control channel (23B+D). ISDN is a
dial-up service that enables one site to connect to another ISDN site. However, because it has only one D
channel, the B channels cannot be connected to different sites.
Normally, the consumer pays a low monthly fee plus, in some states, a connect time charge. The cost of
an ISDN connection is lower than the packet charges for X.25. However, when compared to the fixed
monthly charge for frame relay, the cost for a heavily used ISDN connection is higher.
Although the number of ISDN equipment providers is increasing, ISDN still suffers from problems with
interoperability. Problems of interoperability apply not only to the equipment but also to the transmission
protocols used to carry the IP datagrams. Some vendors push asynchronous transfer mode (ATM) as the
best protocol, while others use PPP. In general, ISDN is not the best solution for primary WAN
connections, but is an alternative for backup lines and for high-speed dial-up connections.
Asynchronous Transfer Mode Links
Media announcements bill ATM as the technology of the future. Does it really deserve such intense hype
or is it on the road to becoming another ISDN? While the development of ATM standards proceeds
toward a full definition of ATM, manufacturers are busy producing ATM equipment. At this point in
time, we face conflicting protocols for defining IP over ATM. RFC 1932 discusses this problem and
summarizes the issues facing the ATM Working Group. Yet, IP over ATM is only the first step.
Standards for ATM as a transport protocol are still in the works.
Following along the lines of X.25, ATM networks are connection-oriented, SVC networks. By using a
small packet (called a cell in ATM terminology), ATM evenly multiplexes cells that contain data, voice,
or video information. However, the small cell size increases the overhead and increases fragmentation.
Until ATM standards stabilize, the question of the viability of ATM remains open.
Routing in an Internetwork
The previous section on routers covered how routers direct IP datagrams between networks and how
routers connect networks that use different transmission protocols. This section deals with building the
routing table that IP uses to make routing decisions.
The network administrator has the option to manually define static routes. However, in a large and
dynamic network, this process is both tedious and prone to error. On the other hand, routing protocols
automatically discover networks and the paths to the networks. However, like everything else in the
Internet, routing protocols evolved over the years to meet new network demands.
Routing Information Protocol (RIP) was the first route discovery protocol defined by IETF. Because part
of the job of a route discovery protocol is to find alternative paths between networks, RIP uses the
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (21 of 27) [4/22/1999 3:57:19 PM]
distance-vector method to accomplish this task. In brief, the distance-vector method determines the
"cost" of a path by the number of hops required to reach a network. The path with the lowest cost is
stored in the routing table. Periodically, RIP rediscovers the network to find any changes. One problem
with RIP is that the lowest cost path might not be the fastest path. Although many routing protocols exist,
the open shortest path first (OSPF) protocol is the best solution to route discovery. Instead of using the
distance-vector method, OSPF uses the link-state metric approach. OSPF adapts more quickly to changes
in the network than does RIP.
As the size of the Internet increased, route discovery protocols created two problems: the routing tables
became massive, and route discovery protocols consumed too much of the network bandwidth. The
solution was to divide the Internet into autonomous systems (AS). Within an AS, the interior gateway
protocols (IGPs), such as RIP and OSPF, dynamically discovered the network. Between autonomous
systems, an exterior gateway protocol (EGP), such as the exterior gateway protocol (EGP) or the border
gateway protocol (BGP), shared information between neighboring autonomous systems. Today, BGP
version 4 (BGP-4) is the standard Internet EGP. However, as the number of routers connecting to the
Internet continue to increase, the IETF continues to work on ways to reduce the amount of route
discovery . In the early 1990s, InterNIC began distributing class C addresses in classless
interdomain routing (CIDR) blocks. CIDR permits the routing of class C addresses as a block rather than
as individual networks. However, even CIDR is but a short-term fix to a growing problem.
IP Addresses and Domain Names
Internetworking routes IP datagrams according to the IP address, but humans find names easier to
remember. This section briefly reviews the principles of IP addresses and provides an overview of how
names are resolved to addresses.
What Is an IP Address?
Perhaps the easiest way to understand IP addresses is to look at the Internet as a global network. All
networks that comprise the global network are just subnets. InterNIC provides the first level of
subnetworking by dividing the global address space into classes that are assigned to organizations. The
organizations are then responsible for subdividing their assigned address space to meet their network
needs.
The IP address is a 32-bit number. To simplify the notation of addresses, divide this number into four
octets and write the octets in a dotted-decimal format. Three types of IP addresses exist: network address,
host address, and broadcast address. Because every host is part of a network, you divide the IP address
into a network portion and a local host portion. When the local host portion is all zeros, it is a network
address; all ones is a broadcast address. Anything else is a host address. However, the IP address itself
contains no information about what constitutes the network portion versus the local host portion. The
subnet mask provides this information. By convention, binary ones define the network portion, and zeros
define the local host portion. Again, by convention, the ones must be contiguous to the left, and the
remainder is zeros. Figure 1.18 illustrates this scheme.
Figure 1.18 : IP addresses and subnet masks.
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (22 of 27) [4/22/1999 3:57:19 PM]
As mentioned previously, InterNIC splits the global address space into classes and then assigns the
network address according to these divisions. Table 1.1 shows the breakdown of the address space.
Table 1.1. IP address classes.
Table Class Network Address Subnet Mask No. of Networks
table A 1-126 255.0.0.0 126
table B 128-191 255.255.0.0 16,384
table C 192-223 255.255.255.0 2,097,152
table D 224-254 255.255.255.0 (experimental)
As mentioned before, the designations shown in Table 1.1 represent assigned network addresses. The
network manager for an organization is then responsible for additional subnetting, according to the
requirements of their individual networks.
Special IP Addresses
Several special IP addresses also exist. For an Internet programmer, the most important special addresses
are the local loopback address and the broadcast address. For the network administrator, the most
important special addresses are those set aside for networks not connected to the Internet.
The local loopback address (127.0.0.1) enables a client application to address a server on the same
machine without knowing the address of the host. This address is often called the local host address. In
terms of the TCP/IP protocol stack, the flow of information goes to the Network layer, where the IP
protocol routes it back up through the stack. This procedure hides the distinction between local and
remote connections.
Broadcast addresses enable an application to send a datagram to more than one host. The special address
255.255.255.255 sends a "limited broadcast" to all hosts on this network. A "direct broadcast" uses
the address form A.255.255.255, B.B.255.255, or C.C.C.255 to send messages to all hosts on
a particular class A, B, or C network. Finally, a broadcast to a particular subnet is to the address with all
local host bits set to one.
RFC 1918 specifies an Internet "best current practice" for address allocation on private internets
(intranets). For a network not connected to the Internet, or a network where all Internet passes
through a proxy server, the Internet Assigned Numbers Authority (IANA) reserved three blocks of IP
address space: 10.0.0.0 to 10.255.255.255, 172.16.0.0 to 172.31.255.255, and 192.168.0.0 to
192.168.255.255. This block is equivalent to one class A address, 16 class B addresses, and 256 class C
addresses.
Resolving Names to Addresses
In the early days of ARPAnet, a system resolved names to addresses using the hosts file. The Stanford
Research International (SRI) maintained the hosts file, and each site periodically downloaded an updated
copy of the file. As the number of sites connected to ARPAnet increased, this method proved too hard to
maintain and placed an increasing burden on the network. In 1984 Paul Mockapetris, of University of
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (23 of 27) [4/22/1999 3:57:19 PM]
Southern California's Information Sciences Institute, released RFCs (882 and 883) that describe the
domain name system. Today, DNS is the standard for resolving names to addresses. However, the hosts
file still plays a role in name resolution during the booting of a system and as a means to provide LAN
resolution when DNS is down.
In a nutshell, DNS is a distributed database whose structure looks like the UNIX file system. DNS is a
client/server system in which the resolvers query name servers to find an address record for a domain
name. The query process begins with the root name servers. If the root name server does not know the
answer, it returns the address of a name server that knows more details about the domain name. The
resolver then queries the new name server. This iterative process continues until a name server responds
with the address for the domain name. Figure 1.19 illustrates the structure of DNS.
Figure 1.19 : The hierarchical structure of DNS.
The resolver maintains the retrieved information in a cache until the designated time to live (TTL) for the
record expires. This approach reduces the number of queries and, at the same time, responds to the
dynamic nature of networks. By distributing the database across the Internet, the site responsible for the
information maintains the information.
The Client/Server Model
By definition, every TCP/IP application is a client/server application. In this scenario the client makes
requests of a server. That request flows down the TCP/IP protocol stack, across the network, and up the
stack on the destination host. Whether the server exists on the same host, another host of the same LAN,
or on a host located on another network, the information always flows through the protocol stack.
From the information presented to this point, the client/server model has some general characteristics:
The server provides services and the client consumes services. l
The relationship between the client and the server is machine-independent. l
A server services many clients and regulates their access to resources. l
The client and server can exist on different hardware platforms. l
The exchange between client and server is a message-based interaction. l
The server's methodology is not important to the client. l
The client carries the bulk of the processing workload so that the server is free to serve a large
number of clients.
l
The server becomes a client to another server when it needs information beyond that which it
manages.
l
By specifying only the interface between the Application layer and the Transport layer, the TCP/IP
Application layer permits various Application layer models. This open-ended approach to the
Application layer makes it difficult to draw a single model that illustrates all TCP/IP applications. On
one end of the scale, applications run as shell-level commands; on the other, applications run in various
window environments. For example, the traditional telnet is run from the shell. Yet, some
implementations of the telnet client take advantage of windows technology. To make life more
complicated, telnet implementations are also available for the distributed computing environment (DCE).
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (24 of 27) [4/22/1999 3:57:19 PM]
C++ client/server applications use the Object Management Group's (OMG) Common Object Request
Broker Architecture (CORBA) model. Consequently, trying to define a universal Application layer
model is an exercise in futility.
However, even with all the variations, the Web browser continues to grow as a popular Windows
environment for the implementation of the client side of the equation. By using a common windowing
environment, users access the Web, connect to remote with telnet, download files, read mail, and access
Usenet through one interface. Although browsers implement this interface in a variety of ways, the
direction is toward using the browser as an interface to Internet applications.
Sockets and Socket APIs
As mentioned earlier in the chapter, the port number is an application identifier that links the Application
layer to the Transport layer. However, because multiple users can run the same application, the
identification of a unique connection requires additional information. The Transport layer creates a
unique connection via a socket, which is the port number plus the IP address. The combination of the
sending socket plus the receiving socket provides a unique identification for every connection.
However, if both the sending host and receiving host use the port number defined in the services file,
then multiple connections between two hosts for the same application (for example, two FTP
connections) results in identical socket pairs. To solve this problem, the source port number is some
unique number not related to the services file. This number depends on the particular implementation.
For example, UNIX-based TCP/IP uses the process number for the source port number because the
process number is always unique. This scheme guarantees the uniqueness of any socket pair. Figure 1.20
illustrates how sockets work.
Figure 1.20 : A session established using sockets.
The Transport layer keeps track of these socket pairs by storing them in a port table. Although this
device solves the technical problems, the use of socket APIs hides the details of the interface from the
programmer.
In 1981, BSD introduced UNIX BSD 4.2, which contained a generic socket interface for UNIX-to-UNIX
communications over networks. In 1986, AT&T introduced the Transport Layer Interface (TLI), which
provides a stack-independent interface. UNIX SVR4 provides both TLI and the Berkeley socket
interface. For Microsoft Windows, the WinSock is the socket API and follows the Berkeley socket
interface standard. Novell adopted TLI as the standard interface to the Transport layer, although NetWare
also supports NetBIOS, Named Pipes, and sockets. As part of the revised SNA standard, IBM introduced
the Common Programming Interface for Communications (CPI-C) as another API standard for network
communications. With different APIs on different platforms, true portability of software is still an elusive
goal. Nevertheless, using an API simplifies the task of writing network software.
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (25 of 27) [4/22/1999 3:57:19 PM]
Applications, Plug-Ins, and Applets
Not too long ago, programmers developed applications; now they develop applications, plug-ins, and
applets. Although a program is a program, the name attached to it tells us something about the nature of
the program. Alas, there are more gray zones than black and white ones. In spite of this overlap, some
well-defined characteristics separate applications, plug-ins, and applets.
Starting with an application, the common characteristics are that:
It is a standalone program. l
A desktop program, including Web browsers, invokes an application in a separate window. l
An application normally implements a specific application protocol such as FTP, telnet, or SMTP. l
On the other hand, a plug-in's characteristics are that:
It represents an extension to a Web browser. l
It implements a specific MIME type in an HTML document. l
It normally operates within the browser window. l
And then we have the Java applet. Is it a "small application," or is it something else? A Java applet
Is written in the Java language and compiled by a Java compiler l
Can be included in an HTML document l
Is downloaded and executed when the HTML document is viewed l
Requires the Java runtime to execute l
Whereas applications and plug-ins must be ported to each hardware platform, applets run on any
platform that has a Java runtime. Thus, applets provide an object-oriented, multiplatform environment for
the development of applications.
Summary
This chapter provided
An overview of the major events in the history of the Internet, networks, and intranetworks l
A review of the TCP/IP protocol stack and the most important protocols l
A brief look at Ethernet and token ring networks and the associated LAN technology l
A survey of current intranetworking protocols and an introduction to the principles of routing l
A short synopsis of the characteristics of client/server architecture and its relationship to TCP/IP l
A thumbnail sketch of sockets and a summary of the major socket APIs l
A list of features that distinguish applications, plug-ins, and applets l
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (26 of 27) [4/22/1999 3:57:19 PM]
Chapter 1 -- An Overview of Internet Programming
http://docs.rinet.ru/WPU/ch1.htm (27 of 27) [4/22/1999 3:57:19 PM]
http://docs.rinet.ru/WPU/f1-1.gif
http://docs.rinet.ru/WPU/f1-1.gif [4/22/1999 3:57:28 PM]
http://docs.rinet.ru/WPU/f1-2.gif
http://docs.rinet.ru/WPU/f1-2.gif [4/22/1999 3:57:52 PM]
http://docs.rinet.ru/WPU/f1-3.gif
http://docs.rinet.ru/WPU/f1-3.gif [4/22/1999 3:58:02 PM]
http://docs.rinet.ru/WPU/f1-4.gif
http://docs.rinet.ru/WPU/f1-4.gif [4/22/1999 3:58:12 PM]
http://docs.rinet.ru/WPU/f1-5.gif
http://docs.rinet.ru/WPU/f1-5.gif [4/22/1999 3:58:17 PM]
http://docs.rinet.ru/WPU/f1-6.gif
http://docs.rinet.ru/WPU/f1-6.gif [4/22/1999 3:58:23 PM]
http://docs.rinet.ru/WPU/f1-7.gif
http://docs.rinet.ru/WPU/f1-7.gif [4/22/1999 3:58:38 PM]
http://docs.rinet.ru/WPU/f1-8.gif
http://docs.rinet.ru/WPU/f1-8.gif [4/22/1999 3:58:42 PM]
http://docs.rinet.ru/WPU/f1-9.gif
http://docs.rinet.ru/WPU/f1-9.gif [4/22/1999 3:58:47 PM]
http://docs.rinet.ru/WPU/f1-10.gif
http://docs.rinet.ru/WPU/f1-10.gif [4/22/1999 3:58:52 PM]
http://docs.rinet.ru/WPU/f1-11.gif
http://docs.rinet.ru/WPU/f1-11.gif [4/22/1999 3:59:03 PM]
http://docs.rinet.ru/WPU/f1-12.gif
http://docs.rinet.ru/WPU/f1-12.gif [4/22/1999 3:59:12 PM]
http://docs.rinet.ru/WPU/f1-13.gif
http://docs.rinet.ru/WPU/f1-13.gif [4/22/1999 3:59:17 PM]
http://docs.rinet.ru/WPU/f1-14.gif
http://docs.rinet.ru/WPU/f1-14.gif [4/22/1999 3:59:23 PM]
http://docs.rinet.ru/WPU/f1-15.gif
http://docs.rinet.ru/WPU/f1-15.gif [4/22/1999 3:59:30 PM]
http://docs.rinet.ru/WPU/f1-16.gif
http://docs.rinet.ru/WPU/f1-16.gif [4/22/1999 3:59:36 PM]
http://docs.rinet.ru/WPU/f1-17.gif
http://docs.rinet.ru/WPU/f1-17.gif [4/22/1999 3:59:43 PM]
http://docs.rinet.ru/WPU/f1-18.gif
http://docs.rinet.ru/WPU/f1-18.gif [4/22/1999 3:59:49 PM]
http://docs.rinet.ru/WPU/f1-19.gif
http://docs.rinet.ru/WPU/f1-19.gif [4/22/1999 3:59:54 PM]
http://docs.rinet.ru/WPU/f1-20.gif
http://docs.rinet.ru/WPU/f1-20.gif [4/22/1999 4:00:03 PM]
Chapter 2
WWW Design Issues
by Bob Breedlove
CONTENTS
You Don't Own the Resources
The Internet-More Concept than Reality m
Router Tables: The Internet "Glue" m
Domain Name Service: Helping the Humans Understand m
Client/Server Tools m
Internet Design Considerations m
l
You Don't Make the Rules
The Resources Can Be Unreliable m
Transaction Timing Is Unpredictable m
l
Designing Your Application
Design the Complete Application m
Determine Which Components Will Be Internet-Based m
Public Interface Components m
Multiple End-User Platform Requirements m
Timing Issues m
Connectionless Protocols: E-Mail m
l
The Internet Can Be Unreliable and Can Change Without Notice
Design an Alternative Delivery Mechanism m
Detecting and Reporting Failures m
Dealing with Disasters m
l
Security
Passing Through Multiple Machines m
Anyone with a Scope m
E-Mail Example m
Encryption m
Secure Web Servers m
Encrypting Sensitive Information m
Encrypting or Password-Protecting Documents m
Unsecure Request, Secure Response m
l
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (1 of 22) [4/22/1999 4:01:09 PM]
Verifying the Correct Client m
International Considerations
I Don't Think We're in Kansas Anymore m
Non-English Speakers m
Other Cultures m
Addresses and Phone Numbers m
Dates and Number Formatting m
Time Zones m
l
Summary l
Masses of people worldwide are tapping into the World Wide Web (abbreviated WWW or simply the Web), lured by
graphic interfaces and relatively inexpensive access to unlimited information. Many companies see these Web
residents as a ready-made pool of potential customers and are turning to the Web as the next great untapped market.
The Web can be an excellent infrastructure for your application. By infrastructure, I mean that the Internet can provide
a common transport mechanism and, through the Web browser interface, provide a well-known and familiar interface
to your application. This is especially true if you need to build an application that can do the following:
Enable your customers to place orders with you from remote locations via an online catalog l
Provide customer service support for your products l
Give your geographically diverse sales staff instant access to pricing information l
Open your products to an international market l
Enable your remote offices to access catalog information immediately and place orders with your home office l
Any of these requirements need telecommunications to achieve their goals. Most require that you program a graphical
user interface (GUI). And some, like online catalogs, require that you display pictures of your products. Before
jumping on the Web just because it's the hottest thing going, you might examine traditional alternatives for your
application, such as the following:
Distribution of catalog and other materials in hard copy via express services l
Customer service operations with human personnel answering questions via toll-free numbers l
Dedicated networks running custom or off-the-shelf client/server applications l
Dial-up operations, such as publicly accessible bulletin boards l
Distribution (via express services) of materials such as floppy disks or CD-ROMs containing your catalogs l
The Internet and the capabilities that it supports, such as the Web, offer advantages in ease of use, cost savings, and
immediacy of information. But before you rush off to get your company a set of Web pages, read on.
The public Internet can be a good choice for the infrastructure for all or part of your application, but when you
program for the public Internet, you face design issues beyond those for an application on a single computer or a
dedicated network. This chapter discusses these design issues and offers some guidance to help you produce viable
Internet applications, whether you're performing custom programming or programming for commercial Web
browsers.
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (2 of 22) [4/22/1999 4:01:09 PM]
You Don't Own the Resources
Designing applications for the Internet is challenging, first of all because you are designing client/server applications.
These types of applications are always challenging, but using the public Internet adds to this challenge primarily
because you don't control most of the infrastructure over which your application runs. To understand this issue, review
the following sections for a brief look at the Internet.
The Internet-More Concept than Reality
The Internet as we know it today is more a concept than a reality. Strictly speaking, the Internet really doesn't exist.
This statement might sound radical; after all, for something that's more concept than reality, a tremendous amount of
activity exists on it. To understand this statement, you have to look at what the Internet is-or, more precisely, what it
isn't.
The Internet is not a centrally owned or managed resource. There is no "Internet Committee," "Internet
Administrator," or "Internet Help Desk." As you see later in this chapter, naming and addressing are centrally
controlled of necessity, but that's about the extent of central control. So, if the Internet doesn't exist, how are all these
people doing business on it? What is it?
The Internet (with a capital I ) is a network of networks (an internetwork, or internet-small i ). In the most simple
terms, the Internet is a router-based TCP/IP wide area network (WAN) formed by the cooperation of independent
organizations. These organizations include
Public agencies such as the Defense Advanced Research Projects Agency (DARPA) in the United States, and
central government agencies in other countries
l
Network companies such as MCI, SPRINT, and AT&T l
Public, for-profit companies such as IBM and Microsoft l
Private, nonprofit organizations such as universities and colleges l
Other organizations l
These entities cooperate with each other by allowing "public" TCP/IP packets to pass through their resources (cables,
routers, bridges, computers) for the benefit of all concerned. These packets carry the information for your application
across the Internet. The whole thing is held together by router tables, as described in the following section.
Router Tables: The Internet "Glue"
Routers and bridges (generally called gateways) make an internetwork function. These devices are specialized
computers that use tables of addresses ("router tables") to tell how to get packets of information from one network to
another. These tables are maintained by some automatic processes (caching) and by human beings. Invalid router
tables can be one of the causes of failed transactions. Look at an example of how they work to get information around
the Internet.
My workstation is located on the local area network (LAN) at our building. When my company decided to become
linked to the Internet, the company's network naming group contacted the Network Information Center (NIC) to
request a block of addresses. They were assigned the address 198.132.0.0. Later, when our LAN was installed, we
requested a TCP/IP address from the corporate naming group and were assigned the address 198.132.57.0. When
my machine was added to the LAN, it was assigned this address: 198.142.57.4. TCP addresses are defined by a
set of 4 numbers separated by periods. Each number can have a value between 0 and 254. There are various classes of
addresses that define the meaning of the numbers. For your address class, the first three nodes of the address define
the network. (That is, given the address 111.222.333.444, 111.222.333 defines the network. The last number,
444, identifies the particular device on that network.)
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (3 of 22) [4/22/1999 4:01:09 PM]
When my Web browser needs to communicate with another computer, it uses the address of the computer to establish
a connection (socket) for communication. Suppose that I want to talk to a computer at 144.44.44.4. Because the
address isn't on my LAN, the request is routed to the LAN "gateway." This "router" has tables listing LANs about
which it knows. If it doesn't know about the specified LAN, it sends it to a default "gateway," and so it goes until it
finds the address. After the packets reach the gateway on 144.44.44.0, the router there routes the packets to the
machine whose address is 144.44.44.4.
Domain Name Service: Helping the Humans Understand
The Internet could operate entirely from these addresses; however, for humans, it's better to use names that are
meaningful. (It's the same reason that companies try for phone numbers that can be rendered as meaningful words.)
For example, www.microsoft.com is much easier and more meaningful than 198.105.232.6. These names
are often referred to as domain names. Internet addresses are divided into domains. For example, this address is in the
com (commercial) domain.
It's also easier on network administrators to use names. If the administrator has to physically move the machine
hosting your Web pages to another network or has to relocate the Web server to another machine, all he has to do is
change the name mapping after the machine or service has been relocated, and the machine is logically moved.
Incidentally, if you look up www.microsoft.com, you'll actually get three addresses-another benefit of domain
names. Domain name servers (DNS) provide these services based on naming standards and protocols that make this
possible.
In simplified terms, when you type in an address like this, the browser extracts the www.microsoft.com portion
of the address and formats a name request for the designated name server:
http://www.microsoft.com
The request causes the name server to return the correct dot-notation address (xxx.xxx.xxx.xxx) for Microsoft's
Web server. The browser then contacts the server on the designated port using the HTTP protocol and establishes a
socket connection to pass information. (Even www is probably an alias for the actual machine name. This system
enables the administrator to change the machine or map the name to additional machines-without having to notify
millions of Net residents that the name has changed.)
Client/Server Tools
When most of us think of the Internet, what we really think about are the tools that we use over the Internet-Web
browsers, Telnet programs, File Transfer Protocol (FTP) modules, news and mail readers, and others. As you will see,
these tools are client/server tools. That is, they consist of a piece of software on your workstation that requests
services of another piece of software on a computer in another location. These tools are made possible by wide
adoption of standards and protocols including the following:
Transmission Control Protocol (TCP) l
Internet Protocol (IP) l
File Transfer Protocol (FTP) l
Hypertext Transport Protocol (HTTP) l
Simple Network Management Protocol (SNMP) l
Simple Mail Transport Protocol (SMTP) l
Domain Name Service (DNS) l
Thus, when you "surf the Net," you really aren't connecting with some monolithic "Internet program." What you're
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (4 of 22) [4/22/1999 4:01:09 PM]
really doing is using a set of client/server programs to return pages of information from a server (the HTTP daemon)
to a client (the Web browser).
When you design an application for use over the Internet, you design a client/server application. Your custom
software can provide both the client and server portions of the application, or you can choose to use standard software
for either or both ends of the application. For example, you can choose to write the host (server) portion of the
application to be a Web server that can take advantage of any commercial Web browser available on the market. On
the other hand, you can choose to implement the host portion of your application as a Common Gateway Interface
(CGI) module, and use a commercial Web server to provide the routing to a commercial Web browser. In another
example, you can design an application using Java or another plug-in scripting language that utilizes commercial Web
browsers and hosts.
Whatever your application, you must be connected to the Internet to make it work. Figure 2.1 illustrates some typical
Internet connections.
Figure 2.1 : Typical Internet connections.
Many variations on this theme exist but, to simplify matters for discussion, assume that the client has a connection to
the Internet through an Internet service provider (ISP) from a local area network (LAN). The server (host) also has a
direct connection from its LAN to its ISP.
The most typical variation on this setup is for the client to have a dial-up connection over asynchronous modem to the
ISP. In essence, once connected, this variation is the same as the dedicated connection. However, it's usually much
slower than the dedicated connection-typically 9,600 to 28,800 baud versus 56Kb and up.
Whatever the connection, when you fire up your Web browser to access some information on the host, here-in
simplified form-is what happens.
You enter a particular address (a Universal Resource Locator or URL) into your Web browser. Your browser makes a
connection to your domain name service (DNS) to request a translation of the human-readable URL to a dot-notation
IP address for the host. Your DNS might have to request the address from other domain name servers to fulfill your
request, but assume that it returns the address successfully. (Of course, if this is your application and not a Web
browser, it has to deal with the case in which the address is not returned successfully.)
Your browser "client" requests a socket connection to the HTTP "host." This request passes through your router to the
ISP, and through its router(s) onto the Internet. Here it can pass through several other machines before it reaches the
host's ISP and eventually the host. Assuming that the host has the capacity, the socket connection is established
between your browser and the HTTP daemon running on the host. (A daemon is a program that runs continually on a
host. In the case of an HTTP daemon, it's looking for socket requests on a particular port-typically port 80).
Your browser then communicates with the host, using the HyperText Transport Protocol (HTTP). The actual requests
and pages are created using the Hypertext Markup Language (HTML). The browser requests the particular page,
which is returned by the daemon. After the page has been returned, the socket connection is broken, and your browser
translates the HTML into the page layout that you see.
It is important to note that the connection is broken. That is, unless some mechanism is designed to retain information
either at the client (Web browser) or the server (Web server), the information is lost. The next time your client
application communicates with the server, it will be as if it had never communicated with that server before. Designers
often use cookies, which are stored on the client machine, or database records, which are stored on the server and
keyed by some information passed by the client, to track necessary information.
TIP
The fact that the socket connection isn't maintained throughout the
"conversation" is an important consideration in programming for the
Web.
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (5 of 22) [4/22/1999 4:01:09 PM]
Internet Design Considerations
Because Internet protocol (IP) addresses are used in the packet routing process that is at the heart of the Internet, they
can't be allocated in a random fashion. Network naming and addressing is controlled by the Network Information
Center (NIC), but it's really the only thing that is centrally controlled.
NOTE
The NIC is currently managed by Network Solutions, Inc., located in
Chantilly, Virginia. To download information, access
ftp://rs.internic.net/ via anonymous FTP.
Each segment of the Internet is controlled by the organization that owns the resources. That organization makes the
rules for that segment. Each organization makes bandwidth available to pass IP packets through their routers and
along their network. They can place restrictions on the use of these resources. Your packets will potentially pass
through several machines, routers, and other devices that are owned and controlled by someone else.
You Don't Make the Rules
As stated earlier, you don't own most of the resources over which your application will operate. Because you don't
own the resources, you don't make the rules. This means that you have to abide by the rules established by others-for
completely different reasons than the objectives of your application. This situation can result in such unwanted results
as finding that the user's ISP restricts the size of messages it forwards, or that your customers can't reach your home
page because a name server is down for maintenance.
The point is that, when you run your application over the Internet, you can't complain to some central authority when
something goes wrong. Of course, you can complain to your network administrator about your local resources or to
your ISP about your Internet connection. But, aside from that, you have to take what you get.
In fact, sometimes the problem is finding out what the rules are. When a transaction fails, often there is no indication
of the reason. Luckily, organizations supporting the Internet operate within broad guidelines and standards.
Despite this problem, the whole thing seems to operate pretty well for the most part. However, you should keep in
mind the points in the following sections as you design your application.
The Resources Can Be Unreliable
You might design, develop, and test your application over one path that exists because of some organization's
resources. The application runs great. Then you find out that the organization has gone out of business or decided not
to carry Internet , and your path to your end user suddenly changes-with negative results for your application.
You might also find that resources are temporarily unavailable. A domain name server might be unavailable during a
critical period of time for your business, like month end, because the host machine is undergoing maintenance during
that period. A particular host can be overloaded on Fridays or at the end of the month because it's carrying from
its organization's month-end processing.
It's critical to remember that the owners of resources can do anything they want with their resources. They can change
their maintenance schedules, move domain name servers, modify bandwidth, and more-all without consideration for
your application. After all, they run their systems primarily for their benefit. They make decisions based on their
business plan and system designs, not yours. Later in this chapter, you see how to design your application to take all of
these factors into account.
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (6 of 22) [4/22/1999 4:01:09 PM]
Transaction Timing Is Unpredictable
Because you can't control the resources on the Internet, you can't guarantee the timing of your transactions. An
interaction that completes in a matter of seconds one time can take several minutes the next time-the next day, your
application might not even be able to make the connection. For this reason, timing-critical transactions should not be
placed on the public Internet.
CAUTION
Don't place timing-critical applications on the Internet.
Designing Your Application
To this point, this chapter has discussed several issues facing applications intended for the public Internet. It probably
seems that you're at the mercy of other organizations and the whole thing is unreliable enough that you might as well
give up. Perhaps you are and perhaps it is, but applications are running successfully on the Internet. And the capability
to reach a whole world of potential customers is driving Internet development at a staggering pace.
TIP
Good system design and development techniques still hold for
Internet applications. Planning is the key to a successful application.
The key is to plan for the Internet environment just as you would if you were designing this application for your own
network or private TCP/IP network (intranet). As you see later in this chapter, good system design and development
techniques still hold for Internet applications. You just have to plan for some of the idiosyncrasies of the medium. The
remainder of this chapter examines what you can do to design your application for the Internet.
Design the Complete Application
Following a good system development methodology is still the best way to design for the Internet. Starting with
requirements definition, through business design and into detailed technical design, construction, and testing, the
Internet portion of your application must be designed just as you would design any other modules in your application.
The decision to use the public Internet for your application must be made based on business reasons. After all,
alternatives to the Internet do exist:
Build/use a private network (intranet) l
Allow direct dial-up access l
Use an existing online service, such as CompuServe or America Online l
Each of these options has advantages and disadvantages that must be considered. Private networks are reliable and
secure, but very expensive. Direct dial-up access provides an alternative for users who don't require full-time access to
your application. Online services can provide easy access for users who might already be members of the service, but
they can be expensive for your users and are not as secure as private networks.
And, of course, some applications aren't appropriate for the Internet, or simply won't run over the Internet. For
example, applications requiring results in real time aren't appropriate, and applications requiring extra security (such
as personnel applications) are probably inappropriate because of security concerns.
If you consider the use of the public Internet from the beginning of your project, you won't be caught by the surprises
that can result from use of the public Internet. Many of these considerations can be complex and can take a good deal
of planning or preparation to integrate into your application.
For example, if you plan to have a special domain name for the public to access your application, you must request it
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (7 of 22) [4/22/1999 4:01:09 PM]
from the NIC. This process can take some time. You might have to reconfigure your routing tables to accommodate
the machines on which your application will run. You might have to deal with corporate firewalls (special-purpose
computers that isolate corporate networks from the general Internet) and other corporate standards to implement your
application. The time that these issues take needs to be integrated into your development plan. (See Chapter 4
"Developing Intranet Applications," for more details about dealing with intranet considerations.)
Determine Which Components Will Be Internet-Based
Not all components of your application can be Internet-based. Early in your application design, you need to determine
which modules of your application will be Internet-based. Because the timing and security are major issues of using
the Internet, modules requiring strict security or where timing is critical should not be implemented on the Internet.
The remainder of this section examines modules that might be considered for Internet implementation.
Public Interface Components
Modules of your application permitting public access are natural candidates for the Internet, for several reasons.
By designing an interface that enables your users to take advantage of tools they already know, you can avoid the
training issues that could result from requiring users to learn proprietary programs and new interfaces. The users of
your system probably already know how to access the Internet by using their Web browsers, mail and news readers,
and File Transfer Protocol (FTP) clients. Introducing your new screens, new addresses, and new filenames is an
incremental change in known procedures for your potential users. This setup can make your system less intimidating
for potential users and can be especially important if you are designing an online ordering or customer service
application.
Multiple End-User Platform Requirements
Applications are often implemented into existing infrastructures. To avoid excessive costs, you might have to
accommodate existing end-user platforms. In many companies, this is a mix of PC, Macintosh, and UNIX
workstations. You also might want to accommodate customers' equipment and software. Internet tools enable you to
reach a wide variety of customers using any type of equipment.
For example, a Web browser is an excellent choice for a client/server application over the Internet. When you write
for Web browsers, you can eliminate the need to consider the hardware platforms on which they're located. The
Netscape browser, for example, runs on PCs running Microsoft Windows, on the Apple Macintosh, and on various
UNIX platforms running X-Windows. Other Web browsers are also available, such as lynx, a text-based browser, the
Microsoft Internet Explorer, and browsers supplied by online services such as CompuServe and America Online
(AOL).
Writing applications that create Web pages (generate HTML) is relatively simple. Formatting forms (screens) is also
relatively simple. However, you need to take the points in the following sections into account.
Choosing a Browser Versus Writing for All Browsers
Hypertext Markup Language (HTML) is derived from Standard Generalized Markup Language (SGML, formally
called ISO 88791) used in the publishing industry. HTML, together with URLs (Universal Resource Locators) and
HTTP, is one of the foundations of the World Wide Web. There have been two revisions of the HTML standard (1.0
and 2.0). However, two major players in the Web browser marketplace-Netscape and Microsoft-have defined
extensions to this standard that have become very popular. Netscape's version 2.0 browser, in particular, implemented
several very desirable features that other browsers don't support. Since then, Microsoft and Netscape have both
released version 3.0 of their respective browsers, which have further diverged from each other. Because of the
installed bases of these browsers, the extensions they have implemented are a de facto standard when writing HTML.
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (8 of 22) [4/22/1999 4:01:09 PM]
Other browsers used on alternative platforms and through various online services might not implement these
extensions. Still other browsers are text-based, and don't support many of the graphics that have become so popular on
the Internet. Lynx is one of these browsers, implemented for UNIX shell accounts for many Internet service providers,
because they provide only a text interface for the user.
To use browsers at the desktop (client), you are faced with a choice in designing your application: You can write for a
particular browser, such as the Netscape or Microsoft browser, or a set of browsers that implements a particular
standard or pseudo-standard. Or you can write your application so that a wide range of browsers can take advantage of
the application. These are the issues involved in making the choice:
If you choose to write for a particular browser, be aware that you are potentially limiting the market for your
application and whatever profits are attached to that application.
l
If your application requires the use of special features of a particular browser-for example, the frame capability
of the Netscape 2.0 browser, or the Java applets implemented in a number of browsers-you must write for that
browser.
l
You can choose to write for a particular browser if you have control of both ends of the application. For
example, if you are building an application for your field sales force, you will probably provide them with a
standard browser, even if they are running on different platforms.
l
If your application needs to reach the widest possible audience, you probably should choose either the HTML
1.0 or HTML 2.0 standard and stick with it in designing your pages.
l
When you are using an HTML standard, keep in mind that some of your audience might be using text-based
browsers or have graphics turned off. You might want to provide text-only versions of the pages you design,
and you should always provide alternatives to image maps. Graphics used as links should use the ALT keyword
to provide a non-graphic alternative to determine where the link leads. For example, you can provide a set of
arrow buttons to go from page to page in your application. A person with a text-only browser or with graphics
turned off wouldn't have the slightest idea what these buttons meant. To avoid this problem, code the following:
l
<IMG SRC="..." ALT="[INDEX]">
<IMG SRC="..." ALT="[NEXT]">
<IMG SRC="..." ALT="[PREVIOUS]">
Although the image source (SRC) can be an icon with an arrow, text-based browsers will ignore it, and it won't
be visible if graphics are turned off. The alternate keyword (ALT) displays text in place of the graphic to enable
users without graphics to continue to use your screens.
l
Not all browsers support forms. If you are taking orders via the Internet, you might want to provide an
alternative method such as mail for those customers with browsers that don't support forms.
l
More WYSYMNG than WYSIWYG
WYSYMNG stands for What you see, you might not get. Programming for a Web browser is much like programming
for X-Windows. That is, you can "suggest" what the screen will look like by programming HTML directives such as
bold (<B>) or heading 1 (<H1>), but you really don't have control over the total look of the final product on a
particular user's browser.
You can spend a lot of time on page design to make your application user-friendly and appealing to your clients, but
differing equipment and software can cause the best page to look ugly and sometimes become just barely usable.
Also, remember that the Internet is a public medium. If your application will be used by consumers, they have a lot of
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (9 of 22) [4/22/1999 4:01:09 PM]
really "cool" pages with which to compare it. You have a lot of competition; your pages have to look their best to
attract and keep the attention of the customer.
Your pages might not turn out as you planned, for several reasons:
Users can define the type styles to be used on their browsers. One user might define 10-point Helvetica; another
prefers 12-point Arial or Courier.
l
Aspect ratios of screens on various platforms differ. Your screen will look different on a 640´480 Windows
screen than on a 1760´1280 X Window screen or on a Macintosh.
l
The number of colors supported by the user's equipment can affect the look of your page. Not everyone has
equipment that supports thousands or millions of colors.
l
A feature supported by one browser can look terrible when viewed with another browser. l
In addition to what's in the foreground, consider the backgrounds and choice of colors. Colors that appear
reasonable on one platform can be garish on another. Also, some colors might become unreadable if you place
your logo as the background of a page.
l
Testing is the key. Test your pages on a reasonable number of configurations. If you're writing for commercial Web
browsers at the client end, test for the major programs, at least. This means that you will probably test with Netscape
Navigator and Microsoft Internet Explorer. Also test with the various hardware platforms that you anticipate.
A good pilot or beta program can help you flush out any difficulties resulting from the differences in equipment and
software. Encourage your testers to go a little wild with their settings and get as many varied looks at your final
product as you can.
You should also design your pages so that they appear reasonable on a large number of screens. Choose a standard
aspect ratio and design for that. For example, you might choose 640´480 as your typical screen size. This is a
reasonable setting if your application will be accessed by the general public, because it's the smallest of the ratios you
need to consider.
If your application sends graphics-and what self-respecting Web page doesn't?-don't use graphics that span the full
screen width. Remember, you also need to contend with scrollbars and the fact that your user might not run his or her
browser on the full screen. A general rule of thumb is to keep graphics to 480 wide (about 75 percent of the screen
width) at the most. Of course, if you're programming for standard, known equipment and software, you'll know a set
number of screen sizes.
Another problem with large graphics is their transmission time. The old adage "a picture is worth a thousand words"
applies here. In the English language 1,000 words is about 6,000 characters. At 14,400 baud, these words would take a
little more than four seconds to transmit. If you substitute a graphic that is, say, 24,000 bytes, it could take about 17
seconds. This length of time can turn off some potential customers. You might want to consider the value of the
graphic and, perhaps, reduce its size or substitute words.
Text paragraphs are relatively unaffected by the size of the screen. However, remember that HTML paragraphs wrap
at the borders of the browser screen or the table. You have no control over that aspect of your application. Also, text
positioned by graphics using the LEFT, RIGHT, and CENTER directives can appear different (or wrong) with some
screen sizes. Be sure to check the graphics on different screens to make sure that your layout isn't affected.
Maintaining Information Across Transactions
One important aspect of writing for the Web is that information about total transaction between the client and host-the
"conversation"-isn't maintained across parts of the conversation. In a client/server application across a dedicated
network, a socket connection is established at the beginning of the conversation and continues until the work is
completed. The client and host track the information (often in memory) while the connection is in progress, because
they're dealing with a known entity at the other end of the socket connection the entire time.
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (10 of 22) [4/22/1999 4:01:09 PM]
This isn't the case for Web transactions. Socket connections are maintained only for the length of a single send/receive
exchange (transaction). That is, when the client sends information to the server (say a URL) and the server responds
with information (a Web page), a socket connection is established and then broken. Information regarding the
transaction is not maintained for the next send/receive transaction unless you specifically program for it.
This process is a lot like having a conversation with someone with a very short memory. You say something to him
and he responds, but the next time you say something to him, he doesn't remember your first exchange. You have to
keep filling in the details from previous exchanges to keep your partner up to date. In addition to this problem, the
host might be carrying on thousands of transactions with other clients simultaneously. The point to remember is that
you have to carry all information about the conversation with you. A couple of methods are available.
First, you can hide information on the screen (page) sent to the client. HTML provides an input type for this-hidden.
Hidden information doesn't appear on the page, but is returned like any other input field. You might want to hide
sequence information or other identifying information that will be used by your application to retrieve data records.
Hiding information on-screen is risky, especially if it's confidential. Most browsers support the capability to examine
the source code for the page. Any user taking advantage of this feature can see your hidden information. You might
want to encrypt sensitive hidden information.
An alternative is to save the conversation information at the server. Send a "key" to the client, either as a display
element on your page or as hidden text. When the client returns the form, use the key to retrieve information about the
conversation. This alternative is more secure, but has the disadvantage of leaving information on the server for
transactions that aren't completed. For this reason, you might need to devise a cleanup routine that can run periodically
to eliminate these incomplete transaction segments.
Some Web browsers implement information packets called cookies as a mechanism to store information about a host
directory tree. Cookies can be used to store key information that can later be used to retrieve information stored on the
host. See the later section called "Security" for details about cookies.
Timing Issues
As mentioned, timing can be a problem on the Internet. You don't know from one time to the next whether completing
the transaction will take several seconds or much, much longer. For this reason, timing-critical portions of your
application should not be Internet-based.
Consider timing not only in terms of programs, but also in terms of the tolerance of human beings to timing issues.
For example, you might not want to rely on the Internet for a customer service system where your customer service
personnel are on the phone with disgruntled customers. The response time of the Internet is, at best, unreliable. A Web
page can take one second to display one time and several minutes another time. You don't want your disgruntled
customer hanging on the phone while your customer service personnel are waiting for the page in the later case.
Detecting and Recovering from Failed Transactions
If your Web browser doesn't receive a response from the Web server in a specified length of time, it will time out and
notify you that the server is unavailable. Timeouts are difficult to manage in client/server applications across your own
infrastructure; they're more difficult when you are dealing with the Internet. You must include code to determine that
the transaction has failed and recover from this condition. Because of the unpredictability of transaction durations over
the Internet, you can't reliably test the expected duration of a particular exchange. The question is, how much time is
too much time? When can you determine that your application has failed?
The design of your application affects the way in which you determine timeouts. If your custom programs run each
end of the client/server connection, you can control timeouts and recovery more precisely. If you are using
commercial products for one or both ends of the connection, however, things are more difficult.
Commercial Web browsers have timeout settings built in. If your client is using one of these programs, it will time out
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (11 of 22) [4/22/1999 4:01:09 PM]
after a length of time, but it will time out on the basis of the manufacturer's standards-not yours.
Handling Retransmissions Caused by the Back Button
One problem you face related to timeouts is the use of the "Back" button and retransmission of the same transaction to
the host. If your client is using a browser, you can't control this occurrence. The user can go back to your screen and
resubmit it as many times as he wants. He really doesn't intend to submit multiple transactions; if he's impatient or
doesn't receive a "reasonable" response, he just feels that the transaction has somehow failed and attempts to resubmit
it.
You help prevent the problems caused by these multiple transactions in several ways. First, provide meaningful
feedback to your client. Make sure that the screen you return contains enough meaningful information to assure the
client that he has successfully completed the transaction. Also, give the client a button to take him somewhere, such as
to your home page or to another logical page. This option gives him an alternative to the Back button and can go a
long way to mitigating this problem. Some browsers now support page refresh generated by the server. Using this
option can be effective for a long-running transaction, but it limits the choice of target browsers.
Also, you can serialize your forms by using the TYPE=HIDDEN parameter of the INPUT field type. As the server
program receives a transaction, it records the serial number and prevents another transaction with the same serial
number from being posted. If the client submits a second transaction with the same serial number, use a gentle
reminder screen to tell him that you've already received and posted the original transaction.
Connectionless Protocols: E-Mail
Some protocols are unreliable. A major example of this is e-mail. E-mail is ubiquitous, and is thus an excellent choice
for some types of applications where universal access to your customers, employees, and other resources is a
consideration.
With very few exceptions, everyone who is on the Internet has e-mail. And through connections to other networks, the
use of uucp (Unix-to-UNIX Copy), and interfaces to other mail systems such as corporate mail systems, you can
reach even people who are not on the Internet.
There are many examples of the use of e-mail in applications:
A mailing list to send out bulletins or product information to your registered customers l
E-mail access to your help desk personnel l
Automatic response systems to product inquiries l
Verification of order entry can be by e-mail l
Automated notification by e-mail of some update event in your application l
But there is one major consideration in the use of e-mail. Because e-mail is a "store and forward" protocol, you aren't
guaranteed delivery. Here's how it works. You send e-mail to a customer. The message is stored on your computer.
The mail system examines the address and determines that it is not local. The message is then forwarded to another
computer indicated as a mail forwarder in the local mail configuration. That machine repeats the process and passes
on the message if it is not for its local mail system. The process continues from machine to machine until the message
is delivered or some "fatal" error is encountered. This process can take seconds or days. In some instances, the mail
cannot be delivered and it is returned to you.
Your application must be able to deal with this returned mail. First, it must be able to identify it, and then it must be
able to do something with it. One consideration is that this mail can take several days to return to the system. Because
handling this mail can be tricky, the most typical action is to forward the mail to some human's mailbox for him or her
to deal with.
One problem can be a loop created in automated mailing lists when a message is returned to the list mailbox and
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (12 of 22) [4/22/1999 4:01:09 PM]
interpreted as a new request, to which the original information is returned, which is then rejected and returned to the
mailbox and interpreted again, and so on. You get the idea. This can be avoided by adding a return address that is not
the address of the mailing list. For example, make the return address some human's mailbox and let that person deal
with the complexities of this situation.
The Internet Can Be Unreliable and Can Change Without
Notice
A program designed for a single computer or for use on a local area network (LAN) or dedicated wide area network
(WAN) is guaranteed some specific set of resources (bandwidth, central processor usage, and so on), which results in
reliable operation. With some certainty, in these situations, your application will operate much the same in terms of
response time from day to day.
This is not necessarily the case with the Internet. Because there is no central control of the public Internet, it can be
unreliable. Machines can be pulled out of service, networks can be reconfigured, addresses can be changed, and more,
without notice. In addition, the number of people "surfing" the Net is increasing exponentially, causing delays and
even failures of some parts of the Net. The time of day and day of the week can be a factor. Also, the use of automated
programs such as "spiders," which search the Net in a much more intense way than humans, and the introduction of
poorly designed programs that consume way too much network resources add to the situation.
How do you predict what the impact of Internet use will be on your application? Of course, the best way is to test a
prototype of your application at all the times you expect it to be used. A wide area, public beta test can tell you
something about timing and reliability, but predicting all the problems you will face is probably impossible. Short of
this, here are some thoughts.
Make sure that your application is hosted on a machine that won't be overburdened. Also, make sure that the
connection between the machine and the Internet is sufficiently fast to permit reasonable access and response times.
For most commercial applications permitting public access, a T1 connection is recommended. Note, however, that T1
connections might be prohibitively expensive for many small businesses. In this case, you might want to consider
renting space for your Web application on a machine at an Internet service provider (ISP) with adequate bandwidth to
support your application. Depending on your area, you might also have access to ISDN phone lines. These can be a
viable alternative to the faster T1 connections. However, even these can be expensive.
Design an Alternative Delivery Mechanism
If you're placing part of your business on the Internet, designing an alternative to your Internet-based application can
be critical. This factor can be especially important if the application is designed to secure sales for your business.
When you place a sales application on the Internet, you place at least a part of your profits at risk of the unreliable
nature of the transport medium. Here are a couple of considerations:
You also risk at least part of your business if you design your application to be accessed by your (potential)
customers. If you allow customers to order your products online, or you base part of your customer service
strategy on an online application, you take the chance that your customers will get a bad impression of your
business from a failure of the Internet.
l
You also risk part of your business if you design an Internet application to be used by your sales or field support
staff. Imagine a sales representative at an important customer's site, unable to reach your Internet Web page to
show your product.
l
To avoid losing sales from these situations, design alternative methods for your customers and field staff to access
information, place orders, or obtain customer service response. Here are some ideas:
In your media advertising (print, radio, television, direct-mail) include all sources for ordering your products. l
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (13 of 22) [4/22/1999 4:01:09 PM]
Provide customers with a toll-free order number that allows customers to order the same products found on your
Web page.
l
Provide fax-back service that allows customers to receive your catalog pages in hard copy form. l
Provide a telephone number for your remote staff to dial in to your server directly via SLIP or PPP. l
Provide a CD-ROM version of your online catalog for your sales staff. l
In short, don't leave your customers with no way to place an order or get support except the Internet. Because you
don't control the Internet resources, you can't guarantee delivery.
Detecting and Reporting Failures
So when does your application decide that a particular transaction has failed? This depends a great deal on whether
you control both ends of the transaction. Let's look at a typical situation.
Figure 2.2 depicts a scenario in which you don't control the timeout at the client (browser) end. The browser will
implement some timeout function and will usually return some standard error to your user, but how does the host
determine that a transaction has failed? In addition, your host application might never respond to the customer. This
can be for one of many reasons, including failure of your application, failure of the network, or an error on the part of
your customer in operating his browser. To your customer, these errors all appear the same-as a failure of your
application. Whatever the reason for the timeout, you need to deal with the consequences in your application. You do
not want to compound the problem by sending the customer something he did not want. For this reason, you might
want to implement some confirmation into your application as shown in Figure 2.2.
Figure 2.2 : Your host program with output to a Web browser.
In this example, your customer is ordering online. To make sure that the transaction has completed successfully, you
might want to have one final confirmation after the order has been placed. That is, your customer fills out the order
form and transmits it to the host. The host processes the order and sends a confirmation back to the client with total
cost and a confirmation number. The client is required to confirm the order. When the host receives this confirmation,
the transaction is complete and the customer is sent one final message.
This scenario will vary when you have custom programs at each end of the transaction or create a transaction using
Java applets. However, the principle of confirming that a transaction was received still applies.
Dealing with Disasters
All systems need disaster recovery plans, but when you design a system for the Internet, the fact that you don't have
control over most of the Internet's resources makes recovery more difficult. Disasters can range from simple power
outages to parts of the Internet being out of service due to natural disasters such as floods, hurricanes, and so on. Your
disaster recovery plan must deal with the fact that you might have no control over the recovery of Internet resources.
Your application is completely dependent on some other organization, and while that organization is dealing with the
problem, you can be out of business.
Of course, if your resources are the ones that are involved in the disaster, you need to have plans for an alternative
infrastructure. Here are a couple of ideas for designing your application that can help when you lose all or part of your
local infrastructure:
Use an alias to name the machine on which your server is located. For example, most Web servers are named
www.something (even though the machine really isn't named www). With this strategy, if you lose this server
or have to relocate your application you can restore the application on another machine, set that machine's
nickname to www, update your domain name server, and you're back in business. Your domain administrator
can set up this alias for you.
l
NOTE
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (14 of 22) [4/22/1999 4:01:09 PM]
Machine "nicknames" can also be a good technique to enable you to
switch your application to a new machine or run it on multiple
machines during standard operation.
If possible, host your application on multiple machines with different Internet service providers. At a minimum,
make arrangements with a service provider to host your application in the event that disaster strikes your base
machine. Also, plan how you will notify users of the (temporary) name change for your application before you
need it.
l
Security
Security is a major issue with the Internet because it is public domain. The public nature of the Internet can cause
security concerns that don't exist for private intranet or dial-up applications. Because packets pass through machines
over which you have no control, someone can potentially see confidential information. Any hacker with a network
datascope can get credit card numbers, Social Security numbers, and other confidential information from your
transmissions. You need to design for these potential security leaks.
Passing Through Multiple Machines
Your transactions have the potential to pass through many computers and other devices on their way between the
client and the host. On most UNIX systems, you can issue the traceroute command to see this routing. Most of
these machines are acting only as routers, but they're points where your signal can be intercepted and decoded. Here's
a look at the number of "jumps" that it takes to get from my account on Netcom to another computer run by the
Channel 1 BBS. (The command issued was traceroute user1.channel1.com.)
traceroute to user1.channel1.com (199.1.13.9), 30 hops max, 40 byte packets
1 netcomgw.netcom.com (192.100.81.254)
2 f0-0.netcomgw.netcom.net (163.179.1.1)
3 t3-1.scl-ca-gw3.netcom.net (163.179.220.194)
4 sl-mae-w-F0/0.sprintlink.net (198.32.136.11)
5 sl-stk-6-H3/0-T3.sprintlink.net (144.228.10.45)
6 sl-ana-2-H4/0-T3.sprintlink.net (144.228.10.26)
7 sl-ana-1-F0/0.sprintlink.net (144.228.70.1)
8 sl-fw-6-H2/0-T3.sprintlink.net (144.228.10.29)
9 sl-fw-3-F0/0.sprintlink.net (144.228.30.3)
10 sl-channel1-1-S0-T1.sprintlink.net (144.228.33.34)
11 user1.channel1.com (199.1.13.9)
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (15 of 22) [4/22/1999 4:01:09 PM]
Don't worry about the format of this display. The important point is not the details, but the fact that my information
passed through ten devices other than the originating machine (not shown on this route printout) and the destination
machine (user1.channel1.com). If you are at all concerned about security in your application, this situation
should concern you.
Anyone with a Scope
Anyone with a scope on any of the devices through which your information passes can trap that information. Things
like Social Security numbers (999-99-9999) and credit card numbers have patterns that can be detected by automated
search programs. An unscrupulous person can place one of these programs on a device routing packets along the
Internet, let it work for a period of time, and then take a leisurely look at the data that it traps.
E-Mail Example
E-mail can be even more vulnerable to this type of piracy, because mail travels as plain text in a format that's easy to
read, and the full messages are stored and forwarded by post office machines. Although most of us don't like to look at
them, and many mail readers filter them, mail headers can tell you a lot about the machines on which your mail rests.
Take a look at a message header:
Received: from ns2.eds.com by mail5.netcom.com (8.6.12/Netcom)
id NAA01582; Wed, 24 Jan 1996 13:21:17 -0800
Received: by ns2.eds.com (hello)
id QAA07685; Wed, 24 Jan 1996 16:21:40 -0500
Received: by nnsp.eds.com (hello)
id QAA26247; Wed, 24 Jan 1996 16:19:58 -0500
Received: from target2.sssc.slg.eds.com by dsscsun1.dssc.slg.eds.com
(5.0/SMI-SVR4)
id AA00143; Wed, 24 Jan 1996 15:18:57 -0600
Received: from rfbpc (rfbpc.sssc.slg.eds.com [198.132.57.4])
by target2.sssc.slg.eds.com
Like the traceroute information presented earlier, the details of this heading information isn't important for this
discussion. The important thing is the fact that this piece of mail rested on four machines not under our control. At
each of these points, your message is simply part of a larger text file. Anyone with the proper security clearance (or
anyone who can hack into that machine and obtain that clearance) can read your message. The headings are read from
the bottom to the top:
The mail originated on my PC (rfbpc). l
The mail was passed to the post office machine on our LAN (target2). l
The mail was forwarded by our post office to our division's mail handler (dsscsun1). l
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (16 of 22) [4/22/1999 4:01:09 PM]
The division mail post office passed the mail to our corporate firewall (nnsp). l
The mail passed to the corporate post office outside the firewall (ns2). l
Finally, the mail was delivered to the post office on the Internet service provider (mail5). l
Incidentally, the mail passed through several machines that aren't listed in this heading. Remember that
traceroute? Mail packets have to pass through several machines on which they don't rest, making them vulnerable
to snooping.
What does this mean to your application? If you're passing sensitive, private, or confidential information, consider
encryption for your application.
Encryption
Many types of encryption can be used to protect your transactions. Several Web browsers and hosts are "secure" in
that they encrypt information passing between them. The extent to which you want to use encryption in your
application will depend on the sensitivity of the information and the cost of encryption.
Of course, if you are writing your own application in which you will provide both the client and server modules, you
can provide your own custom encryption schemes.
CAUTION
One caution about using encryption such as that used by products like
Pretty Good Privacy. These schemes are controlled by the U.S.
Federal Government, which has some restrictions against exporting
encryption technology overseas. Be sure to check out this issue before
committing your application to specific technology or standards.
Secure Web Servers
If you are designing an application that will be hosted by a Web server, consider placing the application on a secure
Web server. These servers establish a secure connection with the client browser and encrypt all information that
passes between them. The Netscape Commerce Server, for example, uses Secure Sockets Layer (SSL) to encrypt
pages during transmission.
Encrypting Sensitive Information
Even if you choose not to encrypt entire transmissions, never send an unencrypted password, Social Security number,
credit card number, or other sensitive information over the Internet. This data can be encrypted easily by the host CGI
interface program, even if you implement your program using a commercial Web hosting program. Implementing
encryption at the client end of the application is more difficult if you don't rely on the encryption capabilities of the
commercial server/client. Java or some other plug-in application needs to be used to encrypt the sensitive information
prior to transmission.
Encrypting or Password-Protecting Documents
If you are going to transmit documents over the Internet, such as word processing documents, you can use the
capabilities of the applications that create the documents to encrypt or password-protect the documents. For example,
both Microsoft Word for Windows and Microsoft Excel can provide file-sharing passwords that must be entered
before a document can be accessed.
You might also want to use the capacity of compression programs such as PKZIP to password-protect files they have
compressed. With this system, even if some hacker manages to intercept a file, she will have to work hard to read it.
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (17 of 22) [4/22/1999 4:01:09 PM]
Following are some thoughts about using passwords:
Use the longest password you can to protect your documents. l
Don't use common words or phrases. They are easier to remember, but also easier to crack. Random
combinations of letters and numbers are best.
l
Change passwords periodically. That is, if you send several documents over a period of time, make sure that
you change the password at least every 30-60 days. This strategy lessens the chance that the password will be
compromised.
l
Don't send passwords over the Internet; transmit them via a secure means. l
Unsecure Request, Secure Response
In the case of especially sensitive information, you can allow requests to come to your application via the public
Internet. However, you might want to return the requested information via a secure medium. For example, you could
allow customers to request information via the Internet and then use fax-back facilities to fax the information to their
machines.
Verifying the Correct Client
Another difficulty in dealing with connectionless protocols is that you might need to verify that the client you are
talking to is the one you think it is. Luckily, some techniques are available, as described in the following sections.
Trusted Addresses
Your application might accept socket connections only from "trusted" TCP/IP addresses. Web browsers send the name
of the machine in the SERVER_NAME field and the address of the remote in the REMOTE_ADDRESS field. Be aware
that these fields can be faked, but they can be used in combination with user IDs and passwords to provide additional
security.
User IDs and Passwords
Your application might ask the client for a user ID and password. For applications with custom clients, the user ID can
be programmed into the client before distribution and the user can be required to enter a specific password to verify
her identity. In addition, you can limit user IDs to specific TCP/IP addresses and refuse to serve ID/address pairs that
don't match.
Cookies
If your application uses commercial browsers, you can take advantage of the capacity of some browsers-for example,
Netscape or Microsoft's Internet Explorer-to store information on the client machine; that information can be returned
to the server when a specific host path is requested.
CGI scripts can set data at the client's browser; this information is called a magic cookie. When a browser makes a
request for a page, it sends its cookie (if it has one set) to the server along with the request. If this is the first time that
this particular machine has been used to access your application, it will need to set default configurations or provide a
form on which the customer can provide required information.
A magic cookie is made up of several parts:
URLS for which the cookie will be sent l
PATH for which the cookie will be sent in the above host domain l
DATE when the browser will delete its cookie l
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (18 of 22) [4/22/1999 4:01:09 PM]
SECURE flag that tells the browser to send its cookie only if it has a secure connection to the server l
TIP
Cookies can also be a convenient way to customize your application
for a particular client; for example, when you are transmitting a page
in a foreign language for international clients. Once a customer has
visited your site, you can recognize the customer from his cookie, and
automatically customize the page returned to him.
Using this capability, you could transmit a user ID to the client and then retrieve it on subsequent visits by this client.
You can match the returned cookie to security information entered by the human being on-screen as an additional
security precaution.
International Considerations
When you place your application on the Internet, the potential audience for your application becomes an international
one. You must consider the implications of this fact, especially if you are designing an application for public access.
I Don't Think We're in Kansas Anymore
Your audience might speak a different language and come from a different culture. Even if you program your
application in English, if the application will be used by someone in another country, you will have some linguistic
and cultural considerations. The title of this section is a good example. For anyone who has seen the movie The
Wizard of Oz, the meaning of the phrase "I don't think we're in Kansas anymore" is evident. For those who have never
seen the movie, the meaning is blurred. In this case, the heading means that you can't assume that the rest of the world
operates by the same conventions that you do in your part of the world. Be careful and always consider that the
Internet is an international medium, especially if you are expecting business from international clients.
Non-English Speakers
English has become the international language of business, but your application is likely to be visited by potential
customers who don't speak English or speak it as a second language. In designing your pages, avoid idioms that are
likely to be misunderstood by foreign English speakers.
NOTE
Pages in a foreign language can be important if you are targeting your
application to a specific country or culture. Be sure to use a standard
form of the language and avoid idioms that can be confusing in a
different country.
NOTE
If you expect a large number of customers, you might want to provide
alternative language versions of your pages. When you do, remember
that some languages are more wordy than others to express the same
thought. Here's an example from my wristwatch instructions:
English Spanish
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (19 of 22) [4/22/1999 4:01:09 PM]
The alarm time is set on a 12-hour
basis and indicated by the alarm hour
and minute hands that move
independently of the main time hands.
La hora de alarma se fija en la indicacin de
12 horas y es indicada por las manecillas
de horario y minutero de alarma que se
nueven independientemente de las
manecillas de hora principal.
These differences in the number of words required to express the same idea can affect formatting of your carefully
designed screens. Be sure to account for this problem if you choose to support multiple languages.
Also, make sure that you have your pages translated by a professional translator or, at the very least, a native speaker
of the language. Don't rely on automated translation programs. Often, the direct word-for-word translations aren't
accurate and will not be understood.
TIP
Remember the discussion of magic cookies in the "Security" section?
Cookies can also be used to store language information. That way,
when a customer returns to your pages, he is automatically routed to
the correct language version.
Languages vary by country. For example, the Spanish spoken in Mexico varies somewhat from the Spanish spoken in
Spain. They use different words, tenses, and idioms to express the same thoughts. Spelling also differs from country to
country, even in English. Meter and civilization in the USA are metre and civilisation in England. So what should you
do?
Choose a standard version of the language, but be aware that some of the words used can differ by country. l
Don't depend on automated translations by programs; have a professional translator or native speaker of the
language perform the translation.
l
If the language supports a formal and informal mode of conversation, choose the formal mode. l
Avoid slang and other local idioms that are a part of every language. l
If you have any doubt that an expression will be understood, try for something more standard. l
Be consistent in your use of language. l
Other Cultures
When you are dealing with an international audience, you can't assume that they will have the same frame of reference
as you do in your country. Even if they speak your language, they might not understand local references or idioms that
might be common in your county-or even your part of the country.
Something else to consider is your use of graphics, icons, and colors. In Islamic cultures, it's inappropriate to depict
human figures in certain ways, so be careful with your representations of the human form. In a number of cultures, the
left hand symbolizes vulgar functions, so depicting a left hand on a button could be insulting. In some cultures, white
is the color of mourning after death. The list goes on.
Be cognizant of and try to avoid these situations. Watch for them as you design your pages.
Addresses and Phone Numbers
Always use the area code and perhaps include the country code for all phone numbers. Also, don't assume that the
visitor knows where you are located. Always include the full address for your company if you choose to give it.
Include the country. It's arrogant to assume that all your visitors will know which country you are in by the use of a
state or province.
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (20 of 22) [4/22/1999 4:01:09 PM]
Even things as simple as the address and phone number differ from country to country. If you will be capturing this
information in your application, you need to provide forms with fields that will accommodate the differences.
Also consider edits. For example, U.S. ZIP codes are all numeric, but, if you edit for this, your customers in Canada
will not be able to enter their postal codes, which include letters.
Dates and Number Formatting
On the Internet, you are addressing an international audience. Remember that numbers and dates aren't formatted the
same way in all cultures. For example, 11/12/96 is November 11, 1996, in the United States and December 11, 1996
in many countries of Europe. To avoid confusion, format dates as "dd-mon-yy," for example, 11-Dec-96.
Most countries support a.m. for times before noon and p.m. for times after noon. However, you might want to use a
24-hour time reference just to be safe. Thus, 1:30 in the afternoon could be displayed as 1:30 p.m. (13:30) or
just 13:30.
Numbers also have different formats in different countries. In the U.S., one million is 1,000,000.00, while in Spain it's
1.000.000,00. But digits aren't the only problem. One billion in the United States is one-thousand million
(1,000,000,000), while one billion in England is one million million (1,000,000,000,000). So you have to be careful
even if you use the words and not the numbers.
And speaking of numbers, your prices are important. If you are quoting prices, be sure that your audience knows what
currency you are using. For example, both Canada and the United States use the dollar, but $50.00 (Canadian) is less
than $50.00 (US). Be sure to specify that amounts be sent in the currency that you want.
Time Zones
The Internet has expanded the concept of the 24-hour/7-day application. When you write an application for the
Internet, you need to be aware that while you are sleeping in the U.S., someone in Spain is starting their workday and
people in Australia are already worried about tomorrow. If you're going to serve an international audience, the day
really starts by convention at the International Dateline, not in your particular time zone.
This consideration can be especially crucial for applications that have to do things for the customer based on time of
day, or that rely on information from other processes that run periodically (typically mainframe batch processing
cycles). In the latter case, the question to answer is this: Can your application be unavailable during the period when
the information is being processed?
To illustrate the former situation, let's look at a small application that will mail reminders daily to customers. You'd
like to have these reminders arrive in their mailboxes for the start of the workday, so you decide to send them out at
midnight-but midnight where?
Assume that you're in the U.S. Pacific time zone, say in California. That's -8 hours from Greenwich Mean Time
(GMT). By the time it's midnight in California, it's 11 a.m. the next day in Australia. If you send out the notices at
midnight California time, you will certainly miss the notice to your customers down under.
The answer, of course, is to keep time zone information with the messages. Then arrange your programs to execute
once per hour and process the messages for the appropriate time zone. Thus, you would process those messages for
Australia at about 1 p.m. the previous day, Pacific Time, so that they arrive in Australia in time for the start of the
correct business day.
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (21 of 22) [4/22/1999 4:01:09 PM]
Summary
Given the discussions in this chapter, you might be discouraged about writing your application for the Internet.
Designing an application for the Internet does add challenges to the basic client/server application, but none are
insurmountable.
New solutions are coming to the market every day. Design your application for the Internet from the start. Rely on
solid programming design methodologies and practices. Be aware of the pitfalls and provide solutions for them, and
test your application thoroughly under all conditions. If you do this, you will create a successful application and join
the thousands who are taking advantage of this marvelous medium.
This chapter covered issues related to writing an application for the Internet. You learned that you do not have control
over the infrastructure and resources upon which your application will depend. You saw techniques that can be used in
your application to deal with problems of the unreliable nature of the Internet, security and confidentiality issues, and
the international nature of the Internet.
Chapter 2 -- WWW Design Issues
http://docs.rinet.ru/WPU/ch2.htm (22 of 22) [4/22/1999 4:01:09 PM]
http://docs.rinet.ru/WPU/f2-1.gif
http://docs.rinet.ru/WPU/f2-1.gif [4/22/1999 4:01:21 PM]
Chapter 4
Developing Intranet Applications
by Bob Breedlove
CONTENTS
The Purpose of Intranet Applications l
You Own the Resources-Or Do You? l
The Growth of Intranets l
Application Scope l
Capacity Planning l
Leveraging Existing Resources l
Security
Protecting Confidential Material m
Security Versus Availability m
Change Passwords Periodically m
l
Dealing with Corporate Control Organizations
Network Naming and Addressing m
Router Operations m
Corporate Standards m
LAN Groups at the Local Level m
l
Accessing Mainframe Data
Data Mirroring m
Screen Scraping m
l
Intranet Style Guide
Web Page Organization m
Navigation m
Page Organization m
Page Design m
Use of Graphics m
l
Summary l
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (1 of 21) [4/22/1999 4:01:43 PM]
The explosion in use of the Internet has shaken up the traditional paradigm for application design. In the
traditional view of client/server applications, custom-written application components were distributed
and used to run the application. In the new paradigm, the user has a client tool-the Web browser-to which
host applications are written.
The Web browser gives the end user a unified platform on which to run applications. This new paradigm
can be useful to the development of intranet applications because the new paradigm enables application
designers to write multiple host applications that work with a common client. Using a common client can
reduce training costs and lower the learning curve for new applications by enabling the end user to use a
single client for multiple applications.
Developing applications for an intranet requires many of the same considerations as developing
applications for the public Internet (see Chapter 11, "CGI and the Internet"). An intranet can be viewed
as a private Internet-a non-public router-based TCP/IP network. It can, however, have some exposure to
the public Internet, generally through a computer that limits the types of packets which can pass between
the intranet and the public Internet-a "firewall." This chapter begins with an examination of some of the
things that make programming for an intranet unique.
The Purpose of Intranet Applications
The purpose, and thus the design, of applications designed to operate over an intranet vary from those
designed for the Internet. A set of Web pages (referred to in this chapter as an "application") intended for
the Internet is generally intended for an outside audience, for example, customers, vendors, or other
companies. The look and feel of the application will generally be more "glitzy." Being "cool" and "sharp"
counts, and the pages often contain attention-getting graphics and other gimmicks designed to attract an
audience to the pages.
The intent of these applications is generally to promote a product or service or actually to sell a product
or service over the Internet. Thus, attracting and keeping a target audience is an important aspect of
Internet programming.
Intranet applications, on the other hand, are usually intended for internal audiences such as co-workers,
managers, or employees. These applications are intended to provide important information or services to
manage the business. As such, users want these applications to convey this information succinctly,
efficiently, and in a timely manner. The same graphics and other gimmicks that are the heart of an
Internet application can actually interfere with the effectiveness of an intranet application.
Much of the following discussion assumes that you are developing applications that meet these general
purposes. If you need general information or if you are developing applications for external audiences,
you might find it helpful to read Chapter 1 "An Overview of Internet Programming."
You Own the Resources-Or Do You?
Before you examine the actual design of applications for an intranet, look at the factors that make
intranet applications a challenge to design and implement. As you will see, many of these factors affect
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (2 of 21) [4/22/1999 4:01:43 PM]
your development time frame and implementation effort; others affect the performance of your
application after it resides on your intranet.
As shown in Chapter 1 the public Internet has no central authority or controlling body for its
infrastructure. The various resources over which it operates are controlled by the organizations that own
them. In contrast, an intranet is usually a centrally controlled resource. Generally in large corporations, a
central authority manages at least the backbone of the intranet and handles such services as these:
Network naming and addressing l
Security l
Corporate firewalls l
Router configuration l
Capacity management l
Authority for some of these functions can be delegated to divisional or regional authorities, depending on
the size of the corporate domain. Control of the intranet is generally divided, however, between locally
managed local-area networks (LANs) and centrally managed wide-area networks (WANs) and
backbones. What this means to your project is that you will have to work with these corporate groups to
get things done. Later in this chapter, we will explore in more detail how this affects your project time
lines and implementation.
TIP
Intranet resources are usually controlled by a corporate or divisional
group. You will have to deal with these organizations to implement
your system.
Figure 4.1 represents a typical corporate intranet. The backbone of the intranet is usually some packet
switching technology or other high-speed wide-area network technology. This and corporate resources
such as corporate firewalls (A) are usually centrally controlled. LANs (B) are usually locally controlled;
however, resources that connect the LAN to the intranet (routers and bridges) can be centrally controlled
and managed. Intranets also often have to contend with dial-up access (C) from field sales and other
off-site staff. This dial-up access can be accessed through corporate resources or locally controlled.
Mainframe access (D) is also a concern for many corporate applications. Mainframes traditionally are
centrally controlled and can be controlled by groups other than the intranet groups.
Figure 4.1 : A typical corporate intranet has centrally managed and locally managed resources.
In this chapter, you'll see how this control of resources can affect your system design and time lines for
development. You'll learn about alternatives for your design and about development time-line
considerations that you will face when working with the intranet control and management functions.
The Growth of Intranets
Most corporate intranets are a result of evolution rather than planning and design. They evolved from
earlier attempts to connect LANs, WANs, and mainframes in response to the demand for greater access
to information. As such, intranets are composed of a mixed bag of workstations, hosts, networks, and
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (3 of 21) [4/22/1999 4:01:43 PM]
other devices. Intranets give users unprecedented access to corporate data resources. Dealing with the
intranet itself, however, can be a major challenge in writing applications for use on this shared resource.
Application Scope
This chapter presents designing client/server applications that use some portion of the intranet
infrastructure depending on the distribution of the data and applications that process it. In general terms,
client/server applications can be categorized into various degrees of decentralization.
Figure 4.2 shows this continuum. From left to right in the figure, the typical configurations can be
described as follows:
Figure 4.2 : Client/server design strategies, showing typical applications for each alternative.
A. Traditional applications with data, processing, and display/output on the same platform. These
applications are typified by single-user PC applications and traditional mainframe batch
applications.
B. Data and processing on a single platform with display on a separate platform. Mainframe online
transactions with video display terminals and Web server CGI applications are typical of this
type of application.
C. Data separated from processing and display. This is typified by SQL servers, which provide data
from central repositories to distributed applications.
D. Separated (three-tier) data, processing, and display, typified by applications that require
processing above that provided by desktop workstations (PCs).
You will face different issues depending on the scope of your application. By "scope," I mean the extent
to which your application will use the intranet resources. Generally, these fall into the following
categories:
Application Category Use of Intranet Resources
Single computer system None
Local LAN-based system None
Central processing/data access with remote display Minimal
Central data access with remote processing/display Moderate to heavy
Distributed data, processing, and display Heavy
Capacity Planning
In single computer systems, the central processing unit (CPU) speed, available memory, and direct
storage-device capacity and storage-device throughput are the limiting factors to system performance.
With intranet applications, add to this list the network throughput. Throughput is a result of several
factors:
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (4 of 21) [4/22/1999 4:01:43 PM]
The load on your Web server and the machine on which it operates l
The load on your local-area network l
The bandwidth of the network segments over which the application operates and the load on those
segments
l
The speed and number of the routers, bridges, and other "gateway" devices through which the
application operates
l
The necessity to deal with firewalls l
The capacity of other servers on which your application depends, such as domain name servers,
database servers, terminal servers, and so on
l
Each of these factors affects the operation of your application. You will have to work with corporate
organizations to modify most of these factors.
If the load on your Web server is the problem, you have a few options. The first might be to increase the
size of your Web server host machine, but before considering this expensive option, take a more detailed
look at the capacity problem. The problem might be caused by a single page or CGI script, or it might
exist only at particular times of day. The key is to determine what, specifically, is causing the load
problem and when the load problem exists before you spend money on equipment.
One important point to remember about Web-based applications is that you can, within reason, place the
resources anywhere on the intranet. If your current host can't handle your application, consider moving it
to an existing host that can or consider splitting it between hosts to equalize the load.
Your own LAN can be the bottleneck for your application. Here you need to examine the bandwidth and
the usage on the LAN. If you find that the LAN cannot provide the needed bandwidth, again, consider
hosting your application on a LAN that can or increasing the capacity of the LAN. (It is unlikely that you
will be able to convince your company that purchasing new LAN equipment is worthwhile, unless your
application is the major one on the LAN.)
If your problems arise from the load on the LAN, consider moving your application server to a separate
LAN segment. Depending on the LAN type, you might need to provide a separate network interface card
for your router to accomplish this. It might relieve your application from overloading.
The need for adequate network capacity (bandwidth) is obvious. Your intranet needs the capacity to be
able to handle the volume of data that your application will generate. Your application will operate, for
the most part, at the speed of the slowest segment over which it operates. Unless your LAN segment is
the slowest, there might be little you can do about it. Make sure that the bandwidth from your Web server
to the backbone is as fast as it can be. If it isn't fast enough, consider increasing the bandwidth or moving
your application to a host on a LAN that provides the bandwidth you need.
Any device through which your application's packets must travel will delay your application. This
latency is built into intranets because they rely on gateways (routers and bridges) to provide packet
routing. There is probably little you can do about the overall speed of the intranet.
You also should be aware of the gateway's capabilities to filter by packet type and IP address. If you find
that users can't get to your application, have your network managers examine the filtering on each of the
routers to determine where the packets or your IP address are being stopped. If you are running on a
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (5 of 21) [4/22/1999 4:01:43 PM]
UNIX host, you can use the traceroute command to find out which devices exist between you and a
specific host (see Chapter 17, "Using the Win32 Internet (WinInet) API," for an example of this
command).
If you find that router filtering will be a problem, you might find that the issues are more complex than
just asking router operations' personnel to remove the filter. That filter was applied for a reason. You will
have to examine the business issues that caused the filter to be applied; that way you can determine
whether you can remove it. If you cannot remove the filter, your alternative might be to host your
application on a machine that is not filtered, duplicate your application on both intranetwork segments, or
exclude that segment of the intranet from using your application.
Proper equipment such as network sniffers and cable testers can be essential in the effort to determine the
actual cause of the problem. If this equipment is not supplied by some corporate resource, it might be up
to your department to provide this equipment in order to determine the cause of the problem and
determine the proper course to correct it.
Firewalls are placed between the intranet and the public Internet to protect corporate resources, as shown
in Figure 4.1. Firewalls act as single points of entry to the corporate intranet, and often, single points
where users on the intranet can gain access to the public Internet.
When we speak of a firewall, we speak of users on the corporate intranet as being "inside" the firewall
and the Internet as "outside" the firewall. Generally, firewalls are configured to let all types of packets
out, giving users on the intranet access to the public Internet. Firewalls are almost always configured to
restrict the packets coming in, thus restricting public access to the intranet that they are installed to
protect. Telnet, FTP, and HTTP packets are usually filtered from the outside, as these would enable
hackers access to the resources on the intranet. Mail and news packets are often allowed to pass through
the firewall freely in both directions.
At this writing, Java and other languages of its type are in their infancy. It will be interesting to see how
Java transactions will be treated through a firewall. This is a potential security problem because the Java
application is sent from the host outside the firewall but will execute on the client machine inside the
firewall.
Although firewalls are a necessity, they can cause problems for your application, especially if users on
the outside of the firewall need to access your application. Firewalls can also slow transactions and
become bottlenecks for your application. For this reason, it might be best to design a distributed
application with a module outside the firewall to communicate with the public Internet and an equivalent
module inside the firewall for users on that side. Figure 4.3 illustrates this type of design.
Figure 4.3 : An application in which the main system runs inside the firewall (B) and modules run
outside the firewall (A) to communicate with dial-up and Internet users.
By placing some of the modules outside the firewall, you avoid having unauthorized HTTP packets
passing through the firewall. By using IP address filtering, you can receive packets from your "trusted"
host (A). For additional security, consider replicating data with the modules on machine "A" outside the
firewall so they are completely isolated during online operation. Use FTP or another transport
mechanism to gather transactions in a batch operation to integrate with the main database.
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (6 of 21) [4/22/1999 4:01:43 PM]
This type of "store-and-forward" operation can be effective for systems that have remote components
such as hand-held field units or that send transactions such as sales order transactions that you can deal
with as distinct entities. Thus, a sales representative might access the Internet to upload the day's orders
and download information for the next day's sales calls at the end of his or her day.
The last consideration for using an intranet is the total load on the network. If the load is too great at
critical times, your application becomes unusable. There is probably little you can do about this except
design your application for some other infrastructure.
Be aware that intranet usage can vary widely by time period. Remember, most corporate intranets were
not planned but evolved over time. Although capacity planners can examine the backbone of the intranet,
there is often little centralized control over applications that use the intranet. When designing your
application, consider other applications that will also share bandwidth with your application. This is
especially important if your application performs special processing during typically busy times.
For example, if you are designing a financial application that accepts transactions that are processed in a
weekly or monthly cycle, you can bet that your heavy activity will be in the period just before the cycle.
If this happens to fall at the end of a week or a month, other systems can compete with your system for
bandwidth, making the response times unacceptable for your user community. Be sure to test your
application during these heavy periods. It might even be wise to develop a prototype early in the design
cycle to assure that transaction times are acceptable during heavy load periods.
Using an existing intranet for your application offers many advantages. Capacity planning is the key to a
successful intranet application. In considering capacity planning, you often must work with corporate
entities. The major consideration in capacity planning is the time frame in which projections must be
supplied to assure that changes can be implemented to accommodate the increased load. Lead times will
vary from corporation to corporation, but they will usually require you to predict initial loads, expected
loads over time, and peak loads.
Leveraging Existing Resources
An existing intranet can be a good choice for internal applications because it uses existing resources, thus
saving on initial costs and start-up time. Designing for a Web browser can cut your programming efforts
and, because your user already knows the technology, can reduce your training costs.
NOTE
Designing for a Web browser can solve the problem of programming
for diverse workstation types. When designing Web pages, you write
to the single HTML standard and let the browsers worry about
formatting.
But running your application over an intranet that has evolved over several years can be a double-edged
sword. Intranet growth is typically "organic," where workstations and network technology are purchased
to answer a specific business need and then are integrated at a later date into the intranet. Because of this,
the types of workstations on an intranet are likely to vary greatly. Most corporations have evolved a mix
of workstations, including the following:
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (7 of 21) [4/22/1999 4:01:43 PM]
Microcomputers (PCs) running Microsoft Windows l
Microcomputers running Microsoft Windows NT l
Macintosh computers l
UNIX workstations running text-based interfaces (shell accounts) l
UNIX workstations running X Window l
In addition to these common workstations, your corporation can run other platforms and specialized
workstations. A Web-based application is an excellent choice for applications that must accommodate
these diverse platforms. By designing Web pages, you do not need to supply specialized client software.
Instead, you can construct and display Web pages on the various equipment already deployed on the
intranet.
As shown in Chapter 17, there are considerations when designing applications for Web browsers. There
are also considerations on the Web server side of the transaction.
Hypertext Markup Language (HTML) began as a standard, but with the explosive growth of the Internet,
major players in the Web browser market are racing with each other to implement new and innovative
(and non-standard) features in their Web browsers. Unless your corporation has standardized a particular
Web browser, your application might have to work with more than one browser.
Your application can usually detect the type of browser it services by checking a parameter passed by the
browser. This parameter is not always reliable and is not passed by all browsers. If you need to support
specific features or need a graphically consistent application, consider writing to a specific browser and
supplying it to the users of your application.
Security
Security doesn't seem to be such a major issue on a corporate intranet as it is on the public Internet. After
all, this network is not public. But business considerations can make security an important issue with
which to deal.
If security on an intranet is centralized, it is usually controlled by a corporate organization. Many
corporations currently do not have centralized security for their intranets, which is unfortunate as much
of the hacking done today occurs on private rather than public networks.
If your corporation does have central control of intranet security, those in charge will have security
standards that your application must meet before you can place it on the intranet. As with other corporate
organizations, you will probably have to plan in advance to work with the corporate security department.
Some intranets might even use centrally administered security for logon passwords and other security
issues.
Most technicians find that security concerns often conflict with the technical considerations of their
applications. Technical advances often outstrip the security department's ability to accommodate them.
You might devote your time to security modules that seem overly burdensome and might find that you
are unable to implement some technologies on the intranet because of security requirements and
concerns. But by planning ahead, you can prepare time in your design and construction schedules to
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (8 of 21) [4/22/1999 4:01:43 PM]
accommodate these security needs.
Protecting Confidential Material
Another concern in intranet applications is protecting confidential material. It is true that your application
is operating over corporate resources, but it can pass data that should not be seen by unauthorized
employees, contractors, customers, and others who have access to the intranet. Many confidentiality
issues discussed in Chapter 1 for the Internet also can be applied to intranet applications. Because the
intranet and Internet are both TCP/IP networks, they have the same limitations and problems when plain
text is transmitted across them.
One issue that requires a balancing act is the need for confidentiality versus the availability of
information for the corporate community. Security and confidentiality issues are always cost-benefit
tradeoffs.
Remember also that you might have to apply local, state, and even national laws to the information in
your application even though it passes over your private intranet. Personnel and financial applications are
often subject to these laws. Another interesting consideration that spans political jurisdictions-states,
provinces, or even countries-is that various segments of the intranet might be subject to different laws
when it comes to the confidentiality of the information carried on them.
Security Versus Availability
Maintaining security and confidentiality is a juggling act. On one side is the need to keep information
secure and confidential, and on the other side is the need to make information available. There are no
hard-and-fast rules for managing this dilemma. You could write an entire book on security and
confidentiality issues. In a single chapter, I can provide only some guidelines by which you can develop
your application.
You will need to examine two things to determine the level of security that your application requires.
First, determine how sensitive your data is. Some data is easy. For example, if you are developing an
organization chart application that will display information about your employees such as social security
numbers, home addresses, and phone numbers, you are dealing with sensitive information that should be
protected from unauthorized access. Other information is more subtle. Let's say you're working on a
marketing application that will enable your managers and sales representatives to share information
about current and potential customers. You might think that this information doesn't need to be very
tightly secured; after all, this is your internal network-your intranet. This brings us to the second
consideration in the security versus availability dilemma.
Stop for a moment to consider the people who have access to your intranet. If you are part of a company
of any size, you probably have all sorts of people in your intranet:
Employees l
Temporary help l
Consultants and vendors l
Customers l
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (9 of 21) [4/22/1999 4:01:43 PM]
Would you want all of these people to look at your data? Even subtle data can have an impact on your
business. Let's say you want to put your company newsletter online. Along with those announcements of
company activities, the local bowling league scores, and the picture of the employee of the month is an
article about your marketing strategy. If consultants, vendors, or customers had access to this
information, it could give them (or their other customers) a competitive advantage in the future.
If your intranet has a mix of people on it, consider giving non-employees IDs that are easily identified,
perhaps with special characters in certain positions. Secure all confidential or potentially damaging
information with secured Web servers. Require access via ID and password. Your application can detect
the special IDs and deny access to the information.
One interesting fact is that very few corporations have implemented internal firewalls on their intranets.
You might consider implementing a firewall, especially if you are designing a sensitive divisional or
departmental application that needs to be isolated from other divisions or departments.
How do you decide the security issues? Only you can do so. Look at the data, and then give some
thought about the people who are using your intranet. If you have any doubt, secure the information. A
few tips follow.
If you have any doubt about the security if your intranet, run your application on a secure server
and pass information only to users with secure browsers to ensure that your sensitive information
will not travel over your network as plain text.
l
Develop a central security system that can identify the various types of users by user ID and
password.
l
Accept connections only from known, secure IP addresses. Make sure that machines that are
accessible to unauthorized personnel cannot access your application. Use filters on your router, if
appropriate, or refuse to send pages from your server to unknown IP addresses.
l
Change Passwords Periodically
Given a choice, most of us would select a password that was easy to remember, never change it, and use
the same password everywhere. Your corporate security group probably has standards much stricter than
that-for a reason. Easy passwords that never change are easy to crack, and once passwords are cracked,
hackers can use them again and again.
TIP
Never send passwords via electronic mail unless the message is
heavily encrypted. In fact, just to be safe, never send passwords
through electronic mail, period!
If you must use passwords in your application, change them periodically. Once a month is typical,
though your application might require more or less frequent changes. If you use the HTTP password
capability, you will want a separate process for updating passwords. One way is to use corporate security
files to obtain passwords. Another suggestion is to alter the passwords periodically yourself and
distribute them to your users via a secure mechanism. Never send passwords in an electronic mail
message unless the message is encrypted!
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (10 of 21) [4/22/1999 4:01:43 PM]
Dealing with Corporate Control Organizations
As you have probably recognized, for a major part of the design and implementation effort for an intranet
application, you will have to work with the corporate organizations that control the resources. Companies
vary, but in this section, you'll learn some of the typical organizations. Your company can name these
groups differently or roll the responsibilities into other groups, but the company will probably have some
group to provide these services.
TIP
Working with corporate organizations can take time-plan for it in
your development schedule.
Network Naming and Addressing
Probably the first place you will have to go is to network naming and addressing, especially if you are
going to implement a new server for your application. This group will provide you with new TCP/IP
addresses and domain names. Often in large corporations that have multiple subdomains, this
responsibility is delegated for each subdomain.
It will undoubtedly take some time to get a new domain or even machine registered in a large
intranet-plan accordingly. When you request addresses or names, be sure to include your development
and test environments along with your production host, if they will be on different machines.
If your application will have exposure to the public Internet, you might have to work with your corporate
naming and addressing organization to obtain the IP addresses and names for your hosts and register your
hosts. Often corporations are assigned blocks of IP addresses and are responsible for naming their
domains. In this case, your corporate group can probably supply the names and addresses that you need.
Router Operations
One frustrating aspect about intranets is router operations. Routers are the "glue" that hold the whole
application together and, in a corporate intranet, are often centrally controlled. Some companies use
routers as security and control mechanisms; that is, they filter specific IP addresses or groups of
addresses to segregate parts of the company.
If all parts of the company must share your application, you will have to work with router operations
(and possibly other corporate organizations) to resolve the issue of segregation. This can generally be a
time-consuming process. The end result is usually one of three:
Modify the router filters to pass your particular server. 1.
Host your application on a server that has access to all segments of the intranet. 2.
Duplicate or split your application on servers within the intranet segments. 3.
As you can imagine, the second and third options can raise other issues of control and access to maintain
and update your application.
To test whether your application is accessible by all who require it, ask users on the various segments to
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (11 of 21) [4/22/1999 4:01:43 PM]
attempt to retrieve pages from your server. Be sure to include all protocols-that is, FTP, SMTP,
NNTP-that your application will use to ensure that packet types are not being filtered at some point in the
intranet. Also, make sure that your beta testers represent all network segments that will use your
application.
Corporate Standards
Unlike the public Internet, you might have to conform your application to corporate standards before you
can deploy it on the corporate intranet, especially if your application will be part of a "suite" of
applications, such as corporate or financial applications. You might have to conform your application to
the corporate look and feel and meet performance and specific programming standards. Be sure to
investigate these standards early in your design process.
LAN Groups at the Local Level
You will also have to work with the LAN administrators on the network where your server resides.
Often, LANs are given naming responsibility for the domain of which the LAN is a part. These resources
can help you work with corporate infrastructure. They also tend to be more accessible just because
they're physically close.
Accessing Mainframe Data
Much of a corporation's data probably exists in mainframe files or databases. Often, this data is accessed
through legacy mainframe systems over non-TCP/IP networks. The most common network architecture
is IBM's System Network Architecture (SNA). Corporate intranets are often put into place as the
infrastructure to access this data. However, converting legacy mainframe systems to client/server systems
is often expensive and time consuming.
Thus, your system might have to access data on mainframes maintained by legacy systems. Typically,
executive information systems (EIS) are LAN based. You can find many tools on the market that access
mainframe data, but these tools tend to rely on the data being in a mainframe database or are expensive to
install and maintain.
It is well beyond the scope of this chapter to talk about the various tools available for mainframe access,
but I'll briefly discuss two alternatives to give you a framework for your design:
Data mirroring on intranet-based databases l
Access through existing mainframe systems (screen scraping) l
Data Mirroring
If you design a decision support system (DSS), you can choose to download data to a LAN-based
database out of the mainframe system, often referred to as a data warehouse because it contains historic
data, often summarized, optimized for data retrieval. Data warehouse design is a complex subject and
will not be covered here.
Many tools to access intranet-based databases are coming to the market. If you choose to write your own
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (12 of 21) [4/22/1999 4:01:43 PM]
tools, you will need to design a CGI application, which interfaces with your Web daemon through the
CGI standard and the database's application programming interface (API). Figure 4.4 illustrates this
design.
Figure 4.4 : CGI application design for CGI and LAN-based data warehouse. Mainframe data is
downloaded in batch processes, summarized, and loaded.
Data synchronization is an issue for this design. That is, you will have to carefully consider updating of
your database and transmitting data between the mainframe database and the intranet-based database.
The issues of data duplication are complex and well beyond the scope of this chapter.
Screen Scraping
Cost and time to develop client/server-based applications to meet the demands for access to corporate
data are usually high. One method you can use to speed access to data at a relatively low cost is to use
programs to access data from existing mainframe application screens. Figure 4.5 illustrates this
application design.
Figure 4.5 : A typical screen scraping system configuration using a CGI program communicating with
the Web host and a mainframe interface program.
There are two components in this design: a CGI application and a mainframe interface program.
CGI Application
The CGI program, the interface between the user and the mainframe interface program, receives input
from the user in formats specified by the CGI standard and returns information to the user by formatting
HTML pages. The program establishes a TCP/IP socket connection with the mainframe interface
program and passes transactions that will be processed by the mainframe application just as if a human
had typed them.
The CGI application details vary, depending on your application. However, all applications perform the
following basic functions:
Send HTML forms to request information from the end user l
Follow CGI standards to receive requests from the end user l
Establish TCP/IP socket connections with the mainframe interface program l
Reformat and send transactions to the mainframe interface program over the socket connection l
Receive information from the mainframe interface program over the socket connection and process
it to return to the end user
l
Format HTML screens and return information to the end user l
Store any information that must be maintained between transactions l
Of course, you will have to code both the CGI application and the mainframe interface program to
correctly process errors such as timeouts, unavailability of the mainframe system, and other unforeseen
circumstances.
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (13 of 21) [4/22/1999 4:01:43 PM]
Mainframe Interface Program
This daemon program is responsible for the connections to the mainframe. It usually operates through a
vendor's SNA interface API. The program varies depending on your application and the vendor's API,
but programs of this type perform several basic functions:
Sign on to the mainframe at the start of the day l
Maintain connection on lines that have an inactivity timeout l
Process transactions sent from the CGI program l
Re-establish the sessions with the mainframe in case they come down during the processing day l
Log off the mainframe at the end of processing l
In addition to these basic functions, the mainframe interface program can perform other specialized
functions for your application.
Because the process of signing on to the mainframe can be time consuming, the mainframe interface
program signs on to the system once per day and maintains the connection until it signs off in the
evening. The interface program is responsible for maintaining this connection and accommodating all
security procedures to sign on to the mainframe.
The mainframe interface program receives the SNA data stream, then picks off information at specific
screen locations. In doing so, the program "scrapes" information off existing application screens and thus
gets the name screen scraping. Using existing mainframe online screens as the source of the data, you
can usually implement this type of program more quickly than other types of interfaces. You can also
typically use this type of screen scraping program as an interim module while more sophisticated
interface modules are being developed.
NOTE
A screen scraping program can be a maintenance headache if your
existing mainframe screens change frequently. Screen scrapers
usually require little maintenance when interfaced to stable
mainframe online screens.
One typical situation your screen scraper will face is an inactivity time-out on online applications. To
deal with this, the program implements a timer that sends a dummy transaction during periods of
inactivity for each monitored line. These dummy transactions can be as simple as simulating an Enter
key press or can involve coding a "do nothing" transaction that can be sent periodically to the mainframe
transaction monitor.
Although processing transactions will be unique to your application, the basic format for this interaction
is as follows:
CGI Program Mainframe Interface Program
Request socket connection Establish socket with CGI program.
Allocate mainframe session.
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (14 of 21) [4/22/1999 4:01:44 PM]
Send request transaction Format request for the mainframe.
Transmit request to the mainframe.
Receive response from the mainframe.
Format information for display Format and return information.
Disconnect socket Disconnect socket.
Deallocate mainframe session.
Although the conversation between the modules can be much more complex, this is the basic
conversation. One important point to note is that the connection between the CGI program and the
mainframe interface program is broken after the conversation is complete. Also, the mainframe session
established for the conversation is de-allocated after the socket connection is broken. This means that any
information that needs to be carried over between conversations needs to be maintained by the CGI
program, the mainframe interface program, or both.
Intranet Style Guide
As I stated at the beginning of this chapter, the purpose of intranet applications (sets of Web pages) is to
convey information as succinctly, efficiently, and timely as possible. This style guide section presents
some basic design elements to help you do this in your applications.
If your corporation has a style guide for intranet Web pages, use it. If not, the corporation might have a
guide for Internet Web pages. If so, you look through it and keep in mind the difference between the
intent of intranet versus Internet applications.
Several excellent style guides are available on the Internet. One excellent overall guide to Web page
creation is the Yale University Center for Instructional Media (CAIM) Style Guide by Patrick J. Lynch.
The address for this style guide is
http://info.med.yale.edu/caim/StyleManual_Top.htmL
Because excellent style guides are available and corporations differ greatly, I do not intend to present a
complete style reference. Rather, with this section, I present suggestions for Web pages that are
important to intranet applications and can apply to Internet applications as well.
Web Page Organization
Your application likely includes more than one Web page. In this case, organization and navigation are
important aspects of your design. A user's perception of your application and its ease of use (navigation)
are important aspects of design. To quote from the CAIM style guide, "Users need predictability and
structure, with clear functional and graphic continuity between the various components and subsections
of your [application]. Banner graphics, signature icons, or other graphic devices can be very useful in
reinforcing domain identity within subsections of your [application]."
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (15 of 21) [4/22/1999 4:01:44 PM]
Although you probably won't need to reinforce "domain identity," you will have to give your users the
information they require with a minimum of fuss and bother. You don't want the users' concept of your
application to be a tangle of connections. The users need to have a clear picture of your organization.
If you build a set of pages, think of them as you would think of a written report or book. Organize your
application into a single home page with specific submenus and pages off these menus. Figure 4.6
illustrates this organization.
Figure 4.6 : A Web application should be logically organized to minimize confusion.
Of course, don't interpret this to mean that you can't jump between content pages-quite the contrary.
Logical jumps between content pages are what hypertext (the "H" in HTML) is all about. The point to
remember is that your Web application should appear logical and organized, not random and
disorganized.
TIP
You might just want to jump into producing Web pages, but
organizational planning is as important to a Web application as it is to
any traditional application.
If you generate screens that request, then display, information dynamically, your structure should follow
in much the same way. As with any traditional application, your Web application should enhance the
way users do their jobs. It should take them step by step through the required screens in a logical manner
so they can achieve their goals.
Navigation
It is important to enable users to navigate through your application. If you have spent the time to plan
your application's organization, you have decided on that organization for a reason.
One important point to remember is that users can drop into your application at any point. If you do not
provide them with connections to navigate up and down through your application, they will not get the
full benefit of it.
The minimal navigation aids that you should place on every page include the following:
[Previous Page][Table of Contents][Home Page][Next Page]
In addition to these buttons, you might want to include buttons to navigate to a next section if your
application is organized into sections or to specific pages of general interest, such as a glossary.
Page Organization
Consistency and logical layout are the keys to good page organization. When you plan your Web
application, design a base page template and use it whenever possible throughout your application.
Figure 4.7 shows some elements you might want to consider for your template.
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (16 of 21) [4/22/1999 4:01:44 PM]
Figure 4.7 : A Web page template with HTML shows the basic elements for home pages. Actual design is
not important; consistency is.
Important elements illustrated by this template include the following:
Format Element Comment
Banner graphic A graphic element that ties your application pages together.
This element gives your pages continuity and your users a
sense of a complete application even if they drop into your
pages at midpoint.
Document title The title of your application; also a strong unifying element.
Navigation buttons Objects for the user to navigate through your pages. These
buttons are important because an outside page can link to a
page in the middle of your application.
Dividers Horizontal Rule (<HR>) lines and other elements that
organize your pages into logical sections.
Page title Element that shows the purpose of this particular page in
your application. The page title and document title give users
a complete sense of this page's purpose in the application.
Logo This small element can tie related applications together. For
example, you might use the same logo for all applications for
a particular division or for all applications of a particular
time, such as personnel applications.
Author information This can be important information for your user. It should
include both content and technical contacts, if they differ, for
an application. The use of "mailto" tags can be helpful by
providing a contact for further information or clarifying the
use of your application or a particular page.
Revision date In a medium like an intranet, it is important for your users to
know how old the content on your page is so they can judge
its value to them.
Forms
The same principles apply to HTML forms and the output they produce. If you send a series of forms,
you should give them a consistent look and feel. The user should find related elements together on the
form and should find similar elements on the same section of each form. If you will be integrating your
forms into a larger set of Web pages, you might want to design your page template such that both
informational pages and forms can appear on the same template.
Feedback
Be sure always to give your users positive and complete feedback from a form action. For example, if
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (17 of 21) [4/22/1999 4:01:44 PM]
you store information as a result of a form submission, make sure to inform your users of that fact. Also
give them somewhere to go from your feedback page without having to use their return button. You
should use your standard application page template to display the feedback information if possible. This
way, your users will have access to the navigation buttons that you have included in your application.
Page Design
Designing a Web application is much the same as designing a book or other publication. The same
graphic design principles apply to what is essentially an electronic version of the printed page.
Consistency and predictability are important to any well-designed information system.
Unlike typesetting, in which you have absolute control, on a Web page, you only suggest some of the
elements. For example, you have no control over the aspect ratio of the end user's screen. You also have
no control over the type face or size that they choose for their browser display. In many cases, the user
can override backgrounds, turn off graphics, and do other things that lay waste to your carefully designed
pages.
Enabling the user to carefully plan and extensively test your pages on different equipment with different
tastes and different software can at least alert you to some of these problems. Also, design your pages so
that they are best viewed on the most common equipment and software in use on your intranet. Then
make sure that they are at least usable on other common types of equipment available to the intranet
users. For example, you can choose to use for your main application frames that are available on some
browsers but not supported by all browsers. If there are also users who must access your pages with
browsers that are not capable of viewing frames, provide a non-frame version of your pages. This way,
all users who must access your pages can at least get to the information they require, even if it isn't as
well-organized as it might be in the frames version of the pages.
On an intranet, you might have some control over the equipment and software used if your company
enforces standards for these things or purchases browser software at the corporate level. If appearance is
vital to your application, you might want to consider writing for a specific browser and then distributing
that browser to the users of your application.
Use of Graphics
Graphics can be the most interesting part of a Web application. If you design for the public Internet and
need to attract visitors, "sharp" graphics can do so, but intranet Web applications are intended to impart
specific information or perform specific functions. Graphics take a long time to send across the intranet,
especially if the end user has dialed in.
To make sure that every graphic is worth the transmit bandwidth time, consider the following. "A picture
is worth a thousand words" is the old adage, but the new Web-based adage should be "Is a picture worth
the bandwidth?" At six characters per word, your thousand words will take up about 6,000 bytes.
Graphics to display the same idea can be much larger-in the range of 10 to 60K bytes. In an intranet
application, your users expect to get the job done in a minimal amount of time. The rule of thumb is use
graphics only if they convey important information for your application.
Here's an example. Let's say your application creates a table of information that you want to display in a
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (18 of 21) [4/22/1999 4:01:44 PM]
graph. You could design a program to create a graphic based on this information to display to the user. A
better solution might be to design your application to create a spreadsheet that you can transmit to your
user and to activate their spreadsheet program once it is transmitted. You could even include a small
macro with the spreadsheet to graph the information automatically.
NOTE
Evaluate each graphic for its information content. If you cannot
succinctly state the purpose for this graphic in your application,
consider removing it.
Look at large graphics to see whether they can be as effective if you reduce them. Also, if you use 16- or
24-bit graphics, consider converting them to eight- or even four-bit graphics. With many business
graphics, such as charts and graphs, eight-bit graphics are just as effective and will greatly reduce the
transmission time of the page.
If you use graphics, keep the style and placement consistent between pages. Graphics can be great
devices to help users feel comfortable with your application. A small "banner" graphic can help tie pages
together. This will give your users the sense that your application is unified and will help them find
information on the page.
The consistent use of icons can also boost the effectiveness of your Web application. Use consistent
icons across related applications. If your intranet spans national boundaries, though, remember that not
all cultures share the same history. An icon that is meaningful in one culture might be completely
obscure in another. If you write for an international intranet, be sure to test your icons with all cultures
involved. Figure 4.8 shows a set of public domain icons that you can use in your applications.
Figure 4.8 : An effective set of icons can enhance your application greatly.
Graphic design for a Web page is much like graphic design for a book or magazine. Many of the same
design principles apply to placing graphics and using white space. The CAIM style guide has a good
discussion of design principles.
The Text Alternative
When designing your Web application, always give your user a text alternative to graphics used as
navigation buttons or image maps. If their time is critical, many users prefer to turn the graphics off on
their Web browsers. This greatly decreases the transmission time for your application pages but can
wreak havoc on your image maps or carefully crafted navigation icons.
Always code the ALT= parameter on images. This parameter should include the text version of buttons,
for example:
<IMG SRC="nextpage.gif" ALT="[Next Page]">
Make sure that the text on your pages can stand alone and perhaps provide an ALT tag for graphics to
give the user without graphics some sense of what they're missing.
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (19 of 21) [4/22/1999 4:01:44 PM]
Image maps can work as excellent graphic guides through your application if they make sense, though
these large complex graphics often require a long time to download. If you provide a graphic image map
for navigation, place a row of text buttons below the image to provide an alternative. For example, just
below your image, you might provide
<A HREF="nextpage.html">[Next]</A>
<A HREF="prevpage.html">[Previous]</A>
<A HREF="homepage.html">[HomePage]</A>
Sizing Graphics
Often programmers make the common mistake of using graphics that are too wide to fit within the
browser's default window. Graphics that spill off the screen look bad and can hide essential information.
Most personal computer monitors currently display 640´480 pixels on 13- to 15-inch screens. Macintosh
and Windows versions of Netscape and Mosaic both default to a window size that limits the horizontal
display area of Web pages to about 500 pixels. To prevent top title banners or other wide graphics from
spilling off, the graphics' horizontal measurement should not exceed 470 pixels. This leaves sufficient
visual relief on both sides of the graphic and ensures that users with the most common monitor sizes will
not have to scroll horizontally to see your full graphic.
Transmitting Graphic Width and Height
By transmitting the width and height information in the anchor reference to an in-line graphic, Netscape
or other browsers can instantly create a bounding box for the graphic without examining the whole
graphic to determine size information. Width and height statements are added just after the standard IMG
in-line image tag. Web viewers that do not support this HTML language extension will simply ignore the
width and height tags:
<IMG SRC="LARGE.gif" WIDTH = 412 HEIGHT=137>
When the browser creates the image box, you can accurately place the text before completely
transmitting the graphic. With large graphics, the user can start to read the information without
interruption or having to wait for the graphic to fully transmit, making your pages appear much faster
than they actually are.
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (20 of 21) [4/22/1999 4:01:44 PM]
Summary
An internal TCP/IP network or intranet can be a valuable infrastructure to tie an organization together.
Intranet-centered applications can provide information to the organization in a common convenient
format such as a Web browser. However, like applications written for the public Internet, these
applications require careful planning and programming to ensure their integrity and usefulness. In this
chapter, you learned several intranet programming issues and have learned several strategies and
suggestions for dealing with these issues. Apply these strategies and suggestions in a structured design
and programming environment and treat the intranet applications as you would any other corporate
information technology resource, and your intranet applications will serve your organization well.
Chapter 4 -- Developing Intranet Applications
http://docs.rinet.ru/WPU/ch4.htm (21 of 21) [4/22/1999 4:01:44 PM]
Chapter 11
Perl and the Internet
by Bob Breedlove
CONTENTS
What Is CGI and What Can It Do?
Terminology m
l
What Are the Benefits of Using CGI? l
What Are the Negatives of Using CGI? l
The Protocols
Environment Variables m
Getting Information from the Server m
Getting Form Data m
Returning Information to the Client m
l
What Is CGI and What Can It Do?
The Common Gateway Interface (CGI) is a standard for interfacing external applications with
information servers, such as Web servers. A plain HTML document that the Web server retrieves is
static-a text file that doesn't change. Every time you call a CGI program in real time, on the other hand, it
executes and outputs dynamic information.
CGI version 1.1 started with the idea of hooking a UNIX database to the Internet. Figure 11.1 shows the
simple concept of the CGI interface.
Figure 11.1 : The concept of CGI programs.
CGI began as a way to interface databases to the Web, but CGI programs provide whatever access you
want to program within the limits of the server/browser.
The Web browser communicates with the host server (daemon) using HTTP. When the Web browser
requests the Universal Resource Locator (URL), or address, of a CGI program, the server starts the CGI
program with the daemon's standard input attached to the CGI program's standard output. The CGI
program services the request and communicates with the database engine using its application program
interface (API), which usually uses some form of interprocess communication, shared memory, or
sockets.
Chapter 11 -- Perl and the Internet
http://docs.rinet.ru/WPU/ch11.htm (1 of 11) [4/22/1999 4:01:57 PM]
The database engine retrieves the requested data and returns it to the CGI program. The CGI program
formats a Web page using hypertext markup language (HTML) and returns it to the Web daemon via its
standard output. The daemon returns the HTML to the browser on the client machine, which formats the
page for display.
All CGI programs use this basic concept. A CGI program outputs more than an HTML page, performs
all the processing itself, or accesses any type of server. Figure 11.1 shows that the basic process remains
the same.
Terminology
In this chapter, many of the terms used are the same as the hypertext markup language (HTML)
standards. Some terms are unique to CGI and might not match common usage.
Environment variable A named parameter that carries information from the
server to the script. It is not necessarily a variable in
the operating system's environment, although that is
the most common implementation.
Script The software that is invoked by the server via this
interface. It need not be a stand-alone program, but
could be a dynamically loaded or shared library or
even a subroutine in the server.
Server The application program that invokes the script in
order to service requests. Generally, this application
runs as an independent process on the host computer.
In UNIX terms, this program is referred to as a
daemon.
What Are the Benefits of Using CGI?
HTML pages are static. That is, once you create and place them on the server, requests are transmitted in
the same format each time they are requested. As Figure 11.2 shows, CGI programs run on the server in
real time. With CGI programs, a user can retrieve real-time data and format dynamic pages, and the
pages are different with each transmission.
Figure 11.2 : CGI programs access data, equipment, and other processes and return a myriad of
document types.
CGI programs return a myriad of document types, not just HTML pages, to the server. They send back
an image, a plain-text document, or even an audio clip as well as redirect the user to other documents or
CGI programs.
CGI programs can also store and retrieve information about the browser in records called cookies on the
client machine. These cookies store information about the user during one session, which the browser
transmits when the user next requests your pages. This typically validates a user or allows the user to set
up a custom page for their own use on your system. For example, this information is used to store
Chapter 11 -- Perl and the Internet
http://docs.rinet.ru/WPU/ch11.htm (2 of 11) [4/22/1999 4:01:57 PM]
information about what the user has accessed during visits to the site and then is used to customize
information (such as advertising) that the user sees on his or her next visit to the site.
Many different compiled languages or scripting languages can be used to write CGI programs. Some of
the typical languages include
C/C++ l
Perl l
TCL l
Any UNIX shell l
Visual Basic l
AppleScript l
Many people prefer to write CGI in a scripting language such as Perl or a shell rather than a compiled
language. This is because scripts don't require compiling, which results in easier incremental
development and debugging. The programs to interpret the scripts and their environments usually take up
less room on the server.
Tools for producing CGI programs that do not require knowledge of a particular programming language
are coming to the market. Choose a language or tool with which you are familiar or which supports the
application programming interface (API) of your database engine.
There are hundreds of modules, sample code, and complete applications available for any of the more
common languages, especially Perl and C/C++. There are also libraries of routines for retrieving
information stored by the daemon and returning information to the Web daemon. The CD-ROM
accompanying this book has several examples and URLs to sites with additional code and information.
Unlike Java and other evolving technologies, CGI is a relatively mature protocol. Most Web servers use
it (some with variations). Because of the explosion of the Internet, many people have experience with it
on all types of platforms and servers.
What Are the Negatives of Using CGI?
One of the biggest negatives of using CGI for Web programming is a security issue.
Running a CGI program is like inviting the world to run a program on your system; therefore, there are
security considerations when using CGI programs. Because of the possibility of this abuse by CGI
programs, most HTTP daemons limit the directories in which CGI programs reside. Most HTTP
daemons require an ID that limits the program's access to other parts of the system.
Hackers can take advantage of poorly protected host systems. CGI programs, therefore, should check
data before passing it on. Hackers even breach security holes in some mail systems.
Because CGI programs run entirely on the host computer, they can be a drain on host and network
resources. If the user receives a form on his browser and enters information, the information, in whatever
state, is transmitted to the CGI program through the HTTP host, and the CGI program edits the
information. If errors are found, the information returns over the network to the user for correction. Users
Chapter 11 -- Perl and the Internet
http://docs.rinet.ru/WPU/ch11.htm (3 of 11) [4/22/1999 4:01:57 PM]
edit on the host computer, forcing incorrect information to transmit over the network before discovery.
New technologies, such as Java, promise the capability of editing on the client before the data is
transmitted to the host. This should minimize the amount of invalid data that is transmitted over the
network.
The Protocols
The basics of CGI are relatively straightforward. As seen in Figure 11.1, the server communicates with
the CGI program primarily through environment variables and under some conditions through the
command line.
Note
Although most CGI implementations use environment variables to
transmit information from the server to the CGI program, some
implementations may pass information through specific files. An
example is MS-DOS where environment space can sometimes be at a
premium.
The CGI program communicates with the server through standard output (stdout). In most instances,
the programmer writes as if the CGI program communicates directly with the client browser. Most
information sent by the CGI program passes unaltered by the server to the browser.
The CGI program activates when the browser receives a request for the program's Universal Resource
Locator (URL). The server places information in environment variables and activates the program by
piping its stdout the server's standard input (stdin).
The information passes from the server to the program in a standard format. It is the CGI program's job
to read and decode this information, perform specific processing, and return information to the browser.
There is no connection maintenance between send/receive exchanges in CGI interactions. If an
application requires multiple send/receive exchanges to complete its work, the CGI program is
responsible for maintaining information about the conversation between exchanges.
The CGI program writes the information to files or databases on the host or passes information through
cookies (which are supported by many browsers). The CGI program then stores information on the client
system. This book does not include a discussion of this part of the CGI application function because it is
not covered by the CGI specification.
Environment Variables
The server must pass information about the request from the browser to the CGI program. In order to do
this, it uses a combination of the command line and environment variables. The following variables are
passed to the CGI program for every request:
Environment variable Purpose/Comment
Chapter 11 -- Perl and the Internet
http://docs.rinet.ru/WPU/ch11.htm (4 of 11) [4/22/1999 4:01:58 PM]
GATEWAY_INTERFACE The revision of the CGI specification to which this
server complies. The format is CGI/revision.
SERVER_NAME The server's host name, DNS alias, or IP address as
it appears in URLs.
SERVER_SOFTWARE The name and version of the information server
software answering the request (and running the
gateway). The format is name/version.
The next set of environment variables is specific to the request serviced by the CGI program.
Environment variable Purpose/Comment
SERVER_PROTOCOL The name and revision of the information protocol
this request has. The format is
protocol/revision.
SERVER_PORT The port number to which the request was sent.
REQUEST_METHOD The method with which the request was made. For
HTTP, this is GET, HEAD, POST, and so on.
PATH_INFO The client gives the extra path information. Scripts
can be accessed by their virtual path names followed
by extra information at the end of this path. The extra
information is sent as PATH_INFO and if it comes
from a URL, the server should decode it before
passing it to the CGI script.
PATH_TRANSLATED The server provides a translated version of
PATH_INFO, which takes the path and does any
virtual-to-physical mapping.
SCRIPT_NAME A virtual path to the script being executed, used for
self-referencing URLs.
QUERY_STRING The information that follows the ? in the URL
referencing this script. This is the query information.
Never decode the query string in any way. This
variable should always be set when there is query
information, regardless of command-line decoding.
REMOTE_HOST The host name making the request. If the server does
not have this information, it should set
REMOTE_ADDR and leave this unset.
REMOTE_ADDR The IP address of the remote host making the request.
AUTH_TYPE If the server supports user authentication and the
script is protected, this is the protocol-specific
authentication method used to validate the user.
Chapter 11 -- Perl and the Internet
http://docs.rinet.ru/WPU/ch11.htm (5 of 11) [4/22/1999 4:01:58 PM]
REMOTE_USER This is the authenticated user name if the server
supports user authentication and the script is
protected.
REMOTE_IDENT If the HTTP server supports RFC 931 identification,
this variable is set to the remote user name retrieved
from the server. Usage of this variable should be
limited to logging only.
CONTENT_TYPE For queries with attached information, such as HTTP
POST and PUT, this is the content type of the data.
CONTENT_LENGTH The length of the content as given by the client.
In addition to these variables, the client supplies any header lines and places them into the environment
with the prefix HTTP_ followed by the header name. Any dash characters in the header name then
change to underscore characters. The server can exclude any headers that it has already processed, such
as Authorization, Content-type, and Content-length. If necessary, the server can choose to exclude any or
all of these headers if including them would exceed any system environment limits.
An example of these header lines is the HTTP_ACCEPT variable defined in CGI/1.0. Another example is
the header User-Agent.
Environment variable Purpose/Comment
HTTP_ACCEPT The MIME types that the client accepts, as given by
HTTP headers. Other protocols might need to obtain
this information elsewhere. Separate each item in this
list with commas according to the HTTP spec. The
format is type/subtype, type/subtype.
HTTP_USER_AGENT The browser the client uses to send the request. The
general format is software/version
library/version.
Getting Information from the Server
Every time a server receives a request for the URL of a CGI program, it executes the program in real
time. Most of the program's output goes directly to the client. A CGI program does not accept
command-line arguments because it uses the command line for other purposes.
CGI uses environment variables to send parameters to the program. The two major environment
variables for this purpose are QUERY_STRING and PATH_INFO.
QUERY_STRING is anything that follows the first question mark (?) in the URL. For example, the URL
http://www.myhost.com/cgi-bin/myprog.cgi activates the program myprog.cgi in the
/cgi-bin directory under the document root on host www.myhost.com. To pass additional
information to the program, the URL expands to
Chapter 11 -- Perl and the Internet
http://docs.rinet.ru/WPU/ch11.htm (6 of 11) [4/22/1999 4:01:58 PM]
http://www.myhost.com/cgi-bin/myprog.cgi?mydata is here
Place the information in QUERY_STRING as
QUERY_STRING=mydata+is+here
This string is encoded in the standard URL format of changing spaces to plus signs (+) and indicating
special characters with a percent sign and two-digit number (%xx). The CGI program must decode the
string in order to use it.
You can add the QUERY_STRING information using either an ISINDEX document or an HTML form
(with the GET action). Another way is to manually embed it into the HTML anchor, which references
your gateway. This string usually is an information query-for example, what the user wants to search for
in the databases or the encoded results of your feedback GET form.
If the Web daemon is not decoding results from a form, the query string decodes onto the command line.
This means that each word of the query string is in a different section of ARGV. The CGI program
receives, for example, the query string my data as
argv[1]="forms"
argv[2]="rule"
No decoding or other processing is necessary in order to use the data.
CGI enables the URL to receive extra embedded information, which transmits extra context-specific
information to the scripts. The PATH_INFO information passes at the end of the URL without the server
encoding any of the information.
A typical use for PATH_INFO information is to provide directory or file information for processing.
Suppose that the CGI program
http://www.myhost.com/cgi-bin/myprog.cgi
needs to process information in directory /mydir. This information passes as an addition to the URL:
http://www.myhost.com/cgi-bin/myprog.cgi/mydir
TIP
Chapter 11 -- Perl and the Internet
http://docs.rinet.ru/WPU/ch11.htm (7 of 11) [4/22/1999 4:01:58 PM]
One use of PATH_INFO is to pass configuration filenames to a CGI
program. The same base CGI program can then handle multiple
configurations by including the configuration file in the URL for the
application.
Myprog.cgi knows the location of the document relative to the DocumentRoot via the
PATH_INFO environment variable or the actual path to the document via the PATH_TRANSLATED
environment variable, which the server generates. Because the first slash / passes with the PATH_INFO
variable, it must be stripped if it is not needed.
Getting Form Data
Use the GET and POST methods to retrieve information from the forms. Each method returns the form
information in a different manner.
<FORM ACTION=CGI URL METHOD=GET>
If the form tag includes the GET method, the CGI program receives the tags in the QUERY_STRING
environment variable. This can be a method of maintaining information about a set of request/send
transactions between the client and CGI program. For example, the CGI program might store information
about the client by indexing a serial number key and encoding this key in the URL specified in the
ACTION= option of the form tag. The URL with the additional key information returns to the program
with a click of the Submit button. This allows the program to retrieve the stored information and restore
its working environment.
<FORM ACTION=CGI URL METHOD=POST>
If the form tag includes the POST method, the CGI program receives the tags through stdin. Note that
the server does not send an indication of end of file (EOF) at the end of data. The program must read the
CONTENT_LENGTH environment variable in order to determine the length of the input to read.
Decoding Form Information
Both the GET and POST methods send URL-encoded TAG=data pairs separated by ampersands (&).
Plus signs (+) replace spaces, and certain characters are encoded as %xx hexadecimal characters. A
NAME tag identifies each FORM variable, and this NAME is placed in the TAG part of the data pair. For
example, given the following form:
<FORM METHOD=POST>
<INPUT NAME="A" SIZE=5> (Input "A B C")
<INPUT NAME="B" SIZE=5> (Input "12345")
<INPUT NAME="C" SIZE=2> (Input "DE")
Chapter 11 -- Perl and the Internet
http://docs.rinet.ru/WPU/ch11.htm (8 of 11) [4/22/1999 4:01:58 PM]
</FORM>
The CGI program receives the following:
CONTENT_LENGTH=20
stdin: A=A+B+C&B=12345&C=DE
Luckily, several library routines are available for various languages to decode URL-encoded data. This
makes life easier when creating CGI programs.
Returning Information to the Client
CGI programs return many document types:
An image l
An HTML document l
A plain-text document l
An audio clip l
Others types are defined by MIME type. CGI programs also can return references to other documents.
The client must know what kind of document the program is sending it so it can display it accordingly.
For the client to know this, the CGI program must tell the server what type of document it is returning.
To tell the server what kind of document the program is sending back, whether it is a full document or a
reference to one, CGI requires the CGI program to place a short header on the output. This header is
ASCII text, consisting of lines separated by either line feeds or carriage returns (or both) followed by a
single blank line. The output body then follows in its native format.
A Document with MIME Type
For a full document, the CGI program must tell the server what kind of document it is delivering via a
MIME type. Examples of common MIME types are text/html for HTML and text/plain for
ASCII text.
Here is an example of an HTML document:
Content-type: text/html
<HTML>
<HEAD>
Chapter 11 -- Perl and the Internet
http://docs.rinet.ru/WPU/ch11.htm (9 of 11) [4/22/1999 4:01:58 PM]
<TITLE>Title Goes Here</TITLE>
</HEAD>
<BODY>
<H1>Heading Goes Here</H1>
Body of the HTML document.
</BODY>
</HTML>
A Reference to a Document
Instead of sending the document, the CGI program directs the browser to a particular predefined
document or has the server automatically send the new one.
An example is an application that sends existing published white papers based on information requests.
In this case, the program should know the full URL of the files to reference and send something like the
following:
Location: http://www.myserver.com/document_location<lf><lf>
The two line-feed characters form a blank line after the Location: line. The server acts as if the
client's request was for the returned URL instead of the CGI program. It takes care of looking up the file
type and sending the appropriate headers.
If you do want to reference a document that is protected by access authentication, the program must have
a full URL in the Location: line. This is because the client and the server must retransact to set up
access to the referenced document.
NOTE
If your application needs to send headers such as Content-encoding,
your server must be compatible with CGI/1.1. Send the headers and
Location or Content-type, and they are sent back to the client.
Chapter 11 -- Perl and the Internet
http://docs.rinet.ru/WPU/ch11.htm (10 of 11) [4/22/1999 4:01:58 PM]
Chapter 11 -- Perl and the Internet
http://docs.rinet.ru/WPU/ch11.htm (11 of 11) [4/22/1999 4:01:58 PM]
http://docs.rinet.ru/WPU/f11-1.gif
http://docs.rinet.ru/WPU/f11-1.gif [4/22/1999 4:02:04 PM]
http://docs.rinet.ru/WPU/f11-2.gif
http://docs.rinet.ru/WPU/f11-2.gif [4/22/1999 4:02:12 PM]
Chapter 10
Extending Java Using ActiveX
by Bryan Morgan
CONTENTS
The ActiveX Advantages
High Performance m
Persistence m
Huge Existing Code Base m
Language Independence m
Distributed m
l
The Flip Side: ActiveX's Disadvantages
Platform-Dependent m
Security Model m
Network Performance m
Browser-Dependent m
l
What Does This Mean for the Web Developer?
ActiveX and the Intranet m
ActiveX and the Internet m
l
Combining Java and COM Using Visual J++ l
Summary l
Since its introduction in 1995, Java has dominated the computer industry's discussion of client-side Web
programming. Because it was the first programming language and environment introduced with the
World Wide Web specifically in mind, Java is a natural fit for developers wanting to add truly interactive
content to Web pages. Some of Java's chief advantages are that it is object-oriented, multithreaded,
secure, and platform-independent. However, this is not to say that it does not have its disadvantages.
Currently, downloaded Java applets suffer from poor performance, are not persistent on the client, and
are severely restricted on the client from performing system-level tasks. Also, despite the tremendous
potential of the Web, the fact remains that the vast majority of code being written today is still being
written for operating-specific, stand-alone applications.
Since 1990, Microsoft has been promoting an object model (COM) that specifies how binary objects can
interact and build on each other. Object Linking and Embedding (OLE) was Microsoft's implementation
Chapter 10 -- Extending Java Using ActiveX
http://docs.rinet.ru/WPU/ch10.htm (1 of 11) [4/22/1999 4:02:25 PM]
of an object framework using COM. OLE provides several objects that enable the user to work in a
document-centric way. This means that the document on which the user is working is the real focus, not
the individual applications that are used to create the document. An OLE compound document could
include word processing text, graphics, spreadsheets, sound, video, or any other OLE-compliant
application's output. Simply clicking any of these objects within the document could activate the
application that created the object. OLE became so successful on the Windows platform that Microsoft
decided to make it the basis of its distributed computing framework. Microsoft also introduced another
COM-based technology that used OLE and other COM-based objects to collectively create programming
objects (OLE controls or OCX controls) that could be dropped into any OLE control- aware
programming environment. Environments that currently support OLE controls include Visual Basic 4,
Visual C++, PowerBuilder, Borland Delphi, Borland C++, and Access.
The explosion in Internet usage forced Microsoft to rethink many of its applications and technologies,
and many parts of OLE were reworked to provide better performance, smaller code size, and a different
security model. These technologies were introduced to the public in 1995 as ActiveX. ActiveX
technologies currently available include the programming objects known as ActiveX controls, the
ActiveX scripting engine in Microsoft Internet Explorer 3.0 (used to run VBScript and JavaScript),
ActiveX Documents (see Figure 10.1), and the ActiveX Server Framework, which provides security,
database access, and server-side tools.
Figure 10.1 : Microsoft Internet Explorer 3.0 displays an ActiveX document.
This chapter points out the strengths and weaknesses in Microsoft's ActiveX technology. A key point to
remember is that with Microsoft Visual J++, the Java developer has both options to play with: pure Java
and ActiveX. In other words, developers are no longer forced to choose between ActiveX and Java.
Therefore, the decision is left up to the developer to pick the best tool for the job (which is the way it is
supposed to be).
The ActiveX Advantages
In any fair discussion, nearly every new technology has a set of advantages and disadvantages. ActiveX
has been praised by many and criticized by just as many others. (In general, this usually indicates that
you must be at least be doing something interesting to evoke such a large amount of discussion!)
Nonetheless, with the advent of the Microsoft Internet Explorer 3.0 browser, the Microsoft Virtual
Machine for Java, and Visual J++, ActiveX is going to be around for quite some time. This section
focuses on the advantages of ActiveX and how it can benefit the Web programmer. To begin, you learn
that you can do things with ActiveX that you simply cannot do using any other technology. This, by
default, gives ActiveX an advantage in many areas where it faces no competition.
High Performance
The ActiveX technologies are all binary technologies. This means that, unlike Java, there is no runtime
interpreter that translates bytecodes into machine code. Therefore, downloaded components (ActiveX
controls) are able to run at true machine speeds, which means ActiveX controls run much faster than
comparable Java applets.
Chapter 10 -- Extending Java Using ActiveX
http://docs.rinet.ru/WPU/ch10.htm (2 of 11) [4/22/1999 4:02:25 PM]
Persistence
Although in some instances object persistence can be a disadvantage, when ActiveX controls are initially
downloaded they are installed onto the local system and remain there. (Future versions of Internet
Explorer will enable the user to set defaults that control how ActiveX controls are saved.) The next time
the user visits a page containing this ActiveX control, no downloading needs to be done. Instead, the
ActiveX control is embedded immediately within the form. Java applets, meanwhile, are cached on the
local file system only during the Web browser's current session. The next time the user visits the Web
site (after closing the browser), the applet most likely will have to be downloaded again. This might not
seem like a big deal, but because many applets inherit and use a wide variety of other classes, many of
these additional classes also have to be downloaded. It is not unusual for a single applet to download 50
separate class files before it can be used within the Web page.
Huge Existing Code Base
Although Java is clearly an extremely exciting technology and might be the language of choice for many
in the coming years, ActiveX technologies have been around since 1990. An extremely large base of
code currently exists in the thousands of ActiveX controls available on the market today. Because of the
COM foundation, all OLE controls available before the introduction of ActiveX can be downloaded and
used within a Web browser just like ActiveX controls. The primary difference between ActiveX controls
and OLE controls is that ActiveX controls are only required to implement one interface: Iunknown. This
enables them to be potentially much smaller than OLE controls, although in some cases ActiveX controls
are no different than their OLE counterparts.
ActiveX controls are hugely popular, and an entire industry already exists and thrives on their production
and sales. Examples of ActiveX controls currently installed on my machine include
Map Display l
Chart l
Spreadsheet l
Spellchecker l
RealAudio l
Stock Ticker l
Movie Player l
Image Viewer l
Date and Calendar l
Progress Bar l
Although it is true that Java applets exist to perform some of the functionality previously mentioned,
there are other operations listed here for which no Java applets exist whatsoever. In addition, many of the
Java spreadsheet and chart classes available (to pick some examples) suffer from extremely poor
performance and low functionality. Meanwhile, the market has pretty much sorted out the winners from
the losers in the ActiveX control arena. Companies such as Sheridan, Micro-Help, and Visual
Components have established excellent reputations for building high-performance, high-functionality
ActiveX objects. Therefore, when components are purchased from these companies, there is some
Chapter 10 -- Extending Java Using ActiveX
http://docs.rinet.ru/WPU/ch10.htm (3 of 11) [4/22/1999 4:02:25 PM]
assurance that they will work as advertised.
You can build the following applications using Visual J++ and the controls listed previously:
A Web page that contains HTML and an ActiveX control to display mapping coverages l
A Windows application written in Java to show a spreadsheet l
A Web application that contains Java applets and ActiveX controls side-by-side to plot data to a
screen based on input coming from a real-time stock ticker; data from this application could be
printed to a local printer in the form of customized reports (not just a mirror of the Web page sent
to the printer)
l
The Windows Virtual Machine for Java makes all of the preceding functionality possible. You might be
surprised to learn that even the Microsoft Virtual Machine itself was built as an ActiveX object.
Thousands of developers have spent huge amounts of time and money investing in application
development using ActiveX components. It is wishful to expect all of these developers to simply stop
everything they have been doing for the past two years, retool, and begin developing Web-based Java
applications. ActiveX acts as a bridge between the two technologies by enabling existing components to
be reused while enabling new components to be added to applications. These components could be
written in Java, Visual Basic, Delphi, C++, or any other language that supports the creation of ActiveX
controls.
Language Independence
ActiveX objects also have one additional advantage: They can be written in any language and can be
called from any other language.
NOTE
Before discussing this further, let me take a moment to define the
word "any" in the world of Microsoft. Developers cannot simply sit
down with a Fortran compiler and immediately start using ActiveX
controls. Instead, the compiler needs to be able to support the
linkages between ActiveX and standard code. Likewise, for a
language to call an ActiveX object, the compiler must be
"ActiveX-aware" and support the hooks necessary to dynamically
link together ActiveX objects with binary code.
Under Windows 95/Windows NT, the development tools that control the lion's share of the PC software
development market all support the usage of ActiveX controls. As mentioned earlier, this includes Visual
Basic and C++, Delphi, PowerBuilder, FoxPro, Access, and many others. C++, Delphi, and VB 5.0 also
support the creation of ActiveX controls. Therefore, an ActiveX object written in C++ could be dropped
onto a Delphi form (or an HTML page for viewing in MS Internet Explorer). The word "object" is
intentionally used here to mean a programming construct that encapsulates data and methods in an
atomic object.
Programs written in Java, meanwhile, are limited in their capability to communicate with code written in
other languages. "Native" language methods can be called through the use of native methods; however,
once these methods are used, Java classes cannot "travel" to remote machines as they do when they are
Chapter 10 -- Extending Java Using ActiveX
http://docs.rinet.ru/WPU/ch10.htm (4 of 11) [4/22/1999 4:02:25 PM]
downloaded to a client browser. Native methods can also link only to static object code, so there is no
way to dynamically update the linked-in code, as there is with ActiveX objects.
Distributed
With the advent of Distributed COM in Windows NT 4.0, ActiveX objects also have the capability to
communicate with other objects located on remote machines. These objects can be placed on other
machines for a variety of reasons:
Maintainability-Objects can be updated once on the server, and all clients will immediately "see"
the update.
l
Network Performance-Each individual object does not need to be downloaded in its entirety over
the network; instead, remote procedure calls (RPCs) are used to communicate between the objects.
l
Scalability-DCOM enables objects to be mirrored across multiple machines to improve
performance for the end user.
l
Much attention has been paid to the two-tier design of traditional client/server applications. In this
development mode, all of the display and application logic resides on the client (the Web browser
containing applets or controls, or a normal GUI application) and the database operations reside on the
server. Several problems arise with this development paradigm. The biggest problem is that the display
code and the application code often become so intertwined that code maintenance is extremely difficult.
If you need to dramatically change a screen, a huge amount of reworking is involved before you can
make the change. Breaking applications into logical portions and distributing these segments across
multiple tiers (often called n-tiers) leads to better maintainability, performance, and scalability.
The Flip Side: ActiveX's Disadvantages
Believe it or not, despite the marketing hype surrounding ActiveX, it does have some real disadvantages
to go with its advantages. These disadvantages are discussed in an unbiased manner in the following
sections.
Platform-Dependent
ActiveX is advertised by Microsoft as having "cross-platform support." Although behind-the- scenes
versions of ActiveX are being readied for the Macintosh and UNIX operating systems, the fact remains
that ActiveX today can be used only on Microsoft's own operating system (Windows). To Microsoft's
credit, the Component Object Model (COM) in no way specifies any vendor- or platform-specific
implementation features. However, so far no company besides Microsoft has stepped forward and built
an implementation on top of COM.
A discussion seems to continually rage in the Java newsgroup (comp.lang.java) over whether the
words "cross-platform" even matter. After all, Microsoft owns a nearly 90 percent share of the personal
computing operating system market, so who cares about "cross-platform"? In other words, what good
does being "cross-platform" do you if all of your customers' platforms are the same? This is an extremely
interesting point and, as with all good questions, there is no easy answer. In an ideal world, each
individual user could choose his computing environment based on his personal preferences. That is, the
Chapter 10 -- Extending Java Using ActiveX
http://docs.rinet.ru/WPU/ch10.htm (5 of 11) [4/22/1999 4:02:25 PM]
software would come to the user, rather than the user being forced to go where the software is.
Java is not completely free from this discussion, either. Even though Java code might be able to run
unmodified on virtually any platform, it is unable to interoperate with other parts of the operating system.
In a generic Web-centric environment, the Web browser itself could act as the operating system and
applet execution environment. However, this excludes all of the applications that take advantage of
operating-system features to provide more value to the end user (printing, file access, inter-application
data sharing, and so on).
Microsoft has announced its intention to develop ActiveX-aware versions of its Internet Explorer
browser for the Macintosh and UNIX operating systems. The time frame in which these browsers are
introduced, combined with the success of the Mac and UNIX ports of ActiveX, plays a key role in the
success of Microsoft's "cross-platform" ActiveX strategy.
Security Model
Java was designed from the ground up to ensure that a person who used a client machine running Java
code could be nearly certain that the code would not harm the local system. No matter who the developer
of the Java applet is, a user can download an applet, run it, and never really think about the security
implications of doing so. This is because Java applets have no capability to read or write to the local file
system or to make any operating system calls (a security technique known as sandboxing). Although no
system connected to the outside world via the Internet can ever be 100 percent secure, the Java language
and runtime environment go a long way to prevent security flaws.
ActiveX controls, meanwhile, have full system privileges. After an ActiveX control is downloaded, your
Windows Registry can be updated, and the component will be installed onto your local system. The
ActiveX control can perform a directory search of the file system, change video resolutions, reboot your
computer, or even grab files and send them over the Internet to a remote server. With these capabilities,
no security model on earth will ever make users feel completely comfortable. Microsoft is trying,
however, to convince the computer industry and the public in general of the virtues of its ActiveX
security model. This model uses a technique known as code signing to verify the contents of ActiveX
controls before they are downloaded.
Code signing is provided by an independent software testing facility (called Certification Authorities)
that tests code to verify that it does what it says it does. When this software has been tested, the code is
signed using a digital signature. These signatures contain information that can be examined by software
that supports the Microsoft Trust Verification service (Internet Explorer, for example). Using this
service, a Web browser can determine whether a control has been modified since it was assigned a digital
signature. If it has been tinkered with, the Web browser can alert the user or disenable downloading.
CAUTION
Keep in mind that ActiveX components, unlike Java applets, do not
undergo any runtime verification. Therefore, after the control is
installed on a machine it is free to do whatever it wants.
ActiveX controls are not required to use code signing. In fact, Internet Explorer 3.0 offers users the
ability to fully control the security level at which they want to operate (see Figure 10.2).
Chapter 10 -- Extending Java Using ActiveX
http://docs.rinet.ru/WPU/ch10.htm (6 of 11) [4/22/1999 4:02:25 PM]
Figure 10.2 : The Internet Explorer Security Options dialog box.
Security can mean different things to different people. Java is secure in that Java code is unable to access
the local operating system when it is running within a Web browser. ActiveX security, though not as
foolproof, potentially still could provide the same level of security that is expected today when users
purchase shrink-wrapped software. Perhaps the biggest problem with ActiveX security is the fact that it
leads the public to trust only software produced by the major software manufacturers. A tiny, brand-new
software company might have difficulty convincing the public to download and run its ActiveX code,
especially when a comparable product is offered by a major manufacturer such as Microsoft.
Network Performance
One other disadvantage of ActiveX controls that is often ignored is their sheer size. Going back to the
partial list of ActiveX controls installed currently on my machine, the following listing shows these
controls and their size. Some of the controls are OLE controls and others are actual ActiveX controls,
and therefore are noticeably smaller (the Stock Ticker and RealAudio controls, in particular).
Map Display (374KB) l
Chart (294KB) l
Spreadsheet (623KB) l
Spellchecker (84KB) l
RealAudio (114KB) l
Stock Ticker (88KB) l
Movie Player (187KB) l
Image Viewer (96KB) l
Date and Calendar (325KB and 228KB) l
Progress Bar (208KB) l
In contrast, the 470 Java classes included in the Visual J++ classes.zip file take up a total of
804KB, or approximately 1.71KB each. Although it is true that some applets also download several
additional classes in order to be interpreted and run, all of the 470 files in the Visual J++ class library
will be included on the local Windows machine as part of the Microsoft Virtual Machine. (In other
words, they don't need to be downloaded in that case.) Microsoft has gone a step further with the Visual
J++ product and enabled developers to package all of the required class files for an applet together into a
single .CAB file. This file is compressed on the server side, and then the individual class files are
extracted from the CAB file as the Java Virtual Machine needs them. Compressing files in this way
greatly reduces download time of Java classes.
Some ActiveX controls also require DLLs (dynamic link libraries) and other files to be installed along
with the ActiveX control. When these controls are downloaded, an installation routine will often start and
install the control onto the local machine. Although this process has to be completed only once, it still
causes a long enough wait that many users might just cancel the operation altogether. Developers who
have built OLE controls should obtain the ActiveX SDK and really look at converting these controls to
true ActiveX controls in order to save download time.
Chapter 10 -- Extending Java Using ActiveX
http://docs.rinet.ru/WPU/ch10.htm (7 of 11) [4/22/1999 4:02:25 PM]
Browser-Dependent
As you probably are well aware by now, ActiveX is supported natively only in Microsoft's Internet
Explorer 3.0 browser. A Netscape plug-in that enables Netscape Navigator to display pages containing
ActiveX controls can be obtained from nCompass Labs, but this product is not supported by Netscape.
Through the 4.0 release of Navigator, Netscape has no plans to add ActiveX support into its browser,
either. All of this means that if you were to build Web pages containing ActiveX controls or Java applets
communicating with ActiveX components (as you see later in this chapter), those pages would not
display correctly within any browser but Microsoft Internet Explorer.
As new ActiveX-enabled versions of Microsoft Internet Explorer become available for the Macintosh
and UNIX platforms, the debate is sure to change. At that point, an overwhelming majority of operating
systems would feature support for ActiveX and Java, making it likely that both technologies will
continue to coexist for some time to come. However, developers interested in ActiveX should realize that
there is a growing contingent of users who are worried about ActiveX's security drawbacks, as well as its
platform dependence. These concerns should be taken into consideration when making development
choices.
What Does This Mean for the Web Developer?
All of this jockeying for position in the Web sweepstakes has left many developers' heads spinning.
Microsoft continues to release a barrage of related ActiveX technologies, with little explanation of the
benefits and drawbacks inherent in each technology's usage. What's worse, because of the real-time
nature of the Web, many new features and products have been reported before these features are actually
fully developed. (When good developers find it difficult to keep up with new technologies,
non-developing journalists can rarely be relied upon to explain these technologies.)
ActiveX and the Intranet
In the short term, the success of ActiveX will be found in the intranet setting. At the department or
division level, software and hardware resources can be quantified and controlled to a much larger degree
than in the entire Internet. Therefore, organizations that have already chosen Windows 95 or NT as part
of their standard desktop should find implementing ActiveX solutions relatively easy. The advantages of
ActiveX really show up in this situation, because the department's IS staff can continue to work with the
tools with which they've been developing for the past few years. Developers can set up Web servers to
provide replication, if necessary, and update objects on servers so that users see the changes in real time.
In fact, they can even reuse existing OLE controls and ActiveX controls. At this point, the professional
developer should look at encapsulating application logic in the form of distributed objects on servers.
The user interface can be generated fairly rapidly using standard Web publishing tools. Developers can
also use Java throughout development projects, in combination with ActiveX, to match the best tool with
the job.
Chapter 10 -- Extending Java Using ActiveX
http://docs.rinet.ru/WPU/ch10.htm (8 of 11) [4/22/1999 4:02:25 PM]
ActiveX and the Internet
On the other hand, ActiveX faces a much more daunting task before it can claim success across the
World Wide Web. Because of security concerns and the fact that a large number of World Wide Web
clients are non-Windows machines, ActiveX on the Internet is met with skepticism by most developers.
As Microsoft demonstrates the effectiveness of its code-signing solution, and as ActiveX is ported to
other platforms, ActiveX should slowly gain a larger measure of support than it currently is receiving.
In any case, to reach the lowest common denominator, pure Java is still the best choice for providing
active Web applications to the greatest number of clients. Despite its flaws, the Java language and
runtime environment were designed with the Web in mind (not retrofitted for the Web after the fact) and
contain several advantages simply not found in any other technology on the market today. The following
example illustrates the use of Java (using Microsoft Visual J++) to build a COM-aware Java applet.
Combining Java and COM Using Visual J++
No matter how you look at it, the Web developer skilled in Java and COM/ActiveX has the best of the
desktop and the Internet at his or her fingertips. The Visual J++ development tool enables the Java
programmer to call COM objects using Java code. These COM objects look exactly the same to the
developer as every other Java class. In fact, using tools included with Visual J++, actual Java class files
are generated for each COM object. These classes can then be imported and used just as if they were a
standard class.
This "magic" is made possible through the use of the Microsoft Virtual Machine for Java. Microsoft has
licensed the JVM spec from Sun Microsystems and has signed an agreement to build the "reference
implementation" of the JVM for the Windows platform. Any additions made to the Windows JVM by
Microsoft can then be given back to Sun for inclusion in the Java Virtual Machine Specification, owned
by Sun Microsystems. Unlike the virtual machine included with most Web browsers, such as Netscape
Navigator, the Microsoft Virtual Machine actually becomes part of the operating system after
installation. This means that it is then available to all Windows applications. Because it is itself
implemented as a COM object, the Microsoft Virtual Machine can be utilized by any application that
supports the same COM interfaces. This enables objects created in Java to appear as COM objects to
other Windows applications. In providing this, Microsoft has elevated Java to the same programming
status as its other flagship languages: C++ and Visual Basic.
The javabeep example included with Visual J++ demonstrates a Java class-calling COM object (located
in the beeper.dll file). This simple object is used to build a Java applet and application that will beep
and print a message each time the user clicks the mouse on the application's client window.
Using the Java Type Library Wizard in Visual J++, standard Java classes are generated from the COM
object's type library.
NOTE
Chapter 10 -- Extending Java Using ActiveX
http://docs.rinet.ru/WPU/ch10.htm (9 of 11) [4/22/1999 4:02:25 PM]
A type library in COM is simply a "definition" file that lists all of the
methods, variables, and interfaces supported by the object that the
type library represents. It can be thought of as similar in nature to a
C++ header file.
These classes provide a mapping between the variables, methods, and interfaces used in the COM object,
and the variables, methods, and interfaces in the new Java class. When the Type Library Wizard is
finished, two new classes will have been created for your use in the \windows\java\lib\beeper
directory:
Beeper.class l
IBeeper.class l
At this point, to access these two objects (actually contained in the beeper.dll COM library), add the
following line of code to your Java applet or application:
import beeper.*;
This will import both classes in the Beeper package. To create a new beeper object for use within
your Java class, the following code is sufficient:
IBeeper m_Beeper = null;
...
if(m_Beeper==null)
m_Beeper = (IBeeper) new Beeper();
After the object has been created, the following statement will call into the beeper.dll and issue a
beep:
m_Beeper.beep();
Programmers with some Java experience should notice that syntactically there is nothing here but
standard Java code. The real work is being done at the Virtual Machine level. Figure 10.3 shows the
javabeep project running as an application.
Figure 10.3 : A Java application calling a COM object.
Figure 10.4 shows the javabeep project running as an applet.
Chapter 10 -- Extending Java Using ActiveX
http://docs.rinet.ru/WPU/ch10.htm (10 of 11) [4/22/1999 4:02:25 PM]
Figure 10.4 : A Java applet calling a COM object.
Summary
The ActiveX technologies are extremely powerful and have the potential to enable Web-based
applications to do things that were previously impossible. Using ActiveX controls, ActiveX scripting,
and ActiveX documents in combination with HTML and Java applets, the software developer can
develop truly interactive, interesting applications using the Web browser as the operating environment.
With a tool such as Visual J++, the ActiveX controls can even be built using Java, and Java applets can
contain ActiveX controls. This gives the professional software developer the best technologies of the
desktop, combined with the best technologies of the Internet.
ActiveX itself comes with several advantages and disadvantages. It has the advantages of being language
independent, having good performance, and a large existing code base. Some of its drawbacks include its
platform dependence (it can be used only on Windows at the current time), its access to the local
operating system, and its level of browser support (only Internet Explorer at the current time).
Microsoft is taking steps to address each of these issues and will eventually get there, but many
developers are comfortable with the capabilities of Java as it currently exists. To port ActiveX to a small
number of desktop operating systems requires an extensive effort, while the Java Virtual Machine
already exists on nearly every operating platform in use today. ActiveX security (via code signing)
requires an independent certification authority to certify and verify a control's behavior.
Tools such as Visual J++ enable Java developers to pick and choose among different Java, COM, and
ActiveX objects and build applications using the best features of all three technologies. Visual J++
comes with three wizards designed to greatly enhance the productivity of the Java programmer.
The Java Applet Wizard l
The Java Resource Wizard l
The Java Type Library Wizard l
These wizards, combined with a visual debugger, online documentation, and excellent development
environment, give the Java programmer an extremely flexible tool that can be used for standard Java
programming, as well as ActiveX programming.
Over time, it will become more apparent whether ActiveX's strengths are enough to overcome its
inherent weaknesses. Until then, it is likely that both technologies will coexist and continue to improve.
If this happens, it will be to the software developer's benefit.
Chapter 10 -- Extending Java Using ActiveX
http://docs.rinet.ru/WPU/ch10.htm (11 of 11) [4/22/1999 4:02:25 PM]
http://docs.rinet.ru/WPU/f10-1.gif
http://docs.rinet.ru/WPU/f10-1.gif [4/22/1999 4:04:05 PM]
http://docs.rinet.ru/WPU/f10-2.gif
http://docs.rinet.ru/WPU/f10-2.gif [4/22/1999 4:04:23 PM]
http://docs.rinet.ru/WPU/f10-3.gif
http://docs.rinet.ru/WPU/f10-3.gif [4/22/1999 4:04:32 PM]
http://docs.rinet.ru/WPU/f10-4.gif
http://docs.rinet.ru/WPU/f10-4.gif [4/22/1999 4:05:03 PM]
Chapter 9
Visual J++: Tools for the Internet and the
Desktop
by Bryan Morgan
CONTENTS
Introduction To Visual J++
Java + COM = First Class Citizen m
l
Microsoft's Component Object Model (COM) and ActiveX
The Birth of ActiveX: An Overview of COM and OLE m
OLE 1.0 m
OLE 2.0 m
ActiveX: Activating the Internet m
l
Comparing Java and COM
Java and COM: Some Differences m
Java and COM: Surprising Similarities m
l
Advantages and Disadvantages: A Close Look at Java and ActiveX l
Summary l
Introduction To Visual J++
Visual J++ is the name of Microsoft's first Java development tool. It was originally internally dubbed
Jakarta after the largest city on the island of Java, but Microsoft refrained from using yet another coffeeor
Java-related name for this product. The name Visual J++ can be taken to mean several different
things:
Visual J++ is a visual tool that uses standard GUI development techniques, such as resource
builders, syntax-aware editors, and graphical debuggers.
l
Visual J++ is integrated with Microsoft's "Visual" family of tools, including Visual C++ and
Visual Basic.
l
Visual J++ enables the developer to extend the capabilities of the Java language (that's where the
++ comes in).
l
At its most basic level of operation, Visual J++ provides a high-performance Java compiler, integrated
Chapter 9 -- Visual J++: Tools for the Internet and the Desktop
http://docs.rinet.ru/WPU/ch9.htm (1 of 17) [4/22/1999 4:05:26 PM]
development environment (with a resource editor, visual debugger, and visual editor), programming
wizards, and extensive online help capabilities. Standard Java applets and applications built using the
Microsoft Visual J++ tool set will run unmodified on any machine on earth that includes a copy of the
Java Virtual Machine (more on this later).
Had Microsoft stopped at that point and released a tool with these capabilities, Visual J++ would be
highly regarded for its excellent development environment and extremely fast compiler. Visual J++ uses
the Developer Studio environment, which also is used by the Visual C++ and Fortran Powerstation
products. The compiler can compile up to one million lines of Java code per second (on a standard
Pentium-based computer), which should place it near the top of the heap in compilation speed. As stated
earlier, had Microsoft stopped with these features, this chapter would focus primarily on the Java
language and its use in the development of applets and applications (a topic that has produced over 100
books in Java's first year alone!).
However, as you probably know by now, Visual J++ is much more than a standard Java compiler.
Microsoft has worked for several years to produce an object-based framework for the Windows platform
with the eventual goal of making this framework distributed and cross-platform.
NOTE
The term distributed here means that objects can be shared across
multiple computers. In other words, if an application were running on
your local machine, it could call into objects running on machines
elsewhere across the network. This enables applications to be
partitioned across multiple machines for performance reasons, and
improves maintenance because only one machine needs to be updated
in the case of software updates.
The term cross-platform is used in this chapter to represent computers
sharing information or programs even when the computers are
running different operating systems. An example of a cross-platform
environment is a network of Windows 95 and Apple Macintosh
computers using programming objects stored on a UNIX server.
Microsoft's object standard is known as the Component Object Model (COM), and the implementation of
this standard is personified in a group of technologies known as ActiveX. One ActiveX technology that
will be familiar to Windows developers is ActiveX controls. These components (formerly known as
OCX, or OLE, controls) are industry standard programming tools now used by many, if not most,
Windows programmers. A partial list of products that support the use of ActiveX controls is as follows:
MS Visual C++/Visual FoxPro/Visual Basic/Access, Borland C++/Delphi, Powersoft Powerbuilder, and
Oracle PowerObjects.
Why is ActiveX being discussed in a section about a Java compiler? This is what separates Visual J++
from every other Java tool on the market! The Visual J++ tool set, in combination with the Microsoft
Windows Virtual Machine for Java, will enable Java programmers to use ActiveX controls along with
Java applets. In addition, standard Windows applications can be built using Visual J++, ActiveX, and the
underlying COM. This will enable Windows developers to utilize the full power and elegance of the Java
language along with the huge existing base of COM objects in which many developers already have
invested.
Chapter 9 -- Visual J++: Tools for the Internet and the Desktop
http://docs.rinet.ru/WPU/ch9.htm (2 of 17) [4/22/1999 4:05:26 PM]
Java + COM = First Class Citizen
What does this mean for Windows and Java programmers? First of all, it means now that these two can
be one and the same. Just as there are Windows VB developers and Windows C++ developers, new
projects will soon be able to choose Java as a development choice. In short, Microsoft is elevating Java
from its already lofty status as a Web programming tool to that of THE Web programming tool and also
a Windows programming tool. Actually, in the near future it might become inaccurate to refer to Visual
J++ as simply a "Windows tool" because COM is gradually becoming a cross-platform object model
(more on this later).
Had Microsoft chosen to simply make Visual J++ a graphical layer over the standard Java tools, the
Visual J++ programmer could use Java to do the following:
Develop Java applets that can run within any Java-capable Web browser l
Develop Java applications that can run on any platform containing the Java Virtual Machine l
Develop Java applications that use native methods to call existing code written in other languages
such C or C++
l
With the extra capabilities that Microsoft has added to Visual J++, the Visual J++ programmer is able to
Develop Java applets that can run within any Java-capable Web browser l
Develop Java applications that can run on any platform containing the Java Virtual Machine l
Develop Java applications that use native methods to call existing code written in other languages
such C or C++
l
Develop ActiveX controls in Java (in an upcoming release of Visual J++) l
Build powerful Web-based applications using a combination of Java applets and ActiveX controls
that can be scripted together using any ActiveX scripting language such as JavaScript or VBScript
l
Develop Windows 95 label-compliant applications in Java using the growing libraries of Java
applets and the already extensive library of ActiveX controls
l
Develop Windows executables that consist of true binary code that can run at native machine
speeds and use the elegance of the Java language
l
As you can see, the first three items in this list are possible using virtually any Java tool on the market
today. Despite many Java programmers' fears that Microsoft would release a proprietary tool that would
somehow pollute the Java waters, these fears are unfounded. A key point is that Visual J++ is a great tool
to use for non-ActiveX and ActiveX Java development. After all, despite the explosive growth and
potential of the World Wide Web, it will be quite some time before the majority of applications
developed are designed to run only within a Web browser.
The Java language has grown faster than any other programming language in the history of computing.
Because nearly all of the Java demonstrations and press coverage of Java have focused on its use as a
World Wide Web development tool, many developers might not realize that Java can be used to write
stand-alone applications with advanced graphical user interfaces. Because Microsoft Windows is the
most widely used operating system in the world today, and because of the vast amount of existing code
already written for the Windows platform, an ideal software development tool would enable the Java
Chapter 9 -- Visual J++: Tools for the Internet and the Desktop
http://docs.rinet.ru/WPU/ch9.htm (3 of 17) [4/22/1999 4:05:26 PM]
developer to combine the best of the Web world with the best of the Windows world. For many
developers, Visual J++ will be that tool.
Although Visual J++ will obviously be used by many for the development of standard Java applets for
Web distribution, Microsoft must be credited for realizing that the Java language itself is a great
programming language. Because of the features of the Java language and the impetus behind it,
Microsoft extended Visual J++ and the Windows Virtual Machine for Java to enable Java applications to
incorporate existing ActiveX controls. Using Visual J++, ActiveX controls and Java classes are identical
to the Java programmer. This is possible because of the Microsoft Java Virtual Machine and the
underlying similarities between Java and Microsoft's Component Object Model. The following section
discusses the evolution of COM and ActiveX and concludes by showing how the Java language and
COM fit together nicely. The chapter then concludes with a discussion of the benefits and weaknesses of
Java and ActiveX.
Microsoft's Component Object Model (COM) and
ActiveX
The next chapter focuses on using Visual J++ to develop full-featured Windows applications using
Microsoft's ActiveX technologies. Many developers might wonder: Exactly what is ActiveX and where
did it come from? Although it was announced by Microsoft in 1996, believe it or not, it has actually been
around for several years and nearly all Windows developers have used some form of it at one time.
Before diving into ActiveX, however, the history of the Component Object Model (COM) and Object
Linking and Embedding (OLE) are examined.
The Birth of ActiveX: An Overview of COM and OLE
COM provides the basis for nearly all of Microsoft's new products. It is, in theory, a
platform-independent, vendor-independent, and language-independent model for developing applications
using intercommunication among binary objects. These objects communicate with each other using a set
of predefined interfaces that each object chooses to implement.
NOTE
An interface is a set of related functions that can be implemented by
an object. If an object chooses to implement an interface, all of the
functions specified by that interface must be implemented.
Each object is defined by which interfaces it chooses to implement. (For example, if a developer wanted
an object to be saved to disk, he or she could implement what is known as a structured storage interface.)
Note that the words in theory are used in the previous paragraph to describe the COM standard's
cross-platform capabilities. Although a COM infrastructure could be written for any operating system,
the fact remains that at the present time it is available only for the Windows family of operating systems.
Microsoft recently has announced plans to assist Metrowerks in porting COM to the Apple Macintosh
and currently is working with Bristol and MainSoft to port COM to UNIX. However, at the current time,
developers should realize that using COM objects in an application will limit the platforms on which that
Chapter 9 -- Visual J++: Tools for the Internet and the Desktop
http://docs.rinet.ru/WPU/ch9.htm (4 of 17) [4/22/1999 4:05:26 PM]
application will run. This possible drawback is discussed later in the "Advantages and Disadvantages: A
Close Look at Java and ActiveX" section.
COM: Specification and Implementation
COM is both a specification and an actual implementation. The COM specification specifies a binary
standard for implementing the object, which is language-independent. Therefore, a COM object could be
written using Delphi, Visual Basic, C++, or-you guessed it-Java. All that is required is that a specific set
of functions be provided by your object so that the object's provided interfaces can be queried.
The COM implementation is provided in the form of a Windows dynamic link library (DLL). This DLL
exports a small number of API functions that enable the programmer to instantiate a component object
using a unique class identifier known as a Class ID. What is important to realize is that COM, by itself,
simply provides the "rules" for which objects can be instantiated and can intercommunicate among
themselves. All of these objects can be combined to make an application. With the advent of Distributed
COM (DCOM), these objects can be located anywhere across a network. This functionality is a core part
of Windows NT 4.0.
Using COM Objects
Although COM is destined to be an integral part of future Microsoft operating systems, COM has never
been an active topic of discussion among most Windows developers. This is because COM, by itself,
does not specify any applicable, real-world objects that can be used by developers to create applications.
Instead, COM is the object model that developers can use to integrate several objects into a working
application. These objects could come from a variety of sources. Here are some examples:
A COM object could be written in C++ and provide spell-checking if given a large string of text. A
Visual Basic programmer could then instantiate the spell-check object, pass it a string of text, and
reuse that functionality. Now imagine that the word processing software installed on all machines
in your office was made up of a set of COM objects, one of which was a spell-check object. One
nice thing about this model is that shrink-wrapped applications can in turn become programmable
objects themselves; therefore, you could reuse powerful functionality already existing in desktop
software products.
l
A geographical information system (GIS) residing on a remote server could be used to store
mapping and statistical data for your enterprise. If that GIS were built using DCOM objects, an
application could be written so that users across the network could reuse these DCOM objects to
display custom maps within local applications.
l
COM-enabled applications such as spreadsheets and word processors could enable COM objects
to be inserted directly into a document. This would enable multiple applications to be integrated
together so that the document rather than the application would become the focus. This has long
been a "Holy Grail" of personal computing, and COM enables this to be done today using OLE
(which is discussed in the following section, "OLE 1.0").
l
Although it is completely possible to write from scratch COM objects that are fully compliant with the
binary specification, most Windows developers have never done this. Instead, programmers who want
the functionality provided by the COM object model have historically relied on a framework that lies on
top of COM known as OLE. OLE stands for Object Linking and Embedding and is the parent of what is
Chapter 9 -- Visual J++: Tools for the Internet and the Desktop
http://docs.rinet.ru/WPU/ch9.htm (5 of 17) [4/22/1999 4:05:26 PM]
now known as ActiveX.
OLE 1.0
As the name implies, Object Linking and Embedding was originally a technology used by Microsoft to
link together desktop application products. This was provided so that users could do things such as insert
a Microsoft Excel spreadsheet into a Microsoft Word document. As the user scrolls through the Word
document and comes upon the Excel spreadsheet, he or she could double-click the Microsoft Excel icon
to launch a copy of Excel and view or edit the spreadsheet.
Although the OLE standard at this point was much simpler than what exists today, it still enabled
inter-application communication and data exchange. After OLE 1.0 was developed, the methodology was
well-documented and supported by Microsoft, and soon many applications appeared that enabled their
application objects to be integrated together. In a short time, OLE became the standard way for
applications to interoperate. Because of OLE1's success, Microsoft realized it could provide the
foundation for a more generic object framework that gave the user and developer many more capabilities.
At the same time, Microsoft began to aggressively position itself as an enterprise system provider using
Windows NT as a network server and products such as SQL Server for database operations. In the
Microsoft scheme of things, all desktop machines would be running some variant of the Windows
operating system. These machines would be able to communicate among each other using a Windows
NT-controlled network and could share information using products such as SQL Server and Exchange. In
such a networked environment, DCOM would enable applications (or even operating systems!) to be
distributed across the network for scalability and administration reasons.
As Microsoft's rapid growth in this area coincided with the development of OLE 2.0, this release of OLE
became much more than a mechanism for combining documents.
OLE 2.0
OLE 2.0 was released in 1993, and some improvements were immediately visible. OLE 2.0 applications
not only could embed documents created by other applications, but these documents could also be edited
and updated directly within the "container" document.
If the user were to edit a Microsoft Word document that contained a chart, the application would appear
to be Microsoft Word. However, if the user double-clicked the chart, OLE 2.0 enabled the application to
essentially "morph" into Microsoft Excel (see Figure 9.1). The user then could operate on the chart using
the Excel menus and options, and immediately switch back to the word processing functionality provided
by Word after the chart had been edited.
Figure 9.1 : An example of OLE 2.0 in-place activation.
This capability was termed in-place activation and notified the world that OLE 2.0 was truly ready for
prime time. After programmers took the time to analyze the OLE 2.0 specification, it became apparent
that OLE2 was in fact a large set of advanced features that offered programmers capabilities that, in the
past, would have been impossible to implement. Figure 9.2 illustrates the features provided by OLE2 and
the following section explains each of these features briefly.
Figure 9.2 : OLE 2.0 features.
Chapter 9 -- Visual J++: Tools for the Internet and the Desktop
http://docs.rinet.ru/WPU/ch9.htm (6 of 17) [4/22/1999 4:05:26 PM]
Features Provided by OLE 2.0
OLE 2.0 is basically a large grouping of COM-compliant objects that can be conveniently grouped into
several primary categories:
Compound documents l
Drag-and-drop l
Uniform data transfer l
Compound files l
Monikers l
OLE controls l
Automation l
Each of these categories relies on the underlying Component Object Model to specify how the objects
interoperate with each other.
Compound Documents
The portion of OLE2 known as compound documents concerns itself with the linking and
embedding of objects. To fully understand what a compound document is, you must first
understand what it means to "link" and "embed" objects.
Objects are linked when the following steps occur:
A portion or all of a file's contents created by Application1 is inserted into a file
created by Application2.
1.
The portion of Application1's file is designated as a link within Application2. 2.
When Application1's file is modified, these changes become apparent when you are
viewing Application2's file.
3.
Objects are embedded when an object created by one application is visually and physically
part of a file created and displayed by another application instance. Figure 9.1 shows an
example of embedding.
To give you an idea of the amount of progress made between OLE1 and OLE2, OLE1
essentially consisted of two subsets of compound documents: linking and embedding.
Obviously, OLE2 was a huge leap forward! You can think of an OLE2 compound document
as providing three possible features:
Object embedding. Object embedding enables an application to act as a container of data from a
variety of other OLE-capable sources. Examples of OLE2 object embedding are a Word document
containing an Excel chart, a PowerPoint presentation containing a sound clip for playback during a
presentation, and a Web browser playing a video file within a Web page using OLE operating
system components.
l
Object linking. Object linking occurs when the inserted object's data actually resides within
another file on a file system. When this linked file is updated, the container document will
automatically see these changes the next time it is opened or updated. This is because the container
document can be thought of as containing a "pointer" to that file rather than containing the file's
actual data. This "pointer" is known as a moniker and contains information about the linked file
l
Chapter 9 -- Visual J++: Tools for the Internet and the Desktop
http://docs.rinet.ru/WPU/ch9.htm (7 of 17) [4/22/1999 4:05:26 PM]
and its contents.
In-place activation. In-place activation is also commonly referred to as Visual Editing (a term that
is trademarked by Microsoft). This is perhaps the coolest and most visible feature of OLE2.
In-place activation enables all objects to be edited within their container application without
calling up new windows to confuse the user. Instead, the container's surrounding menus and
window changes to represent the application of the object being edited.
l
You can extend the concept of in-place activation by thinking of a generic container application
that is basically a shell. Instead of calling up a word processor or spreadsheet to begin a document,
you could open this shell application and add objects to the document as needed. Combine this
idea with the notion of Distributed COM, and you can envision an environment in which these
objects can lie anywhere across a very large network. Instead of loading huge, monolithic
applications onto your hard drive, in the near future you might have the option of downloading
application objects for use in document creation. With the advent of DCOM in the fall of 1996,
this "app of the future" might not be as far off as you might think.
l
Uniform Data Transfer
All data transfers that occur among OLE2 objects use the technology known as Uniform
Data Transfer. This capability provides the definition of something known as a data object.
A data object is a single piece of code that can be used in all data transfers: DDE, OLE,
drag-and-drop, and Clipboard transfers. Note that this data transfer does not necessarily take
place through memory. OLE2 enables the programmer to perform data transfer using files,
memory, or any other methodology that the programmer chooses. Once again, looking into
the future, one can envision transfer methods such as FTP or HTTP for extending what we
now think of as OLE2.
Drag-and-Drop
In most GUI environments such as Macintosh, Motif, or Windows, users have had the
capability to drag and drop items within applications or from File Manager-type
applications. OLE2 takes this functionality a step further by enabling any data object from
any application to be dragged and dropped into any other OLE2 application that supports
this feature. Essentially, any data object that can be copied to the Windows clipboard can be
used with drag and drop.
Compound Files
You can think of compound files as files within files. Programmers building files using
OLE2 compound files can literally create directory trees within files for storing different
types of data. Compound files also can contain data created by several different applications.
Because compound files are composed of a tree-like structure, you can query compound
files for information such as author, modification date, and other features. An example of a
compound file that is an integral part of all Windows systems now is the Windows Registry.
Under Windows 95, you can examine the Registry by running REGEDIT.EXE. Under
Windows NT, this file is called REGEDT32.EXE.
Monikers
Monikers are used to provide links between objects on a system (or across a distributed
Chapter 9 -- Visual J++: Tools for the Internet and the Desktop
http://docs.rinet.ru/WPU/ch9.htm (8 of 17) [4/22/1999 4:05:26 PM]
system). A moniker is another word for a nickname, and you can think of OLE2 monikers as
a type of nickname. Monikers are basically nicknames that identify the source of data and
understand how to bind an application to that data. There are many different types of
monikers in OLE2, including File, Pointer, and Item monikers.
OLE Controls
OLE Controls, or OCX Controls as they are often called, carry on the spirit of the VBX
controls introduced with Visual Basic 3.0. Unlike VBX controls, which are special-case
16-bit DLLs, OLE Controls can be 32-bit controls that implement a standard set of OLE2
interfaces. The result is a programming object that can be used at design-time (in a
development environment such as Visual Basic or Delphi) and at runtime within an
application. These controls are language-independent and have been extremely successful.
At the present time, over 1,000 OLE Controls are commercially available.
Automation
OLE Automation is a technology that is included within the OLE2 umbrella. However, in
many ways it is much larger than OLE2. An application can support OLE Automation by
exposing its desired functionality through a set of interfaces. These interfaces can then be
used to manipulate (automate) the application by another piece of code. Visual Basic is
commonly used to control Microsoft Office applications through the use of OLE
Automation. (In fact, there are whole books written on that topic alone!) Through the
process of OLE Automation, programmers can choose the language and tool they would like
to use to control other programmable objects. OLE Automation is included in most
discussions of OLE2 because it uses the underlying Component Object Model as a blueprint
for inter-object communication.
All of these technologies represent a huge investment for Microsoft. Thousands of hours and
millions of dollars have been spent to build an object framework for the Windows platforms.
With the advent of DCOM in the very near future, Microsoft is positioned to finally
compete and interoperate with other popular object models such as Distributed Computing
Environment (DCE) and Component Object Request Broker Architecture (CORBA). From
Microsoft's point of view, it is clear that technologies such as the World Wide Web and Java
can be used to interoperate with their existing code infrastructure. To do this, Microsoft has
introduced a trimmed-down version of OLE2 known as ActiveX to truly activate the
Internet.
ActiveX: Activating the Internet
The wary reader might by this point be wondering where this discussion is headed. After all, on one hand
you have learned the Web and Java's use in building networked, platform-independent applications. On
the other hand, you have learned OLE and its capabilities for building object-based applications on the
Windows platform. Now the two technologies will be brought together using the magic of COM and
Windows Virtual Machine for Java.
In 1995, all Microsoft projects were issued a well-publicized edict to Internet-enable every product if
possible. The results of that request are beginning to be seen nearly a year later as Microsoft is releasing
a flood of products aimed at corporate and independent Web developers. (Visual J++ is one of the
Chapter 9 -- Visual J++: Tools for the Internet and the Desktop
http://docs.rinet.ru/WPU/ch9.htm (9 of 17) [4/22/1999 4:05:26 PM]
products leading this charge.) While OLE2 was introduced to address the needs of desktop software
developers and system integrators, in the previous section you learned many topics that could clearly be
applied to networked applications. Like all other Microsoft products, OLE2 was thoroughly examined
from an Internet point of view and the resulting set of transformed technologies has been named
ActiveX. Many pieces of OLE2 have been completely reworked for maximum performance benefits for
Web usage, while other technologies basically have been renamed and remarketed as ActiveX
technologies.
Like its parent, OLE2, ActiveX cannot be summed up as one simple technology. Instead, it can be
broken into several parts, all of which can be thought of collectively as Microsoft's ActiveX architecture.
The following highlights the key ActiveX technologies and draws a parallel between them and their
parent OLE2 technologies.
What Is ActiveX?
ActiveX is the name of a group of related technologies from Microsoft that is designed to enable
developers to provide active Web content. Although at the current time ActiveX is a Windows-only
technology, implementations for the Macintosh and UNIX operating systems are slated for release in the
near future. When this platform independence is a reality, ActiveX will enable software developers to
choose their language and tools, reuse existing inventories of objects, and develop extremely powerful
distributed applications for use on a variety of operating platforms. It will do this using a variety of
technologies that exist under the ActiveX umbrella, including
ActiveX documents l
ActiveX controls l
ActiveX scripting l
ActiveX-enabled Internet protocols l
ActiveX APIs l
Microsoft Windows Virtual Machine for Java l
ActiveX Documents
ActiveX documents can be thought of as Internet-aware OLE2 compound documents. An
ActiveX-enabled Web browser such as Microsoft Internet Explorer can download a Word
document from a Web browser and immediately know how to display that file through the
use of ActiveX documents. This technology continues Microsoft's information-centric
approach, which enables users to concentrate more on an application's content than on the
application itself.
ActiveX Controls
ActiveX controls are extensions of the OLE controls mentioned earlier in this chapter. In
fact, in many instances there is no difference at all between an ActiveX control and an OLE
control. Microsoft simply reduced the number of interfaces that an ActiveX control is
required to implement. Potentially, this enables ActiveX controls to be much smaller than
their OLE counterparts. However, in many situations the same interfaces will be required to
be implemented.
Chapter 9 -- Visual J++: Tools for the Internet and the Desktop
http://docs.rinet.ru/WPU/ch9.htm (10 of 17) [4/22/1999 4:05:26 PM]
ActiveX Scripting
ActiveX scripting extends the concept formerly known as OLE Automation by adding
scripting capabilities to Web pages, programs, or even server applications. ActiveX
scripting enables scripts to be written in a variety of languages because it uses two
components: a scripting host and a scripting engine. The scripting host is an application that
is responsible for creating the scripting engine. The scripting engine in turn is responsible
for processing and performing the script commands. Examples of scripting hosts include
Microsoft Internet Explorer l
Future Microsoft Server products l
Various Web authoring tools including Microsoft FrontPage l
Scripting engines are currently available for Visual Basic for Applications (VBA), Visual
Basic Scripting Edition (VBScript), and JavaScript.
ActiveX-Enabled Internet Protocols
Common Internet protocols such as FTP and HTTP can use ActiveX technologies such as
monikers (equivalent to an OLE moniker). These monikers can serve as pointers to
applications and can be interpreted by ActiveX server products in order to link applications
to the Internet.
ActiveX APIs
An entire suite of ActiveX APIs is available through the ActiveX Software Development Kit
(SDK). These APIs enable software developers to extend traditional Windows-based
programs with Internet capabilities such as file transfer and Web server access.
Microsoft Windows Virtual Machine for Java
The final component of ActiveX that you will learn is the Microsoft Windows Virtual
Machine for Java. This Java Virtual Machine is designed to both run standard Java applets
and also expose Java applets as COM objects for their use in ActiveX applications. The
Windows Virtual Machine for Java also enables Java applets to coexist with ActiveX
controls because to the programmer, both are just objects composed of properties, methods,
and events.
Comparing Java and COM
Visual J++ is the first product to combine two extremely popular technologies: Java and COM. This is
possible because the two are extremely similar on many levels. This section summarizes the capabilities
of Java and COM and discusses why they fit together very well.
Java and COM: Some Differences
From the outset, it is obvious that in some ways Java and COM are very different technologies. Most
notably, Java is a programming language, and COM is an object model that specifies how objects created
in any programming language must interact. However, it is fair to say that Java objects and COM objects
can be compared and contrasted.
Chapter 9 -- Visual J++: Tools for the Internet and the Desktop
http://docs.rinet.ru/WPU/ch9.htm (11 of 17) [4/22/1999 4:05:26 PM]
Java objects are not distributed. Although it is true that Java objects can be stored on remote servers,
these objects must actually be uploaded to the client machine before they can be used to run an applet
within a browser. Meanwhile, DCOM objects can be stored on a remote machine and can be called from
that remote machine using a Remote Procedure Call (RPC).
Java applets are designed with specific security restrictions. These restrictions include the incapability to
call code on any server other than the originating server and the incapability to make local operating
system calls. COM objects have full access to the underlying operating system and rely on a completely
different security model that revolves around a concept known as code signing.
Java classes are not required to implement interfaces (groups of related functions that can be thought of
as a unit). The Java programmer can choose to implement zero or more interfaces for each Java class.
COM objects are required to implement at least one interface: IUnknown. This interface then is used to
determine specific information about the object and to acquire new interfaces if necessary.
Java also uses a technique known as garbage collection for automatic memory management. When the
system knows that an object is not going to be used any longer, the Java runtime system automatically
frees that object's memory. Memory management with COM produces an equivalent result to produce
automatic memory management. Instead of garbage collection, however, COM tracks the reference
count, or the number of instances using an object. When the reference count drops to zero, that object is
freed in memory.
Java and COM: Surprising Similarities
Despite the differences mentioned in the previous section, the number of similarities between Java and
COM is very interesting (and an excellent sign that both technologies benefit from a good design!). This
is probably not surprising if one stops to really think about what both Java and COM were designed to
solve. They both were intended to be
Platform-independent l
Object-oriented l
Multi-threaded l
Dynamic l
To start with, Java and COM both require a foundation underneath them to support their
platform-independent claims. Java's foundation is known as the Java Virtual Machine, whereas COM
requires an implementation of the Component Object Model for each specific platform. After this
foundation is in place, both systems rely on objects that are created on the fly and are dynamically linked
together at runtime.
Even the way that the objects are defined is similar in some respects. Java uses a .class file format
that is well-documented. The class file defines the contents of the internal class and any interfaces it
implements. COM uses a .tlb (type library) file to define the contents of the COM object and any
interfaces it implements. A key factor in the operation of the Windows Virtual Machine is its capability
to create type libraries from Java classes and likewise create Java classes from COM object's type
libraries.
Chapter 9 -- Visual J++: Tools for the Internet and the Desktop
http://docs.rinet.ru/WPU/ch9.htm (12 of 17) [4/22/1999 4:05:26 PM]
As you might have noticed by now, both rely heavily on the use of interfaces. Interfaces enable objects to
implement a related set of functions for an object. The intent of these interfaces is generally documented,
therefore the interface serves as a sort of contract between one object (the implementor of the interface)
and another (the user of the interface). Java and COM both use classes (a concept familiar to
object-oriented programmers) to group together related functions and data.
One feature of many systems and languages is exception handling. Exception handling enables the
developer to trap errors and handle them accordingly so that the program will not simply crash. Java
handles exceptions through the use of the Throwable interface. COM handles exceptions through the use
of the IErrorInfo interface.
Advantages and Disadvantages: A Close Look at
Java and ActiveX
Because of the excitement surrounding Java since its introduction in 1995, the software development
community has enthusiastically supported Java and pushed it to the forefront of Web development.
However, like all new technologies, it has some advantages as well as disadvantages. ActiveX is no
different than Java in this respect. You learn these strengths and weaknesses here so that you are well
aware that no technology by itself can solve every problem out there. As with all complicated
undertakings, a variety of issues need to be weighed before decisions are made.
Java's greatest advantage might be that it is the most powerful, ubiquitous programming language that
enables developers to create platform-independent code. Unlike most other cross-platform tools, the Java
developer actually has to make an effort in order to add platform-dependent code to the application at
hand. Java programmers can thank the availability of the Java Virtual Machine for this feature.
NOTE
Although it is true that Java is not truly platform-independent without
the availability of a Java Virtual Machine, the fact is that the JVM is
available now (or will be soon) on nearly every popular operating
system in widespread use today.
Java is also object-oriented. This is truly an advantage because of the large effort made over the last few
years to train programmers to think in terms of objects and designing systems this way. Object-oriented
programming has been demonstrated repeatedly to improve productivity through a systematic approach
to object design and analysis.
Java's object-oriented structure and platform independence are also enabling it to be quickly "retrofitted"
to Component Object Request Brokers for use in building distributed applications. In fact, the Netscape
Navigator 4.0 Web browser will include ORB client software by Visigenic for use in building
distributed, object-based applications using the Netscape Open Network Environment (ONE) platform.
Even though Java was introduced by Sun Microsystems, it remains largely a vendor-neutral architecture.
Sun Microsystems originally developed the JVM for Sun Solaris, Apple Macintosh, and Windows
95/NT, but JVMs have now been developed by many other corporations, including IBM, Microsoft, and
Netscape. Developers deciding to develop applications using Java can choose from a broad range of tools
Chapter 9 -- Visual J++: Tools for the Internet and the Desktop
http://docs.rinet.ru/WPU/ch9.htm (13 of 17) [4/22/1999 4:05:26 PM]
from a variety of vendors and are not tied exclusively to Sun Microsystems' line of products.
Java also has the advantage of widespread acceptance and near-ubiquity. It is rapidly becoming the
programming language of choice for Web solutions and is being used for actual product development
now for things like Web server software, collaboration systems, and desktop applications. Business
analysts often discuss the topics of market share and mind share. While market share is of course the
universal indicator used to judge the success or failure of a product, mind share is a much more difficult
and subjective indicator to measure. For developers trying to decide whether to implement a pure Java
solution or an ActiveX solution, the decision becomes extremely difficult because of these two
measuring sticks.
In terms of product support and existing lines of code, ActiveX is the market share leader because it
effectively existed as OLE for several years already. However, developers who try to keep a finger on the
pulse of the computing community realize that Java has captured an ever-increasing mind share of the
programming audience. For Sun Microsystems, the maturation of Java and its role in it will determine if
that mind share can be converted into market share at a future time for its software and hardware
products.
A lack of existing code and experienced programmers in some ways are drawbacks to implementing
standard Java applications. Although advanced class libraries, thousands of existing controls, and several
excellent tools exist for the ActiveX developer, the Java programmer is often forced into the
"roll-your-own" mode of development. Naturally, it is through this trial by fire that beginning Java
developers turn into expert Java developers, but in some cases the business case for new Java
development might be hard to sell when compared to existing partial solutions that already exist in the
form of ActiveX.
For example, several ActiveX controls that enable developers to create impressive charts and graphs that
appear to the user as full-featured mini-applications now exist. These controls are relatively inexpensive
($99-$299) and many employ internal object models for ease of development. To date, there is no Java
applet available that approaches the sophistication of these controls, and because of Java applet's security
restrictions, some features on these applets might never be implemented to compete directly with their
ActiveX counterparts.
The huge interest in Java and its related technologies has also made it increasingly difficult for
businesses to find truly qualified programmers. It is common to hear HTML designers who have
included an applet within a Web page refer to themselves as Java programmers. The truly seasoned
developer can use the Web to his or her advantage however, by publishing work samples on the Web for
all to see. A well-placed URL on a resume can go a long way to quieting someone's anxiety when they
examine your resume.
Perhaps Java's biggest drawbacks come in the area where it is the most visible: the Web browser client.
Because rogue applets can damage a user's system, the designers of Java built it around a strict security
model that treats applets extremely carefully within most Web browsers. This security model prevents
applets from
Accessing the local hard drive l
Communicating with any server other than the originating server l
Making any calls to the local operating system l
Chapter 9 -- Visual J++: Tools for the Internet and the Desktop
http://docs.rinet.ru/WPU/ch9.htm (14 of 17) [4/22/1999 4:05:26 PM]
Java applets also have no persistence. Because Java is object-oriented and each class can derive from
another class and implement several interfaces, when an applet is uploaded to a Web browser, it can
require the uploading of one, two, maybe twenty other class files with it. Because these applets are not
persistent, the next time the user visits that Web site, this same group of applets will need to be reloaded
all over again. In an intranet setting where users will continually upload the same Java applets over and
over again, it is possible that the users could install local versions of these applets, but Java provides no
"self-installation" capabilities.
One final weakness of Java that should be pointed out is that it is an interpreted language and suffers
from poor performance without the existence of a Just-In-Time compiler. Just-In-Time (JIT) compilers
actually compile Java code into native machine code on the fly after the applets have been downloaded
so that the applets can have improved performance. This feature is included in the Netscape Navigator
3.0 browser and the Microsoft Internet Explorer 3.0 browser. Even with the existence of a JIT compiler,
Java code still runs slower than comparable "C" code, and this point should be considered. A general rule
of thumb is that whenever a task is I/O-bound (such as user interface operations), the slower language
probably will not make a difference. However, in tasks that are CPU-bound (such as mathematical
operations), the interpreted language will force your code to take a performance hit.
Native ActiveX controls are natively compiled, dynamically linked code modules that run without the aid
of an interpreter. This enables them to boast a performance advantage over comparable Java applets.
Although it is easy for developers to say that machines today are fast enough where performance
differences probably will not matter, keep in mind that we are often writing for the lowest common
denominator. I have been in many situations in which software ran just fine on my souped-up
development machine only to see it suddenly crawl on a user's less-capable box.
ActiveX controls also are, for better or worse, persistent on a client's local systems after being
downloaded the first time. At the present, Microsoft Internet Explorer does not automatically remove
these controls when the browser exits. Instead, these controls reside indefinitely until the user deletes
them. Microsoft has stated that control removal will be an option in later versions of Internet Explorer.
Some ActiveX technologies such as ActiveX controls also benefit from the large existing code base.
Well over 1,000 ActiveX controls currently exist that will run within an Internet Explorer or Netscape
Navigator page. This is a double-edged sword however, because the Windows platform is the only
platform on which these controls can be used. Platform-dependence is without a doubt the primary
drawback to implementing ActiveX Web sites. Until COM becomes available for other popular operating
systems such as Macintosh and UNIX, ActiveX might remain primarily an intranet development
technology. This is because within an intranet, Web designers usually are able to pinpoint exactly which
machines will be using a Web-based application and can plan their design accordingly.
ActiveX controls have a truly distinct advantage: language independence. These controls can be built
using a variety of popular products including Visual Basic 5.0, Visual C++, Delphi, and future versions
of Visual J++. In addition, they are not simply a Web-only solution. As mentioned earlier, ActiveX
controls currently are being used by Delphi, Visual Basic, C++, and even COBOL developers
worldwide. This capability alone ensures that ActiveX will continue to grow in the future regardless of
the success of Java and other technologies.
The lack of browser support could possibly slow the adoption of ActiveX for Web-based development.
Because Netscape Navigator is the market leader (remember the discussion on market share earlier?) and
Chapter 9 -- Visual J++: Tools for the Internet and the Desktop
http://docs.rinet.ru/WPU/ch9.htm (15 of 17) [4/22/1999 4:05:26 PM]
because Netscape has chosen not to implement ActiveX support within its browser, users are being
forced to decide between the two market leaders, Microsoft and Netscape. Although users can download
an ActiveX Netscape plug-in from NCompass Labs that will enable Netscape to use ActiveX controls,
very few users (relative to the total number of users) have chosen to do so. Once again, the topic of mind
share versus market share is brought up. If Microsoft Internet Explorer suddenly experiences a dramatic
increase in mind share among "power users," this could only help ActiveX and its related technologies.
One can only hope that the end user will be the eventual winner of the browser "wars," and that the best
technologies will survive in the long run.
Summary
Visual J++ is an extremely powerful development tool that can be used for a wide variety of
undertakings. Java applets and applications can be created using this product making it a valuable
resource for the World Wide Web programmer who decides to program using the Windows platform. In
addition to these capabilities, Visual J++ is the first tool to enable Java and the Component Object Model
(COM) to be combined in the application development process. The Windows Virtual Machine for Java
enables Java classes to be treated as COM objects. Because of this, Java classes can be used both for
interactive Web content as well as for building powerful Windows-based applications.
Visual J++ also will enable the reverse process to take place. In other words, COM objects can be used
side by side with Java objects to produce the most powerful (and flexible) application possible.
Capabilities within Microsoft's Internet Explorer browser enable this functionality to be carried over to
the Web as well.
COM objects that act as plug-and-play programming tools are known as ActiveX controls. These
controls are descendants of the popular VBX controls introduced in Visual Basic 3.0. ActiveX controls
are programming objects that expose a set of properties, methods, and events that can be used by the
programmer to construct applications from other's code. Because COM is a language-independent
standard, ActiveX-enabled Java classes can now be used in common Windows programming
environments such as Visual J++, Visual C++, Delphi, PowerBuilder, Visual Basic, Access, and many
others. ActiveX-aware applications such as the Microsoft Office suite (Word, Access, Excel, and
PowerPoint) can also use ActiveX controls to create powerful, custom-built applications.
In short, Visual J++ satisfies the needs of Web developers and also introduces Java to a much broader
programming audience. Using this tool, Java might soon be the Windows programming language of
choice as well as the unquestioned programming language of choice for the World Wide Web.
At the end of the chapter you learned the strengths and weaknesses of the Java and ActiveX technologies.
Issues such as performance, platform-independence, and vendor support will apparently continue to be
key factors in designers' decisions despite the early promise of the World Wide Web.
Chapter 9 -- Visual J++: Tools for the Internet and the Desktop
http://docs.rinet.ru/WPU/ch9.htm (16 of 17) [4/22/1999 4:05:27 PM]
Chapter 9 -- Visual J++: Tools for the Internet and the Desktop
http://docs.rinet.ru/WPU/ch9.htm (17 of 17) [4/22/1999 4:05:27 PM]
http://docs.rinet.ru/WPU/f9-1.gif
http://docs.rinet.ru/WPU/f9-1.gif [4/22/1999 4:06:17 PM]
http://docs.rinet.ru/WPU/f9-2.gif
http://docs.rinet.ru/WPU/f9-2.gif [4/22/1999 4:06:26 PM]
Chapter 8
Java Programming
by Dan Joshi
CONTENTS
Java Applets
Java Applet Example m
HTML Tags for Java Applets m
l
appletviewer l
Applets (java.applet.Applet)
The Applet Life Cycle Discussion m
The Applet Life Cycle Workshop m
The Logo Version 1.0 m
Fonts, FontMetrics, and Colors m
l
Animation
Animation in the PC Industry m
Animation Workshop m
A Summary of anilogo m
Optimizing Animation m
l
UI and Java
Command Buttons m
Check Boxes m
Choice m
Labels m
Lists m
Scrollbars m
Text Fields m
Text Areas m
Putting Components in Containers m
l
The UI and Java Workshop, Win Version 1.0
Frames m
Frames Workshop m
l
Summary l
What makes Java such a powerful tool for Internet development? Can Java can be used outside of the Internet? The
answer to both of these questions is yes. Java is a fully functional, object-oriented programming language. With new
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (1 of 55) [4/22/1999 4:07:07 PM]
features included in it, Java has definitely defined a niche for itself on the Internet. This chapter describes Java in the
Internet environment.
Every exercise in this chapter can also be used on a Java-compliant browser (such as Netscape 2.0 or later). More
important, the topics described here include tables of methods and constants available to Java applets and programs. This
chapter not only gives an introduction to Java applets, it also serves as a reference as you develop new applets. Note that
due to the limited space and time, the tables include only the methods most useful to the programmer. Some methods are
either not used or are rarely used by the programmer; these have been removed from the tables to keep only the most
useful methods at your disposal. This chapter assumes that you have a complete understanding of the HTML
environment and that you have a Java-compliant Netscape browser version 2.0 or higher. It also assumes that you are
familiar with the basic Java structure and objects that you learn in Chapter 7 "Introduction to Java."
Java Applets
The first level that any Java programmer (or HTML programmer) needs to understand is how to put an applet in your
HTML page. This is the first and often most frustrating major challenge for most people new to the Java environment. It
is so frustrating primarily because it is simple, and the browsers are very forgiving when it comes to incorrect HTML
code. You might not see an error message, but your applet still won't be loaded on the screen. Your first step is to design
a sample HTML page. Assume that you have a newly created Java applet called MyClass.class. All of the HTML
attributes pertaining to a Java applet must be placed between the <APPLET> and </APPLET> tags. The following
segment of HTML code shows how to put the applet on the home page:
<APPLET CODE=MyClass.class WIDTH=300 HEIGHT=300>
</APPLET>
NOTE
A common mistake that new programmers make is forgetting to put
the </APPLET> tag at the end of the applet section on their HTML
page. Consequently, the browser does not load the applet. It is not
always correct to assume that when an applet does not show up on the
HTML page, there is a problem with the applet.
Note that in this case you must have the file MyClass.class in the same directory as the HTML file.
Java Applet Example
Next, you will develop a sample applet to learn how to use an applet on the Internet (and more specifically, on a Netscape
browser). Listing 8.1, which appears on the accompanying CD, shows the first applet you will create, which says "Hello
World." Create a file called HelloWorldC.java and type in Listing 8.1.
Listing 8.1. The "Hello World" program.
import java.awt.Graphics;
public class HelloWorldC extends java.applet.Applet {
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (2 of 55) [4/22/1999 4:07:07 PM]
public void paint(Graphics g) {
g.drawString("Hello World", 5, 50);
}
}
Just to refresh your memory on how to compile programs using the Java Development Kit (JDK), make sure that the Java
compiler and the HelloWorldC.java program are in the same directory. Then type the following:
javac HelloWorldC.java
The next step is to create an HTML file called index.html. Listing 8.2 shows you how your index.html file
should look.
Listing 8.2. The index.html program.
<HTML>
<APPLET CODE=HelloWorldC.class WIDTH=200 HEIGHT=100>
</APPLET>
</HTML>
NOTE
Probably the first thing to note about the HTML code in Listing 8.2 is
the attribute CODE. This attribute is not optional. It passes the name
of the Java applet file that will be loaded.
The final step is to put all the files in the same directory, load Netscape, and open the file index.html in the browser.
Figure 8.1 shows you the output on your screen.
HTML Tags for Java Applets
Note that not all Internet travelers will have Java-compliant browsers, and for many professional sites it is important to
have a site that will anticipate the capabilities of all the browsers that view the page. With that in mind, another HTML
example with the fictitious applet MyClass.class follows. If the browser that loads this HTML page is not
Java-compliant, the screen will display a comment to the users.
<APPLET CODE=MyClass.class WIDTH=300 HEIGHT=300>
It is time to upgrade your browser to a Java powered one. <P>
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (3 of 55) [4/22/1999 4:07:07 PM]
</APPLET>
In addition to that, an alt attribute can display a statement if the Internet surfer has a Java-compliant browser but for
some other reason cannot view the applet. Technically, the alt attribute will be displayed if that browser understands
the <APPLET> tag but still cannot view the applet. The following example uses alt with the applet MyClass.class:
<APPLET CODE=MyClass.class WIDTH=300 HEIGHT=300>
ALT= "Applet could not be loaded"
It is time to upgrade your browser to a Java powered one. <P>
</APPLET>
Other HTML code sets various display attributes for Java applets. Two attributes you have already used are the width
and the height properties, which are fairly self-explanatory to the browser. By using these two attributes, you can set
the size at which the Java applet will be displayed.
Also in this chapter, you have a chance to get hands-on experience in passing parameters from the HTML page to the
Java applet. Imagine that the applet MyClass.class has a parameter of color. An example of how to pass red to
the parameter of color in the HTML page follows:
<APPLET CODE=MyClass.class WIDTH=300 HEIGHT=300>
<PARAM NAME=Color VALUE="red">
ALT= "Applet could not be loaded"
It is time to upgrade your browser to a Java powered one. <P>
</APPLET>
NOTE
You can pass more than one parameter to an applet as long as the
applet is programmed to accept them.
Another optional, yet very useful, attribute is CODEBASE. When you set the HTML site in Listing 8.2, you see that the
class file and HTML file are in the same directory. In reality, Web sites with numerous files in them can become very
confusing and unorganized when you throw everything into the root. You might want to create a special directory for
your Java applets and use the CODEBASE to reference it. The CODEBASE accepts full and partial URLs.
NOTE
Uniform Resource Locator (URL) is what users specify to their Web
browsers to connect to a particular document or resource. A Web
browser can act as an FTP, Gopher, and Telnet client. Table 8.1
shows a breakdown of the URL, http://home.netscape.com.
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (4 of 55) [4/22/1999 4:07:07 PM]
Table 8.1. Anatomy of a URL.
URL part Explanation
http:// Protocol
home. Machine
netscape. Network
com Domain
The following code is an example of several possible formats for the attribute CODEBASE:
CODEBASE = "http://www.myserver.com/homepage/applets/MyClass.class"
CODEBASE = "http://www.myserver.com/homepage/applets/"
CODEBASE = "/applets/"
CODEBASE = "applet/"
Notice that the preceding examples point to the same relative location
(www.myserver.com/homepage/applets/MyClass.class). Extending the example of the HTML code for
the fictitious class MyClass.class is another example of using CODEBASE:
<APPLET CODE=MyClass.class CODEBASE = "applet/" WIDTH=300 HEIGHT=300>
<PARAM NAME=Color VALUE="red">
ALT= "Applet could not be loaded"
It is time to upgrade your browser to a Java powered one. <P>
</APPLET>
In Netscape, you can also specify how to align the Java applet.
NOTE
The align attribute in the <APPLET> tag follows the same pretense
as the align attribute in the <IMG> tag.
Table 8.2 shows the various states in which align can be and the meanings of those states as interpreted by the browser.
Table 8.2. Various align values.
Attribute Explanation
align = texttop Aligns the applet to the tallest text in the line.
align = top Aligns to the top item in the line.
align = absmiddle Aligns to the middle of the largest item in the line.
align = middle Aligns the middle of the applet to the middle of the
baseline.
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (5 of 55) [4/22/1999 4:07:07 PM]
align = baseline Aligns with the baseline of the line.
align = bottom Same as align = baseline.
align = absbottom Aligns the bottom of the applet to the bottom of the
line.
The last two parameters that you learn briefly are hspace, for horizontal space, and vspace, for vertical space. These
attributes specify the amount of space (in pixels) between the applet and other elements in the HTML page. You will not
use these attributes very often, so they aren't mentioned again in this chapter.
appletviewer
As time goes on, Java will have more proprietary environments in which to develop and test programs and applets, but
this chapter uses the JDK 1.0.1 or the JDK 1.0, which is also compatible. If you do not have the JDK, you can download
it from the following site:
http://java.sun.com/download.html
In Chapter 7 you used the Java interpreter (that is, java.exe) to work with your classes. However, the
HelloWorldC.class applet is not designed to run through the Java interpreter because the method main is not
defined.
NOTE
One major difference between Java applets and programs is that
applets do not need the method main to load the applet on a
Java-compliant browser.
The JDK comes with a program called the appletviewer, which lets you view Java applets. The syntax for using the
appletviewer follows:
appletviewer URL
The URL stands for the file path and name for loading the HTML file. You use this handy tool to test and learn about the
applets in the rest of this chapter. The following is an example of testing the appletviewer with your HTML page
index.html from Listing 8.2:
appletviewer practice/index.html
My file index.html is located in the practice subdirectory of my computer, so what you type might be different if
your file is in a different location. Regardless, your end result should be a window on your screen, as shown in Figure
8.2.
Figure 8.1 : The output of your first Java program.
Now that you have seen an introduction to the interaction between applets and browsers and the tools you will use (that
is, the appletviewer) to test and develop your applications, you will learn about built-in classes. The first built-in
class you learn is the applet object.
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (6 of 55) [4/22/1999 4:07:07 PM]
Applets (java.applet.Applet)
As mentioned in Chapter 5 "Java and the Internet," Java applets are slightly mutated Java programs. Now that you have
enough understanding of Java and enough of an introduction to how Java interacts with the browser, you can appreciate
exactly what mutations need to take place before you can call a Java program an applet. First, all applets are extended
from a class called java.applet.Applet, which comes with the Java language.
NOTE
The root of every built-in Java class (and inherited user-defined Java
class, for that matter) always has a root of java.lang.Object.
When you develop an applet, always start by extending your class from the java.applet.Applet class. Table 8.3
shows you a list of methods available to you from the Applet class.
Table 8.3. Methods of java.applet.Applet.
Method Explanation
destroy() A life cycle method that cleans up any
resources that are still being held by the
applet (the last life cycle method to be
called).
getAudioClip(URL url) Retrieves an audio clip.
getAudioClip(URL, String
name)
An overloaded method that also enables
you to specify the name of the audio clip
you want to retrieve.
getCodeBase() Returns a URL of where the applet
resides.
getDocumentBase() Returns the URL of the HTML page
where the applet is embedded.
getImage(URL url) Retrieves an image at the specified
URL.
getImage(URL url, String
name)
An overloaded method that also enables
you to specify the name of the audio clip
you want to retrieve.
getParameter(String name) Returns a parameter from the HTML
page in the form of a string.
getParameterInfo() Returns an array of strings that enable
you to retrieve more than one parameter
to the applet.
init() A life cycle method that initializes the
object.
isActive() Returns a Boolean response based on the
evaluation of whether the applet is
active.
play(URL, url) Plays an audio clip.
play(URL url, String name) An overloaded method that plays an
audio clip.
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (7 of 55) [4/22/1999 4:07:08 PM]
resize(int width, int
height)
Resizes the applet.
resize(Dimension d) An overloaded method that also resizes
the applet.
showStatus(String msg) Prints a message on the
appletviewer's status bar or a
browser's panel.
start() A life cycle method called to start the
applet (this method is called after
init()).
stop() A life cycle method called to stop the
applet.
You will not be able to work with all of the methods that are listed in Table 8.3, but this table should provide you with a
reference. This section gives you a chance to work with some of the more frequently used methods in Table 8.3.
The Applet Life Cycle Discussion
Probably the easiest way to understand some of the important methods in the applet is to learn them in a little more detail
and then use them in a real-life situation. First, you learn the applet life cycle (that is, the methods that constitute the
applet life cycle). Figure 8.3 provides an overview of the applet life cycle.
Figure 8.2 : Example of using the appletviewer.
As shown in Figure 8.3, init() is the first method called when an applet is loaded. Use this method to get parameters
and to initialize and prepare to officially start the applet. The next method, start(), starts the applet. The major
difference between the init() and start() methods is that you can call the method start() again in the same life
cycle. For example, when a client leaves the HTML page and then returns, the applet won't be discarded completely from
memory, so the applet will simply restart, skipping the init() method and calling the start() method again. If the
applet is completely destroyed, you will have to physically reload the applet again, which will start the life cycle all over
again, initially calling init() again.
The stop() method is called when the user leaves the HTML page that contains the applet or if the applet is physically
unloaded. In either case, the stop() method is always called. Like the relationship between init() and start(),
stop() can be called more than once in one life cycle. The destroy() method is the last method called in the applet
life cycle. This method causes the applet to clean up after itself by freeing any memory, resources, and so on.
When you work with the appletviewer, you can use the menu bar (see Figure 8.4) to perform several operations. The
appletviewer's menu bar has the commands Reload and Restart, which you can use to restart or reload your applet.
Figure 8.3 : Drawing of the applet life cycle.
Packaging
Now that you understand how applets live and die on the Internet continuum, let's briefly digress and discuss some new
objects in HelloWorldC.class that you haven't officially learned. Listing 8.1 presents the idea of packaging. Look
at the following line of code excerpted from Listing 8.1:
import java.awt.Graphics;
A package is a kind of class library in Java. Java organizes its built-in classes into packages based on common
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (8 of 55) [4/22/1999 4:07:08 PM]
relationships between the objects. Your primary focus is to understand how to import packages to your classes (or, more
precisely, how to import built-in classes that come with the JDK), but note that you can also create your own packages. In
the preceding code, you import the object Graphics to your class. As with any type of class porting, the class itself
must be declared public to receive maximum exposure to other classes. Another way you could port the class Graphics
to your class HelloWorldC.java follows:
import java.awt.*;
NOTE
You can create your own packages by using the keyword package.
The asterisk in the preceding code has the same function as in any DOS-based environment, which means that it acts as a
wildcard in Java to include all public classes and packages in this importation. At this point, you might ask yourself why
you imported Graphics to the applet in the first place. The answer: Graphics is the base class for all graphic
contexts in Java; you work with this abstract class in the coming sections. By importing that class, you were able to use
the following method:
public void paint(Graphics g) {
You were able to use this method because it takes the object Graphics as an input object, which is why you need to
import it into the program in Listing 8.1.
NOTE
When you use Java to display all kinds of things in your applet, the
paint method is called. In order for you to paint just about anything
on the screen, you need to override this method in your program.
Think of it in terms of what the main method does for a Java
application.
The Applet Life Cycle Workshop
Now that you have learned the applet object, its life cycles, and an introduction to drawing objects on the screen, let's
compile a program to exemplify some of this material. Create a file called cycle.java and type in Listing 8.3.
NOTE
You are not required to override any of the life cycle methods. In fact,
in Listing 8.1, the HelloWorldC.class applet did not need to use
any of these methods. Later in the chapter, however, you work with
animation, which gives you a chance to see these methods in action.
Listing 8.3. Applet life cycle.
public class cycle extends java.applet.Applet {
public void init() {
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (9 of 55) [4/22/1999 4:07:08 PM]
// Display the this statement at the bottom of the Window
showStatus("The applet is initializing...");
// Pause for a period of time
for (int i = 1; i < 1000000; i++);
}
public void start() {
showStatus("The applet is starting...");
for (int i = 1; i < 1000000; i++);
}
public void stop() {
showStatus("The applet is stopping...");
for(int i = 1; i < 1000000; i++);
}
public void destroy() {
showStatus("The applet is being destroyed...");
for(int i = 1; i < 1000000; i++);
}
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (10 of 55) [4/22/1999 4:07:08 PM]
}
Only the showStatus method might be new to you. Table 8.3 shows that the showStatus method is located in the
object java.applet.Applet, so this method is inherited from the object applet. Its primary function is to display
text at the bottom of the window in the appletviewer or at the status bar on a Java-compliant browser.
In the same directory, create the HTML document cycle.html and type in Listing 8.4.
Listing 8.4. The cycle.html document listing.
<applet code=cycle width=200 height=200>
</applet>
Now run the appletviewer and see what happens. Focus on the status bar at the bottom of the screen, which will
display the stage of the applet in its life cycle. Then go to the menu bar applet, click Restart, and watch the status bar
cycle through, stopping and destroying the applet. After that, click Reload and watch the status bar as the applet cycles
through. Work with the Java applet in Listing 8.3 to better understand the applet life cycle.
Let's take a closer look at the method paint in HelloWorldC.class in Listing 8.1.
public void paint(Graphics g) {
g.drawString("Hello World", 5, 50);
}
As you just learned, the paint method creates a Graphics object g. Therefore, for the duration of the method paint,
you can use any of the methods from Graphics as long as you reference them to g. Looking at the preceding code, you
see that you have done just that. Notice that drawString has three input parameters: The first is the string that actually
will be printed, and the second and third parameters are the x and y coordinates on the applet pane where the text will be
located. Figure 8.5 shows the Applet coordinate system. The origin is located at the top-left corner. In the method
drawString, you specified the origin to be five units to the right of the y-axis origin, and, based on the third variable,
you specified the origin to be 50 units down from the x-axis.
Figure 8.4 : The appletviewer drop-down list of commands.
NOTE
The Java coordinate system is not similar to the Cartesian coordinate
system by default (see Figure 8.4), but you can translate the origin
using the method translate in the java.awt.Graphics.
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (11 of 55) [4/22/1999 4:07:08 PM]
The Logo Version 1.0
For the next several sections you will build and improve on a logo applet. Along the way you learn various methods,
variables, and techniques that you can use in Java. Finally, you finish by building an applet that uses multiple threads.
Passing Parameters to the Applet
The best feature you can give to your HTML page is a logo. In this case, you will build a logo applet as part of the
workshop, so let's discuss how to make the applet responsive to input from the browser by receiving parameters. As you
remember from the previous section, you know how to build an HTML page to send a parameter to an applet. What you
need to understand is how the applet can accept the parameter being passed, and you will do this by building your first
version of the logo applet, which is shown in Listing 8.5.
Listing 8.5. The Logo version 1.0 revision 1.
// Logo version 1.0 rev
import java.awt.Graphics;
public class logo extends java.applet.Applet{
// Declare the object variable array StrLine with 3 values.
String StrLine[] = new String[1];
public void init() {
// Get the value for the
String att = getParameter("Text");
StrLine[0] = (att == null) ? "Please Enter Something
in the parameter Text!" : att;
}
public void paint(Graphics g) {
// Display the variable on the screen
g.drawString(StrLine[0], 5, 50);
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (12 of 55) [4/22/1999 4:07:08 PM]
}
}
As you can see in Listing 8.5, you are overriding one of the life cycle methods init() to accept parameters from the
browser. The actual excerpted code of the overridden method follows:
// Get the value for the
String att = getParameter("Text");
StrLine[0] = (att == null) ? "Please Enter Something
in the parameter Text!" : att;
In the code in Listing 8.5, you see that the format to get a parameter relies on the fact that you are using a temporary
variable (in this case, att) to accept input from the getParameter method that was made available to you from the
class java.applet.Applet (see Table 8.3). The string inside the method getParameter specifies the default
value if att comes back empty. The last line of code in this method exemplifies the use of the ternary operator
(described in Chap-ter 7), and with it, you are able to test whether the att is null (that is, that no value was returned
from the getParameter call). If the evaluation is false, then the default string "Please Enter Something
in the parameter Text!" will be placed on the applet instead. If a value was returned from the call, then the
evaluation will return true, and the value in the temporary variable will be passed on to the applet by passing it to the
variable StrLine[0]. (An array is used because in later versions of this applet, you will accept more than one string.)
Referring to Listing 8.5, you see that the variable StrLine[0] is the drawString method's first input. Now the user
will be able to input a variable in the HTML page and pass it to the applet (which in this case will eventually be passed to
the drawString method and be printed on the applet). The advantage of passing parameters is that you can more easily
customize your applet, and each time you might want to change the string, you will not need to recompile the Java applet.
NOTE
The format shown in Listing 8.5 for passing parameters to an applet is
the standard used in some example applets that come with the JDK
and is the same format that can be used to pass other types of
parameters.
Your next step is to create your HTML page (see Listing 8.6) called logo.html.
Listing 8.6. The logo.html page.
<applet code=logo width=500 height=100>
<param name=Text value="Welcome to my Java powered page!">
</applet>
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (13 of 55) [4/22/1999 4:07:08 PM]
The last step is to run the appletviewer pointing to logo.html. If all goes well, your screen should be similar to
Figure 8.6.
Figure 8.5 : The Applet coordinate system.
Go to the HTML page logo.html in Listing 8.6, and delete the line that passes the parameter to the applet as shown
here:
<param name=Text value="Welcome to my Java powered page!">
Then execute the appletviewer again. Your screen should resemble Figure 8.7, which shows the appletviewer displaying
the default string that was hard coded in your applet.
Figure 8.6 : The logo version 1.0, revision 1.
Fonts, FontMetrics, and Colors
The logo program definitely offers the customizing versatility that enables you to decide what to print in the applet. This
section focuses on how to manipulate what is being printed on the screen by using Java's various font classes. To work
with fonts, you need to understand the first and most basic font object in Java, the java.awt.Font class.
In the paint method, you can change the font attributes so that the Graphics object g will display your text in all
shapes and sizes. Java naturally uses a Font object to handle the display and manipulation of text. For that reason,
Listing 8.7 is a revised version of the Logo applet. Make the changes as shown in Listing 8.7.
Listing 8.7. The Logo version 1.0, revision 2.
// Logo version 1.0 rev
import java.awt.Graphics;
import java.awt.Font;
public class logo extends java.applet.Applet{
// Declare the object variable array StrLine with 3 values.
String StrLine[] = new String[1];
//Declare the Font object called appFont.
Font appFont;
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (14 of 55) [4/22/1999 4:07:08 PM]
public void init() {
// Get the value for the
String att = getParameter("Text");
StrLine[0] = (att == null) ? "Please Enter Something
in the parameter Text!" : att;
//Construct the font with the following attributes:
// Font attrib Size
appFont = new Font("Helvetica", Font.BOLD, 28);
}
public void paint(Graphics g) {
//Set the Font for object g
g.setFont(appFont);
// Display the variable on the screen
g.drawString(StrLine[0], 5, 50);
}
}
Listing 8.7 helps incorporate more methods in the class java.awt.Graphics. First notice that in Listing 8.7 you had
to import the object Font to your class to use in this class. Also notice the following lines of code before the init()
method:
//Declare the Font object called appFont.
Font appFont;
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (15 of 55) [4/22/1999 4:07:08 PM]
This declares that you can use an instance of Font called appFont by any method in the class Logo. The following
shows the constructor of your font appFont:
//Construct the font with the following attributes:
// Font attrib Size
appFont = new Font("Helvetica", Font.BOLD, 28);
In the preceding code, you are able to customize all the various types of fonts, sizes, and styles for your appFont
object. The first input variable is a string with which you can specify the font you want to use. The following list shows
all the fonts currently available for the Font object in Java:
Dialog l
Helvetica l
TimesRoman l
Courier l
Symbol l
The next input variable in the Font constructor is an input variable referenced by a constant (specifically, an integer).
The following list shows all the available attributes for how you want the text in appFont displayed:
BOLD l
ITALIC l
PLAIN l
The third and final input variable is an integer that represents font size. The preceding lists, tables, and explanations can
assist you in finding any font that you want to display in Java applets or programs.
Finally, the last new line of code that you should understand in Listing 8.7 follows:
//Set the Font for object g
g.setFont(appFont);
This piece of code from Listing 8.7 is located in the paint method and uses the built-in method of setFont that was
given to you in Graphics. For the Graphics object g, you have set the font to the object of appFont. Now show
your results on the screen. Compile the updated version of Logo in Listing 8.7. Use the same HTML page to display
Logo that you used for the first version, located in Listing 8.6. The resulting output should look like Figure 8.8.
Figure 8.7 : The Logo applet version 1.0, revision 1, with the default output.
In Figure 8.8, the text in the applet stands out much more than in the original version of the Logo applet. Your next step
when dealing with fonts is to introduce the class java.awt.FontMetrics. You can use this built-in class to give
you information about the size attributes of the current font, and with that information you can better decide how to place
text on varying sizes of windows and applets.
With java.awt.FontMetrics you can measure the current font and place it in the center of the applet. You will use
the object FontMetrics in the next revision of the Logo applet.
The next class you need to learn is java.awt.Color. In Java, you can work with all colors, and as in any other
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (16 of 55) [4/22/1999 4:07:08 PM]
development language, you have several methods strictly related to color manipulation. Because of Java's advanced
object design, these variables and attributes are all housed in one object class called color. You can work with several
constructors in the color object. The object color also follows the RGB format for applying color on the screen.
Finally, the color class comes with a set of built-in variables with which you can specify the major colors.
Although most professional programs require exact colors (that is, you must specify an RGB value), for your program,
you will use the built-in variables that define a set of standard colors. For example:
Color MyColor;
MyColor.red;
This piece of code specifies the standard color red without having to know any RGB values for the instance MyColor.
The next revision to your logo class will be to create a dynamic algorithm to center the string on the screen based on the
applet size (see Listing 8.8).
Listing 8.8. The Logo applet version 1.0, revision 3.
// Logo version 1.0 rev
import java.awt.Graphics;
import java.awt.Font;
import java.awt.FontMetrics;
import java.awt.Rectangle;
import java.awt.Color;
public class logo extends java.applet.Applet{
// Declare the object variable array StrLine with 3 values.
String StrLine[] = new String[1];
//Declare the Font object called appFont.
Font appFont;
public void init() {
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (17 of 55) [4/22/1999 4:07:08 PM]
// Get the value for the
String att = getParameter("Text");
StrLine[0] = (att == null) ? "Please Enter Something
in the parameter Text!" : att;
//Construct the font with the following attributes:
// Font attrib Size
appFont = new Font("Helvetica", Font.BOLD, 28);
}
public void paint(Graphics g) {
//Create an instance of the object FontMetrics called fm.
FontMetrics fm;
// Set the fonts metrics for the object g
fm = g.getFontMetrics(appFont);
// Create an instance of the object Rectangle and give it
// the specs for the applet.
Rectangle r = bounds();
// Change the color of the graphics printed to red.
g.setColor(Color.red);
//Set the Font for object g
g.setFont(appFont);
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (18 of 55) [4/22/1999 4:07:08 PM]
// Display the variable on the screen with a dynamic setting
// to ensure that it is centered on the applet.
g.drawString(StrLine[0], (r.width - fm.stringWidth(StrLine[0])) / 2,
(r.height - fm.getHeight()) /2);
}
}
The code in Listing 8.8 is the next revision for your logo applet. First, notice that you imported a few objects, some that
you have not yet learned. Next, you created an instance of the FontMetrics class, and then used the instance fm to get
the various specs for the font appFont:
// Set the fonts metrics for the object g
fm = g.getFontMetrics(appFont);
As you can see, you used the method getFontMetrics, which is available to you from java.awt.Graphics.
With the preceding line of code, you can now use the methods contained in the class FontMetrics. With these
methods, you can find the width and height of the text, which is crucial to aligning the text properly. The next line of
code that you need to recognize and understand follows:
// Create an instance of the object Rectangle and give it
// the specs for the applet.
Rectangle r = bounds();
The preceding code includes a new object that you have not directly dealt with, the rectangle object. At this point,
you are only using the rectangle object (more specifically, java.awt.Rectangle) to find the boundaries of your
applet. Also you are using a method called bounds(), which comes from java.awt.Component, a very large
object. Calling the bounds() method will retrieve the boundary of the applet in the form of a rectangle object.
With that information, you can use the variables that come with the object rectangle, which are r.width and
r.height (knowing the width and height of the applet is crucial to centering the text). The following is the code from
Listing 8.8 that shows everything that you just learned:
g.drawString(StrLine[0], (r.width - fm.stringWidth(StrLine[0])) / 2,
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (19 of 55) [4/22/1999 4:07:08 PM]
(r.height - fm.getHeight()) /2);
Reviewing the preceding code, you are taking the total width of the applet (r.width) and subtracting that value from
the total width of the text to be printed (fm.stringWidth(StrLine[0]), then dividing the resulting value to center
the text in the applet. The text will remain in the center regardless of what size the text or applet pane becomes. The same
process follows for the height, for which you use the variable r.height and the method fm.getHeight().
The final line of code you'll learn before you compile and run the program follows:
// Change the color of the graphics printed to red.
g.setColor(Color.red);
This code uses the method setColor from java.awt.Graphics. As mentioned earlier, instead of using the RGB
format, you will simply use a built-in color variable that comes with the object java.awt.Color. The following list
gives you all the built-in color variables:
black
blue
cyan
darkGray
gray
green
lightGray
magenta
orange
pink
red
white
yellow
Now that you have learned the new features of Logo revision 3 (see Listing 8.8), compile the applet. You will use the
same HTML page that you used in Listing 8.6 to view this applet (see Figure 8.9).
Figure 8.8 : The Logo applet version 1.0, revision 2.
Now you will unleash the power of all that you've learned about centering text. With the applet loaded as in Figure 8.9,
move your mouse to the border and the mouse pointer will change to a resize mouse icon. Change the size of the applet;
the applet will call the paint method again, and the method will use the new information about the applet's size to fit
the text in the middle of the applet. Figure 8.10 provides an example where the applet size was increased arbitrarily.
Figure 8.9 : The Logo applet version 1.0, revision 3.
NOTE
If you look closely at Figures 8.9 and 8.10, you will notice that the
vertical placement of the text appears to be off center. This is because
the method bounds(), which was called to give the applet the
boundaries, includes the menu bar and title bar as part of the height.
When you measure for the height of the applet, make sure you
include all elements of the page for the height.
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (20 of 55) [4/22/1999 4:07:08 PM]
Animation
Now that you have a well-developed background on how to display text in an applet, it is time to learn about animation
and how you can take advantage of the multithreaded power of Java to build more dynamic applications. This will
require a definition of animation, especially because it is one of the newest and fastest growing industries in the computer
realm.
Before you jump into animating your Logo applet, start by understanding the theoretical aspects of animation. First, it is
reasonable to assume that you do not have to be a film studies major to recognize the concepts behind how animation
works. At a very basic level, animation is nothing more than a series of related frames (that is, pictures) that give the
appearance of smooth, natural motion when shown in a particular order.
Another form of animation is moving a fixed object very slowly across a background while taking a series of pictures at
regular intervals. When the pictures are played back, the object appears to be animated. No doubt these forms of
animation are closely related. You already have an example of the first type of animation in the demo section of the JDK,
which exemplifies how quickly you should project a series of well-timed frames to give the appearance of animation. Not
only that, but you can customize the animation demo by using your own pictures. As a result, you can work with the
demo applet with the JDK. Here, though, you will focus on the second form of animation. Your fixed object will be three
lines of text in your Logo applet.
Animation in the PC Industry
The field of multimedia (animation in particular) is a fairly young technology. In fact, it is probably safe to say that if you
were to go back about four years, the whole industry of PC multimedia would be virtually nonexistent. However, in this
industry, time is definitely warped (more like warp 8), and now not only do you have full-blown multimedia, you also
have completely interactive virtual worlds. One can only wonder about the future with technologies such as VRML,
where Internet surfers will be able to interact with Web-based virtual worlds.
But back to animation. With the advent of multithreaded programming environments such as Java, you are bringing
multimedia to a new level. In the not-too-distant past, PCs were showcased in a single-threaded environment, where
running animation would stop all responsiveness from the computer as well as any other programs running in the
background. Without the power of CPU, animation more than 100Mhz faced CPU time deprivation. There are two
reasons for this: The CPU was simply not powerful enough to handle the computations involved, and the compression
algorithms used on the animation itself were not as sophisticated as they are today (that is, not as efficient). As a result,
the animation locked the system while displaying a piece of animation about one-eighth the size of the screen.
Time and technology have changed from that form of multimedia. Today, not only has animation improved, but
programming languages such as Java have brought animation to the Internet.
NOTE
One element that makes Java such a powerful tool for programming
multimedia is the fact that it is a multithreaded programming
environment.
Animation Workshop
At the technical level, you will be creating an animation of text that will be displayed in an applet on the screen. One of
Java's newer technologies is programming in multiple threads. (Refer to Chapter 5for a high-level discussion on threads
if you need to review.) With Java, the programmer can handle threads by using objects. More precisely, Java uses the
java.lang.Thread object class.
In the Java programming format, you create an instance of the object Thread and implement the built-in interface
runnable, resulting in overriding the method run(). The method run() is where the action code in your program
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (21 of 55) [4/22/1999 4:07:08 PM]
will be placed. Update the Logo applet to incorporate the input, and use the three strings that will be animated (see
Listing 8.9). Because this is a new version of the logo class and not just a revision, you will make a lot of changes to the
original code to focus on only the topics discussed in this section. Create a new file anilogo.java and type in Listing
8.9.
Listing 8.9. The aniLogo applet revision 1.
// aniLogo rev
import java.awt.*;
public class anilogo extends java.applet.Applet implements Runnable {
Rectangle r;
// Declare the object variable array StrLine with 3 values.
String StrLine[] = new String[3];
Font appFont;
// Create a Thread object called myThread
Thread myThread = null;
// declare width array
int width[] = new int[3];
public void init() {
// A for loop to find the three lines of text.
for (int i = 0; i < 3; i++) {
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (22 of 55) [4/22/1999 4:07:08 PM]
String att = getParameter("Text" + i);
StrLine[i] = (att == null) ? ("Please put a parameter
in Text" + i) : att;
}
appFont = new Font("Helvetica", Font.BOLD, 28);
//Set r = to the bounds of the applet
r = bounds();
}
// Override this method from the interface Runnable
public void run() {
//Set the current Threads priority.
Thread.currentThread().setPriority(Thread.NORM_PRIORITY - 1);
// Initialize the locations of the two lines of text to be
// of the screen.
width[1] = 2000;
width[2] = 2000;
repaint();
// Algorithm to send the first line of Text across the screen.
for ( int i = - 50; i < r.width/2; i += 7) {
width[0] = i;
repaint();
// Rest
Chapter 8 -- Java Programming
http://docs.rinet.ru/WPU/ch8.htm (23 of 55) [4/22/1999 4:07:08 PM]
Rest(1);
}