Chapter 2

Designing Intranet apps with Java


de sign \di-zin' \ v: to form a plan for Designing intranet apps involves slightly different methodologies than you may be used to and opens a whole new world of possibilities. This chapter explores the design considerations you make when developing intranet apps with Java. You find many valuable tips that are designed to help you become a successful intranet programmer.

Intranet Programming with Java

Intranet apps are network-aware apps that can retrieve hypertext documents from Web servers, connect to database servers, and examine the contents of file servers. Some intranet apps are considered to be clients, meaning they obtain services from a server. Other intranet apps are considered to be servers, meaning they provide services to clients. Creating intranet apps without Java is difficult, especially because the programmer must write the networking routines for accessing remote files and databases. Fortunately, Java demystifies intranet app programming. Java has built-in features for working with networks in general. Using these features, you can easily create routines to retrieve and display the contents of a file from any computer on the network. Java also has specific features for intranets. Using these features, you can easily create routines that connect to databases, log network activities, and display friendly interfaces. Your early plans for your intranet app should focus specifically on your coding language of choice-Java. In Java, there are two types of programs you can create: applets and apps.

Applets versus apps

When programmers create Java applets, they are generally creating a small app that is designed to be used within the framework of an HTML document. Because applets are designed for use in an HTML document, you need an external viewer to display applets. External viewers you use to display applets include Web browsers or applet viewers.

Note that the size of an applet is relative to its purpose. The real key to applets is they are designed to be used with an external viewer.

When programmers create Java apps, they are generally creating an app that is designed for standalone use. The app does not need to be run within an external viewer, which means you can execute a Java app directly using the Java interpreter. If you follow Java-related discussion groups or have read other Java tutorials, you probably have seen references to Java apps. An app is a slang term for a standalone app. While Java apps usually run on a local machine, Java applets usually run on a remote machine. Some Java programs can run both as standalone apps and as applets requiring an external viewer. This is a function of the program's design. Generally, programs that can run as both an app and an applet include a main method required for apps and the init and run methods used in applets.

Throughout this tutorial, the phrase intranet app is often used to refer to both applets and apps that are designed to be used on an intranet.

Conceptualization and Design of Intranet apps

Before you create an intranet app, take the time to carefully conceptualize and design the app. The first step is to decide whether you want to create the intranet app as a Java app or as an applet. Three questions that can help you make this decision are

As you try to answer these questions, look around your workplace and try to determine how best the intranet and this particular app can serve your organization. To help you better understand when to use apps and when to use applets, the next sections examine applet and app creation in depth.

Creating Applets

The most common type of Java program is the applet. Applets are widely used on the World Wide Web. Before you automatically create an intranet app as a Java applet, carefully consider the questions posed in the previous section.

The Benefits and Drawbacks of Applets

When you create an applet, you want the program to be used with an external viewer. The two most common external viewers used with applets are Java-capable browsers and the JDK applet viewer. The benefit of using an external viewer is that the viewer handles starting and exiting the applet. This allows you to create applets without menu bars or dialog boxes. Applets without menu bars and dialog boxes generally have a very simple and friendly user interface. While applets can have simpler interfaces and sometimes require less code, applets inherit all the overhead of the viewer in which they are running. This means that even if your applet needs only 50KB of memory, you are still constrained by the memory needs of the viewer, which may be an additional 2, 4, or 8MB of memory. On a heavily loaded workstation that is already running multiple apps, such as a word processor or spreadsheet, the additional memory needs of the viewer can seriously affect performance. Sometimes the overhead involved with applets is not the major issue, especially on intranets where security is a big concern. Using an external viewer, you gain an additional layer of security. This is because the security controls for applets are usually provided by the applet security manager, which can recognize whether applets are running on a local machine or a remote machine. If an applet exists on the local machine and is in a directory defined in the CLASSPATH environment variable, the applet is loaded by the file system loader. Applets loaded by the file system loader are allowed to read and write files and can access native code.

Code used with Java programs and written in another coding language, such as C or C++, is called native code. Any program that can invoke native code on a computer can gain direct access to protected system areas, which is a major security concern.

If an applet does not exist on the local machine or is not in the right directory, the applet is loaded by the applet class loader and is subject to the restrictions of the applet security manager. These applets are generally restricted from gaining access to the local file system and therefore cannot manipulate files or directories on the local machine in any way. They cannot read or write files. They cannot start another program on the local machine. They cannot make directories. They cannot check file size, modification date, or type.

