Deciding on how you’re going to go about programming for the Internet isn’t as simple as choosing a language. You really need to look at the higher-level issue of the approach and methods you’ll employ to deliver your applications. In this article, you’ll learn about the different strategies available today and gain some insight into the strengths and weaknesses of each.

Designing a Web site that presents more than just the pomp and circumstance of pages constructed from static HTML requires some advanced programming strategies. As your company’s Web evolves, you will have to select from a variety of Internet programming strategies. In this article, I will be overviewing Internet programming with low-level sockets, distributed objects, Java applets and Java servlets, and even a couple of vendor-specific strategies. In an accompanying article, Jim Wiley, MC’s Webmaster, discusses the programming strategies of Common Gateway Interface (CGI), JavaScript, Active Server Pages/ActiveX Data Object (ASP/ADO), Dynamic HTML (DHTML), and eXtensible Markup Language (XML).

Applets are the small programs that propelled Java into considerable fame. Because of the media frenzy surrounding Java use on the Internet, Java is now the most recognized computer language in the world. Applets are Java applications that are stored on your Web server. The Java programs for these little applications is served to Web browsers much the same as an HTML file is served (see Figure 1). Java Applets are considered a major component of the popular (if not yet prevalent) thin-client strategy because the distribution of these applications is handled dynamically by the Web server. The software requirements for visitors to your Java-enhanced Web site are only that their Web browser be Java- enabled.

However, applets have recently fallen into some disfavor as a viable language for the Internet. The reason is quite simple: As applets grow more able to handle complex

Applets

business applications, they necessarily grow in size. The Java code then takes a longer time to download to remote machines. Many customers won’t wait for a large Java applet to download; often, they will simply visit another company’s site. The problem with the lengthy download time is bandwidth and, once the bandwidth problem is solved, applets may be used more heavily. And, while Java applets do add the power of a sophisticated GUI, you have to consider the learning curve of Java, GUI design, and object-oriented programming (OOP).

One of the good things about applets is that, in a world plagued by computer viruses, they are considered secure. Once you have downloaded an applet to your PC’s browser, that applet has no access whatsoever to your PC’s hard disk. The applet’s only I/O capability is directed toward the server machine that originally hosted it. However, an applet’s inability to access the resources of local PC or host sites other than its original host machine can be construed as a constraint as well as a safeguard. Despite the downside of applets, they still deserve heavy consideration for AS/400 applications. Users want a GUI, and programmers don’t want to maintain the hardware and software base of thousands of PCs. Applets are a viable solution to that problem.

So, if you want to deploy a powerful business application across the Internet but you see Java applet download times and CGI execution speed as an issue, what do you do? The latest rage in Internet programming strategies is Java servlets. Servlets are so significant that a complete article in this issue is devoted to them (see “Servlets: What’s Old Is New” by Sonjaya Tandon elsewhere in this Focus section). A servlet is basically the opposite of an applet. That is, an applet is downloaded to the client to present a GUI while servlets remain on the host as background processes to serve application data in the form of HTML (see Figure 2). You could think of servlets as the equivalent of CGI programs (only they’re written in Java), and you’d almost be correct in that thought. However, you’d be discounting the inherent power of OOP and the cross-platform capabilities of Java.

Servlets are platform independent. They are efficient where CGI programs are not. The Java servlet API is simple—simple, that is, if you know Java. Also, because the servlet-programming model has been so well received, there is a whole new crop of Web servers that are optimized for servlets. This new class of servers allows you to take advantage of Enterprise JavaBeans (EJB), Remote Invocation Method (RMI), and Common Object Request Broker Architecture (CORBA); I’ll explain more about RMI and CORBA later. Servlets are among the most recent of the Internet technologies, but if your shop is not prepared to make the shift to Java, servlets may not present a viable strategy for you.

Look, this whole deal, this deployment of business applications across the Internet, is merely about remote communications, right? Why don’t you just get down to brass tacks and write the low-level communications yourself? You can cross out Advanced Program- to-Program Communications (APPC) programming; IBM lost its chance there. The low- level communications strategy of the Internet today is sockets (see Figure 3).

