Overview

Since the first edition of this book in July 1998, the world of Java has continued to gain significant ground. By now, everyone is aware of the industry's commitment to Java, of IBM's commitment to Java, and especially of the AS/400's (now known as the iSeries') commitment to Java. Way back in 1998, the options for AS/400 Java programmers were exactly two: write Java applications that run on the AS/400 or on a client connected to an AS/400, or write Java applets that run in a Web browser connected to an AS/400. Now, in addition to the expanded capabilities of both of these options, there are servlets, JavaServer Pages, and Enterprise JavaBeans (EJBs). Java is now also a full-fledged option for writing Domino applications. Further, XML, with its Java affinity, has emerged as the new standard for business-to-business communication and is a favorite way to persist information needed by tools. A rapidly emerging new standard for reusable components, known as Web Services, also have tight affinity with Java.

Most vendors writing tools have switched to Java. Most package vendors have adopted Java or have a plan to phase it in. Java presentations at professional and technical conferences continue to fill rooms. Look at the agenda for the North American COMMON conference (www.common.org), and you'll see that Java and Java-related technologies permeate it.

So, while Java is still maturing and expanding rapidly, it is now an entrenched part of the iSeries and AS/400 application development scene. At the same time, IBM has proven it is not backing away from RPG or COBOL, and has continued to deliver significant new functionality in each release of both. Further, as of this writing, IBM has just released its new application development package, WebSphere Development Studio for iSeries (WDS), offering modern tooling for everything from RPG to Java to Web user interfaces. That tooling includes WebFacing, an exciting new option for quickly and cost-effectively converting 5250 applications into Web-enabled applications. WebFacing converts display-file DDS source into JavaServer Page source and JavaBeans (simple beans, not EJBs). The WebFacing runtime intercepts the display file input/output operations from an application and diverts them to the WebFacing runtime servlet, offering a Web refacing with no application code change. This awesome new capability is possible due to the power of Java.

The first release of WDS includes the "classic" version of WebSphere Studio for Web user interfaces authored in HTML, JavaServer Pages, and JavaScript, and includes the classic version of VisualAge for Java for applications, applets, servlets, and beans. Also included is the classic version of CODE for RPG, COBOL, C, C++, CL, and lightweight Java development, and even VisualAge RPG for writing Java applications authored in RPG IV. Exciting as this tooling package is on first release, future releases promise to be even more exciting, as all the tools converge around Eclipse, IBM's new Integrated Development Environment that is the basis of the next generation of all IBM tooling. Eclipse is a pluggable and extendable IDE, fully open and indeed open source. What is Eclipse written in, and what is used to extend it? Java, of course. Java is now the cornerstone programming language for IBM.

Evolving the languages and the tools are important enough in their own right, but IBM has also shown it clearly sees a world with both Java and RPG/COBOL by continually enhancing both RPG and COBOL to increase your ability to mix Java and RPG/COBOL code in the same application. V5R1 and later releases of RPG and COBOL bear out this commitment. While Java is clearly the glue of e-Business, IBM will ensure that both RPG and COBOL have roles in this new and exceedingly important picture, for those who prefer to use a business language for their business logic.

With all this in mind, this book will teach you Java so you can include it as another option in your programming toolbox. If you have already read the first edition, welcome back. You will find many additional topics and increased coverage of the core topics. If this is your first read, congratulations on taking the first step on the road to Java.

What is Java?

Java is a programming language. So are RPG and CL. You learned them, and you can learn Java. The reason Java seems like more than just a programming language is the vast number of places it can be used. Vertically, it can be used to program the smallest embedded chips and personal devices all the way up to the largest scalable, transaction-based, distributed enterprise applications. Horizontally, it can run on any operating system and almost any device. Java can be the answer for your user interface, and it can be the language of your next batch language. It can do e-Business on the Internet, and it can do back-office payroll.

However, with all of this, you must distinguish between the core Java language, which is stable, mature, and relatively small, and the Java technologies built on top of that language. These technologies are just specialized Java code written by the industry to solve specific tasks, such as programming chips, Internet Web servers, or large-scale mission-critical applications that support distribution and transactions.