Browsers for Your Applets

Browsers are the most popular type of external viewer for applets. Think of browsers as your windows to the Web; change your browser and you get a whole new view of what is out there. Browsers are available for virtually any computer operating system from DOS to Mac to OS/2. When you set up your intranet, you want to choose a Java-capable browser. The number of Java-capable browsers is steadily increasing. Currently, the most popular browsers that support Java include

As you read about Java-capable browsers, keep in mind that some versions of a browser may not support Java. In order to use Java on a particular operating system, there must be a Java runtime environment. Currently, there are Java runtime environments for UNIX Solaris, AIX, Macintosh, OS/2, and Windows 95/NT. There are also initiatives to develop Java runtime environments for Windows 3.1, Linux, and Amiga.


Not only is HotJava the first browser to support Java, it is also the first browser written entirely in Java. HotJava is being developed by JavaSoft. To say that JavaSoft is developing HotJava slowly is an understatement. Until April 1996, the alpha version of HotJava was the only version available. Unfortunately, HotJava alpha cannot run applets written in beta or later versions of Java. The current version of HotJava is a beta version. Fortunately, this version supports JDK 1.0 and later. Versions of HotJava are available for Windows 95/NT, Sun Solaris, and soon Macintosh. Because HotJava is the first Java-capable browser, it is a popular browser. This popularity leads to disappointment for some new users, especially because HotJava is not feature-rich like some of the other Java-capable browsers. You find that HotJava has a rather plain interface and limited extras. Still, HotJava is currently in the testing stages and may yet evolve into a full-featured browser. JavaSoft's HotJava page is shown in Figure 2.1. You can download an evaluation version of HotJava at the following URL: Screenshot : The HotJava page at JavaSoft.
Unique Solutions with HotJava
Although HotJava is not the most advanced Java-capable browser today, there are many great reasons to choose HotJava as an intranet publishing solution, especially if you need to handle unique content or protocols. Traditional browsers are limited in the type of content they can handle and the protocols they can use. When you want to display documents in a unique or proprietary format such as rich text format (RTF), your traditional browser probably will not be able to handle the format directly and will depend on an add-on module or helper app to display the document. If an add-on for the browser is not available, you are out of luck.
With HotJava, you can easily create your own content handler to display the nonstandard format. Creating content handlers is so easy that many developers needing unique publishing solutions turn to HotJava.
HotJava also allows you to create protocol handlers. Traditional browsers support popular protocols, such as HTTP and FTP. If a protocol is not supported directly in the browser, there is no practical way to extend the browser to support the protocol. For example, most browsers do not directly support the Telnet protocol to access remote hosts. If you want to use Telnet, you start a separate app that is designed for remote host access with Telnet.
Using HotJava, you can create a protocol handler that allows HotJava to remotely access hosts using Telnet. Direct support for a protocol eliminates error messages and confusion when users try to access nonstandard protocols linked in your published documents.

Internet Explorer

The Internet Explorer is a feature-rich browser from Microsoft. As one of the most powerful browsers currently available, Internet Explorer took the Web by storm when it was first released in 1995 and quickly moved to the number two browser on the market. You can obtain free versions of Internet Explorer for Macintosh, Windows 95, and Windows NT. The popularity of Internet Explorer stems largely from its support for existing HTML standards and unique extensions to HTML. Internet Explorer supports HTML 3.2; all Netscape 1.0 and 2.0 extensions; and powerful multimedia extensions including document soundtracks, scrolling marquees, and inline video. Versions 3.0 and later also feature support for Java and ActiveX. As of July 1996, Internet Explorer was also the only browser to fully support the expanded HTML table model specification. The Internet Explorer home page at Microsoft is shown in Figure 2.2. From the IE home page, you can access the most current version of the browser and obtain upgrade modules like Internet Explorer VR. You can access the IE home page at: Screenshot : Web browsing with the Internet Explorer.

Netscape Navigator