You can write to the sockets API with any language that supports it, such as C, C++, RPG, COBOL, Visual Basic (VB), and even Machine Interface (MI). You could even ignore the trendy Java language and disregard the fact that the Java sockets API is extremely easy to use. Realize that, in the end, regardless of the Internet strategy that you use, somewhere, somehow, sockets programs are going to be created to handle the remote communications. So, why not write directly to the sockets API?

The biggest problem with writing your own sockets communication is that you have to develop your own protocol. A protocol is the structure of the data that is to be sent between the remote and the host applications. The other Internet programming strategies either handle the protocol for you or give you a protocol—like HTML and the Internet InterORB Protocol (IIOP) used in CORBA and RMI.

Servlets

Sockets

But, when you write your own sockets code, you must first develop your own protocol and then code your applications to package data into that protocol. Then, you code your application to send that packaged data across the Internet to a receiver application. That Internet application partner program is coded to disassemble the data and stuff it back in a readable form for whatever system it resides on (taking care to handle details such as ASCII-to-EBCDIC text translation and little-endian to big-endian numerical conversions). Simple enough, if you are technically proficient in low-level TCP/IP communications and your company doesn’t mind you doing all of this bit-twiddling.

Because the TCP/IP sockets API is the standard means of communication on the Internet, many vendors have developed middleware that creates or enables the sockets low- level programming for you. To oversimplify, all you need to do is to specify the URL of the host machine in your remote application code, and the middleware does the rest for you.

ODBC drivers, for instance, allow you to use a variety of languages to develop applications that can communicate across the Internet to interface with RDBMSs via SQL. Other languages, like ASNA’s Visual RPG and IBM’s VisualAge for RPG, allow you to develop applications much as you always have—but with RPG language extensions to enable GUI programming. What they (IBM and ASNA) have done is to implement the sockets programming required to seamlessly transfer DB2/400 data to your remote RPG applications.

Why use sockets? Because sockets are fast, or perhaps because you want to use a language with which your coders are already comfortable. Why not use sockets? Maybe because applications developed for sockets do not take advantage of the thin-client model. Then, too, you’ll have to manage software distribution of that application. And don’t forget that, with sockets, unless you use Internet middleware, you’ll have to turn an object into raw data, send that data across the network, and then turn that raw data back into something your application can use.

Distributed-object Communications

If the world has moved to OOP, why all the talk about low-level protocols? Why should you have to learn TCP/IP sockets or even HTML as a protocol? Isn’t the list of the functions associated with a class essentially the protocol of that class? Yes, the API of a class is conceptually the same thing as a protocol. And, yes, there already is an Internet programming strategy for using the class API as an application protocol. Actually, there are three present strategies for the Internet distribution of objects:

• DCOM—Microsoft’s Distributed Common Object Model
• RMI—Sun’s Java language’s Remote Method Invocation
• CORBA—Object Management Group’s (OMG’s) Common Object Request Broker Architecture

Although the implementations of these three distributed-object communications strategies vary considerably, the basic concepts are the same: You develop your host application’s interfaces using your language of choice; then, you use a tool that creates all of the sockets programs required to handle the low-level TCP/IP Internet communications. Your application’s host API is then accessible from remote applications—as if the host application were local to the remote machine (see Figure 4).

Without a distributed-object strategy, your remote applications would have to contain all of the code to maintain the application’s data (with DB2/400) and to handle the low-level communications. With a distributed-object strategy, you develop the base components of your applications to remain on the AS/400. Then, you develop your application’s remote programs with code that merely provides a GUI. Those remote GUI programs seamlessly access the host API after registering with a DCOM, RMI, or CORBA utility passing to it the host machine’s URL. Basically, your remote programs are thin clients with the fat server code remaining on the host. Isn’t that what client/server is all about anyway?

I’d like to quickly summarize the differences between the three models. RMI, the simplest of the three, is a Java-to-Java strategy and, as such, is language dependent. DCOM is language independent but, even if, as rumored, an AS/400 DCOM is being developed, DCOM is still platform dependent. CORBA is also language independent, but CORBA is truly platform independent as well.