The trick to learning Java is to start with the core language, including the syntax and the core Java-supplied functions. With these under your belt, you can move on to additional Java technologies with relative ease, if and when you need them.

From this book, you will learn the core Java language syntax by having it compared every step of the way to RPG. You will also learn the core Java-supplied functions that you will need to succeed with Java, again compared every step of the way to RPG. With the proper analogies, and the proper definition of terms in iSeries-speak, you'll find that Java is not mysterious and absolutely within your capabilities to learn, use, and master! Indeed, thousands of RPG programmers before you have done exactly that.

This book is not small, but neither are your RPG and DDS manuals. Do not despair, as the size is simply because we have included many examples in both RPG and Java to give you a complete introduction to as much Java as you will need to be productive. This might not be the last book you read on Java, but it should make you immediately productive with Java.

What about That OO Thing?

Java is an object-oriented language. It is inconceivable that a new language today would not be object-oriented; the benefits in productivity and quality are too great to ignore. These gains come from the capacity to reuse code and perform better problem domain-modeling. When people complain about Java's learning curve, they always refer to the OO side of things. This is typically from people who haven't learned Java, or want to promote an alternative. Don't be fooled. Yes, thinking "OO" is different than thinking procedurally as you do in RPG. But it comes quickly, and not by reading a book, frankly. That helps, to be sure, but it really starts coming home only by writing code. With a little experience, you can pick up an OO book or course, and it will all fall into place. Once it does fall into place, you will wonder how you lived without it.

Our approach to OO in this book is not to hit you over the head with it. Our primary goal is to teach you the language and the major functionality supplied with the language. As we do that, we'll be showing you many examples. You will slowly get the hang of objects simply by seeing them, and, if you follow along, by coding them. They really are not that hard. So, don't think OO means "uh oh!" It is just a tool that ultimately will make your life better. (Well, your programming life, anyway.)

Why the Hype?

If Java is just a programming language, then why all the fuss? There are a number of reasons:

• The name. Java is a cool name! Programmers like that.
• The Internet. Java has much affinity with the Internet. CEOs like that.
• Portability. Java makes it possible to write completely portable code. CIOs like that.
• Accessibility. Java is free. CFOs like that.

The following sections examine these reasons a little further. We hope you like that.

The name

Java was originally designed by engineers from Sun Microsystems. Their intent was to create a small-scale, interpreted language for programming small consumer devices. Reportedly known as "Oak" in its early days, it was originally an embedded language that quickly found a new use for Internet-related programming. It had all the attributes a programming language for the Internet could want: it was small, simple, easy to code, platform independent, and provided support for dynamic loading of code on demand. Thus, it was renamed and made publicly available as a programming language for the Internet in 1995.

Java's big boost, however, came in early 1996, when Netscape Communications stepped up to support it as a programming language that could be processed by its Web browser. Suddenly, thousands of programmers and Web site owners wanted to learn and use Java.

What about the name? Legend has it that it came from the coffee the engineers drank in vast quantities while working so hard on the project. We guess "Donut" was ruled out.

The Internet

The original reason for Java's popularity, then, was the Internet. Specifically, Java could be used to program Web pages displayed by Web browsers such as Netscape's Navigator or Microsoft's Internet Explorer. Web browsers display text and graphics through HTML (Hypertext Markup Language), a tag-based language similar to UIM (User Interface Manager, the AS/400 source language for writing online help).

Java adds the ability to embed Java applets inside HTML pages. Applets are small applications that only run inside Web browsers, using the screen real estate of the browser window. Since they have the full power of a modern programming language behind them, they can provide fully interactive, animated, live-data Web pages, which is beyond what HTML could originally offer. Java can also be used to author servlets, which are server-side programs for serving up Web pages dynamically and on demand.

Java also supports easy Internet communications programming, using either HTTP or TCP/IP communications protocols. Indeed, it is possible to write a Web browser entirely in Java that performs the basic tasks of finding, retrieving, and displaying HTML files. In fact, Sun has done just that with its HotJava Web browser. While this is easy enough, you have no need for communications programming as an AS/400 programmer because IBM supplies the AS/400 Toolbox for Java, a rich collection of pre-written code that makes remotely accessing AS/400 programs and data easy.