Although the Internet Explorer is vying with the Netscape Navigator for its coveted position as king of the browsers, the Navigator remains the hands-on favorite. The Netscape Navigator is available for Macintosh, Windows, Windows 95/NT, and UNIX. Netscape Navigator supports Java and has many features that make it a great choice for your intranet. These features include support for HTML 3.2, plug-ins, and JavaScript. With HTML 3.2, you get support for the advanced features of HTML like tables and client-side image maps. Plug-ins allow you to add modules for inline video, sound, and multimedia. Using JavaScript, you can create client-side scripts for your HTML documents. Netscape has also introduced unique extensions to HTML with every major release of the Navigator. Currently, Netscape and Microsoft are playing a game of one-up-manship. Netscape Navigator is the first browser to support HTML tables and is the model for the table standard adopted in HTML 3.2. By supporting the expanded HTML table model specification, Internet Explorer went one better in version 3.0. Netscape Navigator 2.0 introduced frames, which are mini-windows within documents. Internet Explorer 3.0 went one better and introduced frames without borders and frames that can float on the page. Netscape added new extensions to the beta release of Navigator 3.0 that include support for frames without borders. You can download free versions of the Netscape Navigator at the Netscape Web site, which is shown in Figure 2.3. The URL to this site is Screenshot : Web browsing with the Netscape Navigator.

Oracle PowerBrowser

Although PowerBrowser is a fairly new browser on the market, it has all the features you expect in a browser created by Oracle. Oracle is known for its powerful databases and not surprisingly, PowerBrowser includes a local database called Blaze. With Blaze, you can store and manage large amounts of data efficiently. Because Blaze and PowerBrowser can communicate, you can easily create HTML pages that access the Blaze database. Other features of the browser include support for HTML 3.2 and Java. Currently, PowerBrowser is available for Windows 3.1 and Windows 95/NT. You can obtain an evaluation version of the browser at the site shown in Figure 2.4. You access this site by pointing your browser to Screenshot : Learning about the Oracle PowerBrowser.

Placing Applets in HTML Documents

When you create an applet, you need to create an HTML document to display the applet. This section provides an introduction to HTML and the specific extensions in HTML for Java.

Introduction to HTML

The Hypertext Markup Language is based on a system of markup codes called tags. Each tag provides specific instructions to your browser. These instructions tell the browser how to display the contents of the document. Most tags are used in pairs. A tag called the begin tag marks the start of an element such as <P> that marks the beginning of a paragraph. A tag called the end tag marks the end of an element such as </P> that marks the end of a paragraph. The difference between a begin tag and an end tag is the forward slash before the element name. Because HTML is not case-sensitive, <p> and <P> mean the same thing. Some characters in HTML are reserved, like the open and close brackets <>, which denote an HTML element. To display reserved characters in your HTML page, you tell the browser this is a special character and not a reserved character. To do this, you use a special element name that begins with an ampersand and ends with a semicolon such as &lt; for the less than symbol <. When browsers see a special character, they display the corresponding symbol if possible. In general, all HTML documents follow a basic structure that includes:

The document identifier identifies the type of document you are creating. Because you are creating an HTML document, your document begins with the tag <HTML> and ends with the tag </HTML>. The begin tag <HTML> tells the browser the document is an HTML-formatted document and marks the beginning of the document. The end tag </HTML> marks the end of the document and is the last item in any HTML document. A header element immediately follows the begin document tag <HTML>. Headers are used to specify key aspects of a document such as its title. The beginning of the header is specified with the begin header tag <HEAD> and the end of the header is specified with the end tag </HEAD>. For now, the only element you may want to use in the header is the TITLE element, which is used to specify a title for your document. The body element follows the header element and contains the text and objects you want to display in the reader's browser. Like the header, the body has a begin tag <BODY> and an end tag </BODY>. You can add attributes to most markup tags. Attributes are used to assign default formats for text or graphics associated with the tag. An example of a tag with an attribute is: <P ALIGN=CENTER>. This ALIGN attribute set to the value of CENTER tells the reader's browser to center a text or graphic element on the page. Using the markup tags discussed in this section, you can create the framework for an HTML document as follows:


<TITLE> A Cool Java Applet </TITLE>


Insert the actual body elements here.


The Java Extensions to HTML

The latest HTML specification-3.2-includes two elements that are specifically designed for use with Java applets. These elements are APPLET and PARAM. Like most HTML elements, these new elements have many attributes that you can use when you insert an applet in a page. Ideally, you use only the attributes that you need for a particular applet.

Using the APPLET Element

The APPLET element is used to name the applet you are inserting into the HTML document and to define its characteristics. Like most HTML tags, the APPLET element has a begin tag <APPLET> and an end tag </APPLET>.

