Deciding on how youre going to go about programming for the Internet isnt as simple as choosing a language. You really need to look at the higher-level issue of the approach and methods youll employ to deliver your applications. In this article, youll 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 companys 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, MCs 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 wont wait for a large Java applet to download; often, they will simply visit another companys 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 PCs browser, that applet has no access whatsoever to your PCs hard disk. The applets only I/O capability is directed toward the server machine that originally hosted it. However, an applets 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 dont 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: Whats 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 theyre written in Java), and youd almost be correct in that thought. However, youd 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 simplesimple, 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); Ill 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 dont 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 protocollike 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 doesnt 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 ASNAs Visual RPG and IBMs VisualAge for RPG, allow you to develop applications much as you always havebut 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, youll have to manage software distribution of that application. And dont forget that, with sockets, unless you use Internet middleware, youll 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? Isnt 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:
DCOMMicrosofts Distributed Common Object Model
RMISuns Java languages Remote Method Invocation
CORBAObject Management Groups (OMGs) 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 applications 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 applications host API is then accessible from remote applicationsas 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 applications 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 applications 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 machines URL. Basically, your remote programs are thin clients with the fat server code remaining on the host. Isnt that what client/server is all about anyway?
Id 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 Javas 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 wasnt sure what to call this strategy, but because its implemented when a product dynamically converts the vendor-specific presentation of applications to a standard Internet protocol, Ill 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. Its 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 applications user interface. (With CGI and servlets, youll still have to develop a user interface with HTML.)
Another important example of a vendor-specific presentation is for the AS/400s 5250 user interface. SEAGULL Softwares 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.
IBMs 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 applications 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 IBMs 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 didnt 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 companys 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 PCs browser on the request of an HTML applet tag
Java Applets
Java Applet Requests
Download
HTTP Web Server
Java Applet
init start stop
Java Servlets
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
doGet doPost service
DB2/400
Dynamic HTML
LATEST COMMENTS
MC Press Online