Portability

Java approaches more closely than any preceding language that elusive goal of "write once, run anywhere." It is possible to write completely portable applications in Java without too much sacrifice or pain. Here is why this is possible:

• Java (like BASIC and Smalltalk) is interpreted rather than compiled.
• Java's interpreter is everywhere, in operating systems, Web browsers, chips, and more.
• The Java is rich in functionality, so there is little need for operating system APIs.

Accessibility

Sun Microsystems makes Java available for free over the Internet for Windows and Solaris. IBM and others take that and make it available for their operating systems, Web browsers, computer chips, personal devices, toaster ovens, and so on. In most cases today, Java is actually made part of the operating system, so it is even more accessible.

Visit any Web-search site, do a search for the word Java, and you'll find thousands of free tutorials, newsgroups and other resources at your disposal. Of course, you can pay for onsite education and robust development tools, but one of Java's most alluring features is that you don't have to make that investment. Even your local community college will almost certainly offer a Java programming course. (Finally, the Pascal courses are being retired!)

The Roles of Java

Java can play a role in at least three important places in your application:

• The client. This can be a traditional GUI application, a Web browser applet, or a Java servlet-created Web page. The user interface will run on any client operating system.
• The server. This can be a small part of an existing application, an entire traditional business-logic application, or a new Enterprise JavaBean application.
• The glue. Whatever the decisions for the client and the server, Java is a good option for tying them together. With new Web Services coming online, Java is also the glue between any two pieces of business logic running on any two machines in any two companies.

The House of Java

Java comes in its purest form as the Java Development Kit, or JDK. This kit contains a number of fundamentals, including these:

• A Java compiler that compiles Java source code into efficiently interpreted bytecode (as opposed to directly executable machine code). This is the javac command.
• A Java interpreter that interprets or runs Java bytecode. This is the java command.
• A set of Java class libraries (packages), similar to reusable ILE service programs, for often-needed programming tasks.

These basic elements, together with their documentation, define the Java language. The documentation is in HTML and is shipped compressed into a file that is a separate download from the JDK, so be sure to get it too. While packaged separately, the documentation is still considered part of the JDK. The JDK also includes a number of other useful command-line tools, shown in Table 1.1.

You can find Sun's JDK for Windows and Solaris at www.java.sun.com/products. However, be aware that the official name has changed to Java 2 SDK, Standard Edition, V1.x. So you have to follow the links for Java 2 SDK at Sun's Web site. Further, Java comes with the operating system on the iSeries, but is known there as the Java Application Development Kit (ADK). However, this book uses the simpler term JDK.