If you are familiar with HTML, you might be wondering why there is a begin and end tag for the APPLET element. After all, all the necessary instructions are in the begin applet tag <APPLET>, which makes the end tag </APPLET> seem unnecessary. Between the begin and end APPLET tags, you can define an area of the document that is displayed by browsers that are not Java-capable.
Here is a sample page that has an area for browsers that are not Java-capable:

<TITLE> Using Java </TITLE>


<APPLET CODE="AppletFun.class" WIDTH=300 HEIGHT=300>
<IMG src="champions.gif">
This page contains a Java applet.
You see this message because your browser does not support Java.
<P>You should get a Java-capable browser.</P>


The required attributes for the APPLET element are: CODE, WIDTH, and HEIGHT. The CODE attribute is used to name the applet's primary class file-the class file containing the Applet subclass references. The WIDTH and HEIGHT attributes define the initial width and height of the applet's display area in pixels.

Testing the display of the applet in your document at various display resolutions is extremely important. The most popular display resolution on Windows-based pcs is 640¥480 with an increasing number of users moving to larger displays such as 800¥600 or 1024¥768. On a Macintosh, screen size determines the pixel size of the screen. Currently, many Mac users have a 13" screen, which offers a display resolution close to 640¥480. On UNIX systems and primarily Oracle SPARCs, the display resolution is often set at 1154¥864.

Here is a sample HTML document using the required attributes:


<TITLE> Java to the Max </TITLE>


<APPLET CODE="CoolApplet.class" WIDTH=300 HEIGHT=300>


In the example, the HTML document and the applet CoolApplet must be in the same directory. If you plan to place applets in a different directory, you must use the optional CODEBASE attribute. The CODEBASE attribute lets you indicate the URL path to the applet. In this example, the directory called java/apps/ contains the class files for the applet:


<TITLE> Java to the Max </TITLE>


<APPLET CODE="CoolApplet.class" CODEBASE="java/apps/" WIDTH=300 HEIGHT=300>

URL paths are either relative or absolute. In the example, the URL path is relative, meaning the applet is located relative to the current directory. To specify an absolute path, you use a full hypertext reference, such as:

Additional optional attributes for the APPLET element include: ALIGN, HSPACE, VSPACE, NAME, and ALT. You can use these attributes to enhance the display of the applet and the layout of your document. The ALIGN attribute is used to specify the alignment of the applet within the document. The acceptable values are shown in Table 2.1.

Table 2.1. The alignment attribute values and their meaning.
Attribute Value Meaning
ALIGN=ABSBOTTOM Align the bottom of the applet with the lowest item on its line.
ALIGN=ABSMIDDLE Align applet with the middle of the largest item on its line.
ALIGN=BASELINE Align the bottom of the applet with the baseline of the text associated with the applet.
ALIGN=CENTER Align applet in the center of the document.
ALIGN=LEFT Align applet with the left side of the document.
ALIGN=MIDDLE Align applet with the middle of the baseline of the text associated with the applet.
ALIGN=RIGHT Align applet with the right side of the document.
ALIGN=TEXTTOP Align applet with the top of the tallest text on its line.
ALIGN=TOP Align applet with the topmost item on its line.

The HSPACE and VSPACE attributes are used to specify the amount of white space around the applet. HSPACE defines the horizontal space on either side of the applet and VSPACE defines the vertical space above and below the applet. The value assigned to these attributes is defined in pixels. You use HSPACE=10 and VSPACE=10 in the <APPLET> tag to have ten pixels of space around the applet. The ALT attribute defines alternative text to display when the browser recognizes the <APPLET> tag but is not capable of running applets. Currently, this attribute is not used widely with applets. The final optional attribute for the APPLET element is the NAME attribute. Using the NAME attribute, you can assign a designator for the applet that allows it to be targeted by other applets on the page. When applets can target each other, they can interact, which allows you to update applets on the page based on what the user is doing with another applet. The value for the NAME attribute is a unique designator, such as NAME=APPLET1 or NAME=APPLET2.

Using the PARAM Element

Using the PARAM element, you can pass general purpose parameters to an applet. The PARAM element is one of the few elements in HTML that uses only a begin tag. Because each <PARAM> tag is used to set a specific parameter to specific value, you can use multiple <PARAM> tags in your document. Place these tags between the begin and end <APPLET> tags. This is the only element you can insert between the APPLET tags that Java-capable Web browsers takes advantage of when they run an associated applet. Applets access the parameters set in the <PARAM> tag using the getParameter() method. The <PARAM> tag has two required attributes: NAME and VALUE. The NAME attribute assigns the name that the getParameter() method in your applet searches for. The VALUE attribute is used to set a specific value for the parameter. Here is an example document using the PARAM element that sets a parameter called TEXT:


<TITLE> Java to the Max With Parameters </TITLE>


<APPLET CODE="MessageBoard" WIDTH=600 HEIGHT=200>
<PARAM NAME=TEXT VALUE= "Thanks for visiting!">


In your Java applet, you read the value set for the TEXT parameter as follows:

Msg = getParameter ("TEXT");

Creating apps

Unfortunately, Java programmers don't create apps as often as they create applets. One reason for this is that many programmers don't understand when to use apps.

More Options with apps

Although apps and applets are similar, there are more options available when working with an app. Primarily this is because apps are standalone programs that require you to create the user interface. For example, the most common method for exiting an app is a Quit or Exit option on a pull-down menu. When you create an app, you need to build a menu bar, add menus to the menu bar, and options for the menus. One of the options on your menu system is the Quit or Exit option. While having to create your own interface outside the context of a browser may seem like a drawback, you actually have more options available to you when you build a unique interface for your app.

apps Have a Different Structure

Generally, apps are run by the Java interpreter on a local machine, which eliminates the need to create an HTML page to view your Java program. Additionally, because you do not need an external viewer to run apps, apps can provide users with better performance. Better performance translates to improved response times and, often, increased productivity. All apps require a static main() method. Unlike C++, Java's main() method must be part of the public class that defines an app. When you run an app, the Java interpreter executes the main() method and in turn, the main() method creates instances of objects and lets the objects control the execution of the program.

apps Have Different Security Considerations

Because apps are run using the Java interpreter, they are not subject to the security constraints of the applet security manager. This gives apps a substantial advantage over applets and means apps have unrestricted access to the client's file system. Therefore, unless you specifically set up restrictions otherwise, standalone apps can

Although being able to access the local file system provides an advantage non-local applets do not have, a lack of security constraints can cause problems. Therefore, if security is a major issue with your program, you want to carefully consider whether you need a strict security model. Standalone apps can also run native code. This means that if you have source code
in other coding languages that you want to use with your intranet apps, you
probably want to create an app. Keep in mind that native code, such as C or C++, is compiled for a specific operating system. Thus if you use native code, you lose the platform independence and widespread portability you gain by coding with Java.

Most organizations that develop software have large libraries of native code. Before you automatically decide that using native code is a done deal, study the current Java APIs. You may be pleasantly surprised when you find that functions you've coded in C, C++, SmallTalk, or some other coding language are already available in Java.

Running apps and Applets

Most intranets have many different types of servers and follow a loose client-server model. In an ideal client-server environment, clients maintain the app front end, the user interface, and the binary executable for the client interface. Servers maintain the app back end, the server software, and data. Using a strict client-server model reduces traffic on the intranet and balances the demand for resources around the network. In the real world, many network apps use a file server model where the server has both the binary executable for the client interface and the necessary data files for the app. Because clients execute apps by way of the server and retrieve data from the server, you often have dramatically more network traffic and heavy loads on your file servers. As you design your intranet apps, keep the client server and the file server models in mind. Because Java apps are invoked by the Java interpreter running on a local machine and can retrieve files from remote servers, your Java apps generally follow a client-server model. Java applets, on the other hand, usually run on a remote machine and because of this generally follow a file server model. Although it seems you should immediately choose the client-server model over the file server model, there are benefits to following a file server model. The two key benefits of the file server model are related to storage and maintenance. With the client-server model, all workstations generally have a copy of the intranet app on their file system which requires space on the workstation's hard drive. Since there are copies of the app on all your workstations, you must copy new versions of the app whenever you make versions, which may create a maintenance nightmare. With the file server model, there is usually only one copy of the app and it is on the file server, which makes updating the app very easy.


After reading this chapter, you should have a clear understanding of the design issues related to Java programming. The fundamental decision you must make is whether to create your intranet app as an applet or as an app. As you've seen, there are many reasons why you may choose to design an applet rather than an app and vice versa. Before you create your intranet apps, consider the underlying issues surrounding applet and app design, including security, file access, the ability to use native code, and network design.

Java ScreenshotJava ScreenshotJava ScreenshotJava Screenshot