CORBA is a set of standards for the implementation of Object Request Brokers (ORB) by third-party vendors. Its architecture is designed by the OMG, a consortium of suits (powerful and important businessmen) from a large number of companies. In the short-term future, CORBA and RMI will have an increasingly closer relationship: The low- level protocol for CORBA has always been IIOP, and Sun has recently decided to also use this protocol for RMI. Right now this means little, but in the future, CORBA ORBs may be able to broker RMI requests and vice versa.

With distributed-object computing, the code base of all but the application GUI remains on the host. You take full advantage of your object-oriented application by extending it to the Web. Your Internet applications are then more scalable than with other Internet strategies. The problem with DCOM, RMI, and CORBA is that their implementation quickly becomes complex; even the simplicity of Java’s RMI becomes complex in actual deployment. Again, as I mentioned with servlets, a new breed of application servers are now being designed to work with all three of these distributed-object strategies to help manage some of their complexities of deployment. Also, the new EJB specification will go far in reducing the complexities of distributed-object communications. We just have to wait for solid implementations of the EJB spec.

Vendor-specific Strategy

I wasn’t sure what to call this strategy, but because it’s implemented when a product dynamically converts the vendor-specific presentation of applications to a standard Internet protocol, I’ll call it vendor specific. The biggest example of a vendor-specific application is Lotus Notes. Notes has its own strategy for designing, storing, and presenting applications. It’s the job of Domino to dynamically convert the presentation of a Notes database to HTML. That Notes application is then available on the Internet through your Web browser.

Essentially, vendors that are using this type of Internet programming strategy are doing the same things behind the scenes that CGI or servlets do: convert your application to HTML. These products go a step farther than CGI and servlets in that they dynamically convert your existing application’s user interface. (With CGI and servlets, you’ll still have to develop a user interface with HTML.)

Another important example of a vendor-specific presentation is for the AS/400’s 5250 user interface. SEAGULL Software’s J Walk, for instance, dynamically converts your green-screens (subfiles and all) to the HTML protocol that your Web browser can cope with (see Figure 5). J Walk goes further than simple screen scraping because it allows you to enhance the GUI that J Walk dynamically generates from your old 5250 application screens.

IBM’s Net.Data, yet another example of a vendor-specific Internet programming strategy, may not convert your 5250 screens, but it does allow the simple creation of scripts that convert your application’s DB2/400 database into HTML using SQL, REXX, and calls to legacy programs.

The problem with many of these vendor-specific strategies is their cost and the need for your commitment to one vendor. Net.Data is actually not that costly, but it still is vendor-specific technology (although all of IBM’s platforms fully support Net.Data). Products like J Walk may be the quickest way to get your current applications on the Internet, but, since the basis for those dynamically generated GUIs is your 5250 screens, realize that the resulting GUI may not be all that sophisticated.

Domino may have warranted a complete Internet Programming Strategies category of its own, but I didn’t want to toot the horn of one vendor. Nevertheless, I must say this

about Domino: It is a powerful and excellent strategy (although a costly one) for extending your AS/400 applications to the Internet.

Paths to E-commerce

There are many paths to e-commerce; this article and the accompanying article by Jim Wiley cover some of the more prevalent ones. Selection of your Internet programming strategy depends on your Web design strategy. In “Evolutionary Phases of a Web Site” elsewhere in this section, Eden Watt presents six phases of a company’s Web site. If your Web site is at the first evolutionary phase, which Eden calls Web presence, then your programming strategy should be fairly basic, perhaps static HTML and some CGI. But if you are taking your Web site to what Eden calls the innovation phase, then you should be very excited about working with some of the more complex Internet programming strategies presented in this article. The Internet gives your company the opportunity of market dominance by technical innovation.

Web Browser

Java Virtual Machine

Java Applet Storage

Figure 1: Java applets are stored on the IFS of your AS/400 and are downloaded to your PC’s browser on the request of an HTML applet tag

Java Applets

Java Applet Requests

Download

HTTP Web Server

HTTP Web Server

Java Applet

stop destroy

init start stop

Java Servlets

Web Browser

Web Browser

Servlet Request

HTML Page

Servlet-enabled Web Server

Servlet Engine

Java Servlet

Figure 2: Java servlets run on your AS/400 host; servlets dynamically build HTML that is to be presented in a remote Web browser

service init

doGet doPost service

DB2/400

Dynamic HTML