The JDK does not include an editor, an integrated development environment, or a visual design tool, and it provides only the most rudimentary of debuggers. Nonetheless, with a decent editor (such as CODE/400's) you have all you need for basic Java development. Figure 1.1 illustrates the pieces of the JDK.

Figure 1.1: The Java Development Kit (JDK)

Most programmers, however, will opt for one of the many full-scale Java development tools that are already available, such as IBM's VisualAge for Java, Inprise's JBuilder, or Symantec's Visual Cafe. These start with the basic JDK, and then add IDEs (integrated development environments), class hierarchy browsers, debuggers, visual design tools, wizards, and many more items to make the development task easier. Multiple-developer shops will also look for tools that offer built-in team support and versioning control, such as VisualAge for Java offers. (Note that the name "VisualAge for Java" can mean either the classic version of this tool, or its new Eclipse-based generation known as "Java Tools" inside IBM Eclipse-based products such as WebSphere Studio Site Developer and WebSphere Studio Application Developer.)

The JDK originates with Sun Microsystems. Based on tremendous programmer feedback, the company adds enhancements and features to the language, and regularly releases a new version of the JDK. Other industry partners betting heavily on Java work with Sun to define and even implement many specialized pieces.

In February 1997, Sun released version 1.1 of the JDK. In December 1998, it released 1.2, and in February 2000, it released 1.3. Release 1.4 is scheduled for the end of 2001, as of this writing. As of version 1.2, the official generic branding became Java 2 Platform, Standard Edition. Sun's own JDK for Solaris and Sun is named Java 2 SDK, Standard Edition. There is also an Enterprise Edition, which is a superset of the Standard Edition and includes server-side functionality such as servlets, JavaServer Pages, and Enterprise JavaBeans. The JDK is maturing and improving very fast, but hopefully its name has stabilized!

Because this book examines the basics of Java, all its samples are written using Sun's JDK on Windows. We happened to use CODE/400 for entering the source, but you can use whatever tool you have handy. The nice thing about using CODE/400 is that you can use the same editor and debugger for both Java and RPG.

If you decide to follow along with this book's samples, you should get the JDK for Windows from www.java.sun.com/products (follow the link for Java 2 SDK). Also be sure to get the documentation, which is a separate download. When you install the JDK, be sure to follow the instructions in the readme file, especially those related to updating your PATH and CLASSPATH statements on Windows. Other operating-system vendors license the JDK code from Sun and port it as-is to their operating systems. The IBM Hursley laboratory, for example, licenses and ports the JDK to the IBM operating systems AIX, OS/2, OS/400, and MVS, as well as to Linux. For OS/400, the IBM Rochester lab leverages that ported base, and then integrates it deeply into the operating system for improved performance. Various Web browser manufacturers also license the JDK code in order to run Java applets embedded in Web pages.

As part of the Java license, the licensee agrees to stay current with the JDK, and must port a new release within about six months of its release by Sun. This ensures a reasonably current base across all the operating systems and Web browsers, as well as user program portability. The JDK now comes with most, if not all, major operating systems.

It has come with OS/400 since Version 4, Release 2 (V4R2) and has been significantly improved ever since. (For more details, see www.ibm.com/java and www.ibm.com/iSeries/java.)

Java Bytecode

Java achieves its portability because of its bytecode architecture. As illustrated in Figure 1.2, the Java source code you enter is compiled into bytecode using the JDK-sup- plied javac command-line compiler. This compiler is really only the front half of a traditional compiler, in that an executable program is not produced as a result. Rather, it stops at what is referred to as the intermediate code in traditional compilers. This is a more efficient, compact version of the source, which is independent of any particular operating system.

Figure 1.2: Compiling Java source code to Java bytecode

The Java source code is contained in a file that ends with the extension .java ("dot java"), while the Java bytecode is contained in a file that ends with the extension .class ("dot class"). You can copy a bytecode .class file to any operating system or Web browser that contains the Java interpreter, and run it there without change. The hard work is performed by the interpreter itself—it has to be ported. And it is the operating system and Web browser vendors that do this hard work for you.

To run a Java application, you invoke the java command and pass it the name of your bytecode .class file as a parameter, as shown in Figure 1.3. For applets, you need to use something called an APPLET tag in your Web page source. (This tag will be described shortly.)

Figure 1.3: Running a Java application

Sun and other vendors also supply a subset of the JDK called the Java Runtime Environment, or JRE, for the operating systems they support. The JRE consists of only the Java virtual machine (the interpreter) and the supporting runtime packages. As such, it is intended as a distribution option for applications when you do not want to assume the existence of a virtual machine on your users' computers, or if you are worried that their version of the virtual machine might not match yours.

JAVA The Language

Java is based heavily on C++, with some key features borrowed from Smalltalk, Ada, and other languages. The working theme of the Java designers is always KISS ("Keep It Simple, Stupid"). To that end, the language does not have the following:

• Pointer variables. (It does have object references though, as you will see.)
• Memory allocation and deallocation constructs.
• Include files (copy members, in RPG parlance).
• Make files (a language for facilitating C and C++ builds).
• Multiple inheritance (an OO construct that C++ uses).
• Prototyping. In Java, you declare and define methods at the same time.
• Operator overloading, a complex function available in C++.

The biggest plus, from the point of view of programmer productivity, is the absence of memory-management functions. Instead of supplying built-in functions for getting and returning memory, Java offers automatic garbage collection. That is, when you declare variables, Java keeps track of where they are used at runtime, and frees up their memory when it determines your code no longer requires them. If you have written any C or C++ code or used the new memory allocation operation codes in RPG IV (ALLOC, REALLOC, and DEALLOC), you must take care to do the following:

• Allocate enough memory.
• Reallocate the memory when more is needed.
• Free up the memory when you are done with it.
• Free up the memory once and only once.

Memory management is very error-prone, and such errors are typically hard to reproduce and difficult to find. As the RPG IV reference manual states, "Misuse of heap storage can cause problems." Indeed. Garbage collection is a language feature Java picked up from Smalltalk, and one that, by itself, saves a significant amount of programmer time. (Now just imagine if someone could manage your real memory! You would save even more time! Maybe in the next release.)

In Java terms, KISS could also be interpreted to mean "Keep It Safe, Stupid" because, in addition to focusing on ease of use, Java focuses on security. An Internet language must be secure; it is not considered polite for code downloaded to client workstations to have the potential for obliterating the data maintained on those trusting, friendly little computers.

Java's extensive built-in security is designed to prevent problems that might arise from both malicious intent and poor programming. The most fundamental of these possibilities is the decision to not define pointers in the language. While this might be seen as a programmer plus (pointer programming, after all, is a battle-won skill), it also stands as a major sand trap for malevolent hackers. Many malicious programs are written by accessing memory that the program is not supposed to utilize, which is done by clever manipulation of pointers. We could tell you more about this but then, of course, we would be creating a potential security problem ourselves. Suffice it to say, "see no pointer, do no evil." (By the way, on the iSeries, pointers are not nearly as dangerous as on other systems because each one encapsulates significant security information. That's why they are 16 bytes long on OS/400, versus 4 bytes on a typical 32-bit operating system.)

The Internet, Html, and Java Applets

Java's initial role in life was that of a Web browser language. In this form, it is used to author applets that run inside Web browsers. Applets resemble traditional applications, except that they are embedded inside HTML and share the Web browser's user-interface real estate.

HTML is a tag-based language that resembles the way UIM (User Interface Manager) is used to author online help pages or menus on OS/400. A tag has both a starting form and an ending form, and the text for that particular tag goes between them. For UIM, the tags are special symbols that start with a colon (:). Typically, the ending tag is the same as the starting tag, but with an e prefix. For example, in UIM, you start a list with :ul (for "unordered list") and end it with :eul (for "end unordered list"). In HTML, the principle is similar, but the syntax is slightly different. Rather than denoting a tag with a colon, HTML encloses it in angle brackets. And rather than ending a tag with an e, it ends a tag with a slash (/). For example, an unordered list is started in HTML by

• and ended with

.

HTML includes many tags for partitioning and formatting text. For example, you can use tags for creating headings, paragraphs, and lists, as well as for formatting text. An example of HTML is shown in Listing 1.1. Figure 1.4 shows how this HTML appears in Netscape's browser.

Listing 1.1: An Example of HTML Code

My First Web Page

This is a header

This is a paragraph. Well, you see how simple it is! The following is an ordered list...

1. Type in the starting tag inside angle brackets
2. Type in the body between the tags
3. Type in the ending tag with a slash in front

Figure 1.4: The result of the HTML example in Listing 1.1

HTML tags are not case-sensitive. Some tags, like

(horizontal rule) do not have an ending tag. Others, like

• (list item), have an optional ending tag; the end is implied by the existence of the next tag.

  HTML is not compiled. You simply create the source with a text editor, save the file with the filename extension .htm or .html, and then open the file directly with your Web browser. The Web browser interprets the HTML commands on the fly and displays the contents according to the instructions provided by the tags.

  HTML provides plenty of tags to spice up your Web pages, including some for formatting fonts and graphics, and even some for audio. One all-important tag is used to link text or an image with an element elsewhere on the same page or on another Web page. The text or image that represents the link is highlighted in several ways, depending on how the user has configured the browser. Most often, a textual link is displayed in the browser window underlined and in a different color than the rest of the text. An image that functions as a link is usually surrounded by a black border. When you pass your cursor over the link, the cursor turns into a little hand. Clicking the mouse while over the link takes you to the referenced Web page. That is, the content of the Web browser's window changes to display the referenced page or graphic. Clicking on the left arrow in the toolbar of the browser returns you to the originating page. The ability to jump quickly from one location to another is what puts the hyper in hypertext, enabling you to author a complex web of pages that are easily traversed by the end user. An example of HTML code for a hyperlink is shown in Listing 1.2, with the result in Figure 1.5.

  Listing 1.2: An Example of the HTML Anchor Tag for Creating Hyperlinks

   

  Figure 1.5: The Web page produced with the HTML anchor tag

  Authoring traditional, static Web pages, then, is quite simple. You only need an editor, an HTML reference manual, and a Web browser. All of these are available for free on the Internet today. Of course, the example shown presents a link to a local file on your hard disk; you have not actually made a link to a location on the Internet. To do that, you need to connect your computer to the Internet. This is often done by paying a monthly access fee to an Internet Service Provider (ISP).

  Along with giving you access to the Internet, it's common for ISPs to allocate space where you can install your HTML source files on their servers. You then use their servers' HTTP (HyperText Transport Protocol) software to make your HTML files accessible from the Internet. HTTP servers serve up Web pages to Web browsers, so they are often referred to as Web servers. Alternatively, you can get a leased line to enable your own Web server to the Internet.

  The directory on the Web server where your HTML files, graphics files, and other files are stored is assigned a universal, unique URL (Uniform Resource Locator) address. This URL enables your Web pages to be found by Internet surfers. They can display your page either by typing in its URL in their Web browser window, or by following a hypertext link. The important thing to remember about these links is that they can refer to any HTML file anywhere in the world, as long as that file's URL is known.

  A URL address consists of several parts:

  • The protocol or prefix section of the URL denotes the part of the Internet on which the file resides. Web pages use the HTTP protocol, which corresponds to the prefix http://, whereas file:/// is used to identify local files.
  • The protocol is followed by the domain name for the HTTP server, such as www.ibm.com.
  • The domain name is followed by the pathname. This includes a series of file directories, separated by slashes, and ends in the actual filename of the Web page, graphic image, or other object to be displayed by the browser.

  URLs can refer to many types of resources accessible through the Internet, in addition to HTTP files and local files. The Web browser knows what type of file to expect based on the protocol in the first part of the URL name. Also, Web servers can be configured to map URLs entered by a user to entirely different physical files on disk.

  Here's an example of a typical URL:

  http://www.ibm.com/software/ad/vajava.html

  This identifies the Internet file vajava.html, in directory software/ad, at HTTP server domain www.ibm.com—the IBM home page. How did IBM get its domain name www.ibm.com? It applied for it, from a regulating body that hands out unique names.

  The infrastructure and underpinnings of the Internet are beyond the scope of this book. For more information, consult any number of books published on the subject, or start with the OS/400 manual, OS/400 TCP/IP Configuration and Reference (SC41-5420).

  HTML as an Internet user interface language

  Choosing a Web browser interface for your applications is a good idea. With such an interface, your internal applications, such as accounts-receivable files, can be served on an intranet that only employees of your company can access (or even only certain employees within your company). Your external applications, such as product-ordering forms, can be made available to the Internet world at large.

  Such filtering of access between external Internet files and internal intranet files can be accomplished with a security device called an Internet firewall. A firewall is software or hardware that restricts access to a Web site to Web surfers with a particular computer IP address or within a particular block of IP addresses, or by means of passwords.

  Regardless of whether you choose intranet or Internet deployment for your files, the bulk of your application runs on the server. Typically, only the user interface itself runs on the client. Furthermore, even these client- or Web-browser-hosted pieces are downloaded on demand to the Web browser from your server, by your Web server software. This architecture offers a number of advantages over the traditional client/server option for adding graphical user interfaces to your applications. Specifically, this architecture:

  • Supports all clients, not just Windows
  • Removes the need to install and maintain your programs on every user's workstation
  • Leverages your server's scalability, security, backup infrastructure, and performance
  • Expands your application's reach to potentially anyone with a Web browser

  But there is a problem; these Web pages are static, which means they only display information to the user; they do not accept input from the user. This is pretty useless for interactive applications. How many AS/400 applications have you seen that are comprised entirely of UIM help panel groups, without display files to interact with the user, and that lack RPG code to process that information?

  There is a way, using conventional HTML, to define interactive Web pages. It involves special HTML tags for defining forms, which allow you to create input-capable fields such as text entry boxes and drop-down lists. Here are the steps by which data on a form is received from a user and processed on the server side:

  • The HTML form defines fields that ask the user for some type of input.
  • The HTML form contains a Submit button that is associated with a server-side program.
  • When the user presses the Submit button, the input is sent to the server-side program.
  • The server-side program uses APIs to retrieve and process the input.
  • The server-side program uses APIs to create and return a new Web page that is displayed to the user.

  The server-side program used to process HTML form input is called CGI, or Common Gateway Interface. CGI is the standard protocol between the Web browser and the HTTP server for processing forms. CGI was, prior to Java, the only way to allow users to interact with your Web browser pages. It is a mature and pervasive technique for producing interactive browser-based interfaces. If you have ever registered a software purchase via the Internet, for example, chances are a CGI program got your purchase information to the vendor.

  Various languages can be used for writing the server-side program, depending on the Web server (that is, the HTTP server) software you are using and the one on the server itself. All offer CGI support, and all of them support RPG as a CGI server programming language. Another alternative is to use a general scripting language called Perl. Perl is an interpreted language that works well for writing CGI programs and is available on all major operating systems, including the AS/400. It is quite an arcane language to learn, but it is available everywhere and is always freely downloadable from the Web. Perl comes from the world of shareware—UNIX. To find out more, see www.perl.com.

  Do you have to learn CGI programming techniques to write interactive Web pages? Not anymore. There is a new option for Web server software, called Java servlets. This part of the Java initiative has been adopted by all major Web servers, including IBM's. To enable servlets, IBM offers WebSphere Application Server, which works with IBM's HTTP server and most other Web servers, including Microsoft's Internet Information Server (IIS). On AS/400, the standard edition of WebSphere Application Server is available as a free offering, at least up to version 3.5.3.

  Servlets are just like CGI programs. The HTTP server calls them when the user presses the Submit button, they process input from HTML forms, and they produce new pages to be displayed in a browser. However, they are written in Java and use specific Java-sup- plied APIs to process input and prepare output. They are loaded into memory once and remain in memory until a preconfigured time. CGI, on the other hand, starts another job for each call to a CGI program. This means servlets offer the programming, security, and stability advantages of Java, are more efficient than calling external CGI programs and, furthermore, easily support state information between client invocations.

  Servlets are exploding in popularity, especially among AS/400 programmers who are used to the screen-at-a-time user interface model that HTML offers.

  Java as an Internet user interface language

  So how else does Java fit into this picture? Through a new APPLET tag added to the HTML language. This tag refers to a Java program (an applet) to be run by the browser when the tag is encountered while reading the HTML. These programs most often contain user interfaces, although they can as easily be raw logic, such as a tax calculation. If the applet involves a user interface, it has the full power of Java's very rich graphical user interface support. For example, an applet might show a multiple-column scrollable table, something not possible in HTML alone. However, applets usually do not have their own main window. Rather, they use the window of the Web browser. This is what distinguishes a Java application from a Java applet. Because these Java programs do not have their own windows and cannot be started from the command line, they are referred to as applets instead of full-fledged applications. The applet inserts user interface parts such as lists, push buttons, and entry fields into the Web browser's window at the point in the HTML where the APPLET tag is encountered.

  The APPLET tag includes parameters for specifying how the HTML text will flow around the applet, and how much of the Web browser window the applet will occupy. There is also syntax for specifying hard-coded parameters to be passed into the Java program. Of course, these applets are not traditional program files at all, but Java .class files containing bytecodes that will be interpreted by the Web browser's built-in Java interpreter.

  When the Web browser sees the APPLET tag inside an HTML page, it goes back to the HTTP server where the HTML page originated to find the referenced Java class. Once found and downloaded, the Java class is interpreted, or run, by the Web browser. If you have ever seen a "Java applet started" message when browsing a Web site, you have encountered a Java applet.

  While Java applets have the full power of the Java programming language at their disposal, they do have some restrictions regarding access to the local client workstation's resources for security reasons. That is, an applet cannot read or write files on the local file system or call any local executables. It can do communications back to the server it came from, however. These restrictions are known as the sandbox that the Java applet must live within, which is a constraint not faced by a full-fledged Java application.

  You can even free yourself from these constraints if you know who your users will be. The JDK comes with tools for digitally "signing" your applets so that users can be guaranteed it came from you untampered. If the users trust you, they can allow signed applets from you to access their workstation resources. This works well in intranet environments, where you can predefine who is allowed to distribute signed applets for company-wide use and you can identify which employees are allowed to run them. (The flip side of signing is the ability to preauthorize only selected users to run the applet.)

  ---

  ---

  JAVA Applications

  Certainly, the prospect of being able to embed Java applets inside HTML Web pages is an enticing one. That is the fuel that has fed Java's wildfire acceptance. However, you can write full-fledged applications with Java, as well. These might be server-side applications that run on the AS/400 and do business logic or data manipulation, or client-side applications that display full-fledged user interfaces, access the AS/400 for data, or call programs on the AS/400. These applications are invoked by running the java interpreter on them. You pass to the interpreter command the name of the Java class file to be interpreted.

  Java applications are portable to all Java-enabled operating systems (which means all operating systems). They have the advantage of having their own main window and user-interface real estate. They also do not have the sandbox restrictions of Java applets. However, you have the responsibility of distributing client-side GUI Java applications (versus applets or server-side programs) that communicate with server-side programs, as you would with any client/server application.

  For servers such as the AS/400, you can only run Java applications that do not have a GUI. While there is technology for running graphical user interface Java applications on the AS/400 directly (via Remote AWT or JBroker technologies), it is recommended that your server-side Java applications be non-interactive and focus on the business logic. For the user interface, use either raw HTML, HTML with applets, or full-function client/server GUI applications.

  This book focuses on the technology for writing Java code that can be used inside applications or applets or servlets.

  ---

  ---

  JavaScript

  On the client side, Java applications and applets are often used in intranet environments where there is a well-defined user population and a high-speed network. For Internet environments or far-flung intranet environments, we have seen a return to raw HTML. This is because HTML has the fewest client requirements (it can run in any Web browser) and is by far the fastest option when slow modem connections have to be supported.

  As mentioned earlier, you can use Java servlets running on your Web server to dynamically create HTML Web pages and process the input from them. Since the servlet is running on your server, it has access to your data, applications, and transactions. It can draw on these resources to process the input and build the content of the pages to be displayed. For example, a customer might enter a bank account number in an HTML form, and the servlet will use that to access the account information and generate an HTML page to display that information. This could be done with all-Java business logic or by calling an existing RPG program.

  The original downside of HTML as a user interface language was its weak GUI constructs and lack of programmability. Hence, the initial excitement in Java applets, which allows you, for example, to display an entry field that only takes integer numbers as input. With raw HTML, you have to use a form and send the data to the server first, where it is verified. If the user typed something incorrectly, you have to wait for an entire new page to be returned from the server in order to see the error message. A Java applet can catch syntactical errors and display the message immediately, without a round-trip to the server.

  Time has moved on for HTML since the early applet days. There is now an industry- standard version of HTML called Dynamic HTML (DHTML). This is a combination of HTML, something new called Cascading Style Sheets (CSS), and a new embedded language called JavaScript. Cascading Style Sheets offer much-improved visual control over your Web page, and allow you to set corporate look-and-feel standards across your entire Web site. JavaScript offers an alternative to Java applets for writing code to run directly in the Web browser. It looks like a subset of the Java language, but is quite different. It is embedded via

My Second Web Page

To see my first web page, click <a href="html1.htm">here</a>