Moderator : Thank you for joining us for our Live Expert Q&A session with Joe Pluta. Joe is president of Pluta Bros. Design, Inc., and author of e-Deployment, The Fastest Path to the Web. Post your questions and get A-Z solutions to put existing AS/400 applications onto the Web. Discover server/client vs. client/server insight, plus Java and XML essentials, network legacy systems expertise and much more!

Moderator: Our first question today is...

bvigil21554: Does Java work on the AS/400?

Joe_Pluta : Absolutely! I've taken JAR files written for Unix machines and simply copied them onto the AS/400 and have run them with no problem. I used this technique to convert AS/400 spooled files to PDF files.

cferraro153178: How do the graphics work?

Joe_Pluta : That's a little more of a problem. Since the AS/400 has no native graphical capabilities, the graphics packages such as AWT and Swing don't work directly on the AS/400.

mdavidson67495: How do you write graphical applications?

Joe_Pluta : You need to use a somewhat more sophisticated approach, and design client/server applications. Or, as my book shows, server/client applications.

mlewis454106: What is "server/client"?

Joe_Pluta : Server/client is sort of the reverse of client/server. It's designed to allow you to put legacy systems onto the network. The primary application -- the legacy program -- runs in batch on the host. That's the client. It makes user interface (UI) requests to the UI server, which communicates with the user either through Swing or through HTML.

ehurley691714: How is that different from client/server?

Joe_Pluta : With server/client, the user interface is controlled by the application program: it shows a specific screen of data, and then when the user responds to that, the application shows the user another screen of data. The application flow is entirely under the control of the host program. In client/server programming, the server programs run on the host, and aren't written to communicate with an end user at all. They simply receive requests--read a record, update a record -- and process them. The client decides which request to send and what data to show to the user.

pvio399974 : Are these server programs written in Java?

Joe_Pluta : No! That's the important point for AS/400 programmers. While Java is great for middleware, it's still much easier to develop business logic in RPG or even Cobol. In both client/server and server/client architectures, the business logic is still written in a traditional high-level language.

jhubley528600 : So what is Java good for on the AS/400?

Joe_Pluta : At this time, Java is best suited for middleware, and especially for servlets. The work I've done to date indicates that the best architecture is a Java user interface, either a servlet or a Swing application, communicating via messages to an RPG program running on the AS/400 that contains all your business logic. For programs requiring high-end graphics, use Swing, and for Web applications, use servlets and HTML.

hrhsoleil370270: What about XML?

Joe_Pluta : XML has a lot of potential in a number of areas. While XML can be used to take a non-human-formatted document and format it for the human eye (or the human ear!), to me XML's strength lies in its capabilities as a medium for computers to talk to one another. Computers used to have to agree on the position and format of individual bits of data prior to communicating with one another--with XML they simply need to agree on the names and XML takes cares of the rest.

lhunt62340: How would you use XML?

Joe_Pluta : Well, we're currently designing XML "wrappers" to fit around legacy applications. For example, a basic order entry system might need to respond to an XML "enter order" request. In that request, we'd have a customer number, and then a list of item numbers and quantities. This XML document then would be processed by an "XML macro processor"-- the macro processor would use the eDeployment technique to emulate the screens needed to process the order using the existing legacy application.

mdavidson67495: Isn't that just a screen scraper?

Joe_Pluta : Functionally, it's equivalent, but it goes far beyond what a screen scraper can do. With a screen scraper you're locked into the 5250 data stream, which means you can never really change your application programs. But with the XML wrapper approach, you can go to the next stage. You can write an actual server to process the order, and then change the XML macro processor to call that program. Once you've done that, you've removed the legacy application entirely, but without changing how you look to the outside world. This staged approach of wrappering, isolating and replacing allows you to re-engineer your systems without disrupting your day-to-day operations, and that is the Holy Grail of systems integration.

rampurawalami230297: We have AS/400 Server Model S20 and OS version V4R4M0. We have applications in Cobol and RPG. Please let us know how fast we can put our applications on the Web.

Joe_Pluta : The model number of your AS/400 is a concern, but other than that, you can put a simple program on the Web in four hours.

hertzel465670: What are the advantages for using WDT/400 over the regular Java programming for AS/400 by ET/400?

Joe_Pluta : I don't use WDT/400 --my development uses just native Java and WebSphere Standard Edition.

hertzel465670: Would RPG & C compilers be installed on the AS/400 by installing WDT/400 on Windows?

Joe_Pluta : Not to my knowledge.

Joyce.Riordan44110 : Do you recommend re-engineering applications prior to implementing them with the Web?

Joe_Pluta : That depends on your business requirements. If you have the time to re-engineer, then by all means do so. If not, though, and your users require a quick GUI solution, server/client provides a stepping- stone between traditional applications and true client/server processing.

heatherd35768: Is e-RPG a good way to get the information to the Web?

Joe_Pluta : e-RPG is an excellent short-term solution for shops which either have no Java expertise, or don't have the machine resources to run Java. My only concern with e-RPG is that it requires your RPG programmers to learn HTML. With a JSP/servlet technique, you can separate the UI coding from the business logic.

deborah-mclellan856535 : I've recently purchased an AS/400 9406 Model 170 and would like to connect this to the Internet so that I can access it from anywhere in the World. I hope to learn how to do this from your Webcast. I would like more info. Thank you. deborah-mclellan@home.com

Joe_Pluta : The model 170 is an excellent machine for Internet access, although I would suggest making sure you have at least 2-3GB (gigabytes) of RAM. With that, however, you can create quite a nice Web serving environment.

proubekas241682: Have you seen or used IBM's Host Publisher? What do you think of it? It does not require any 5250 screen changes, but it does have the WebSphere and HostPublisher layers to go through.

Joe_Pluta : I have not used Host Publisher; I concentrate on using Java along with base WebSphere. My understanding, however, is that Host Publisher jobs require interactive CPW -- server/client technology runs in batch.

kavitakalia745504: Do you know where would I be able to receive free AS/400 training in Toronto?

Joe_Pluta : No, I don't, sorry.

jangell649543: Can you tell us about your approach to Web-enabling legacy code?

Joe_Pluta : It's very simple. On the server side, I replace the I/O opcodes with calls to an API. The API writes the data to a "holding area", which I call a display file proxy. Then, the UI, either a servlet/JSP for browsers or a thick-client for Swing, reads the display file proxy object and displays the data.

cory.keith367792 : Does the new upcoming release of V5R1 include the ability to translate 400 apps directly to the Web?

Joe_Pluta : There are a number of options from IBM that allow "direct" translation of traditional applications to the Web, with varying degrees of success. I guess the choice depends on what you are trying to accomplish. I try to separate the UI from the business logic in such a way that I can eventually "swap out" the old-style monolithic programs without changing the user interface code. Most 5250-based tools or CGI approaches won't allow that.

nathan.roberts61566 : I've seen examples of RPG that generate HTML and can be run from the Web. Yet I can't get it to work. Is something special needed to make this work (other than HTTP server running)?

Joe_Pluta : RPG-CGI is a good, quick, short-term tool, but I don't use it. Brad Stone's book on e-RPG is probably the best place to find information on that particular topic.

rhealey835210: Do you know of any prebuilt-templete type products containing java classes, servlets, HTML and JSPS to help a company put a store font on the Web quickly?

Joe_Pluta : No, although we're working on it . Seriously, there are two options: buy a 3rd party storefront (there are several very good ones) and integrate it to your existing systems, or figure out how to put your legacy systemns directly on the Web.

rdeardorff227528: How do you display OV400 documents on the Web without compromising security on other documents on the system, particularly security for QDLS?

Joe_Pluta : To be honest, I rarely work with Office Vision documents. I know that OV400 users are in a bind regarding moving to new technologies, and from what I understand, IBM's stated direction is to reformat them. At that point, you'll be able to use more standard security approaches.

cory.keith367792 : Does the new upcoming version of V5R1 include Web support?

Joe_Pluta : From what I've heard, there are quite a few advances in Web development that will be available in V5R1, primarily along the lines of a "refacing" strategy.

jbosko32911: So if the business logic is inside the RPG program, what do we use to communicate the data back to the UI?

Joe_Pluta : All of my communications use data queues, because they're fast, but you can use any messaging middleware you're comfortable with.

heatherd35768: What do you have to know to get your information from the AS/400 to the Web?

Joe_Pluta : You will have to understand basic HTML, as well as understanding how the HTTP server works After that, it's a choice of approaches. For a short-term approach, you can use CGI-RPG, and add calls to your RPG programs to write to the browser. For a longer-term solution, you should learn Java and JavaServer Pages. In my opinion, they provide a much more flexible long-term approach... sort of like DDS, only object-oriented.

pisaksson647100: What is the client written in? HTML?

Joe_Pluta : For server/client, the portion that talks to the end user (which is actually the server!) can be written either as a Java Swing application on the desktop, or as a servlet/JSP combination to communicate with a browser.

jsarmiento169740: How can one debug an ILE program, or API, to show values coming from a form post?

Joe_Pluta : Most of the time, I simply use the "snoop" servlet. By redirecting my form post to the snoop servlet ("http://myas400/servlet/snoop"), I get a very good listing of what the post information contains.

jwh955597: What is the difference between client/server and server/client and how is development different?

Joe_Pluta : Server/client requires only minimal changes to your existing systems. Most of the work is already done for you, and the applications "feel" similar to your existing applications. You can literally put a program on the Web in a few hours. Client/server, on the other hand, requires a complete re-engineering of your applications, and as such requires much more upfront investment. That's why I like to use server/client first, followed by client/server.

cscinocco271905: I hear a great deal about multi-tier processing environments, what combination of products/technology is going to be most common over the next few years?

Joe_Pluta : In my opinion, RPG and DB2/400 are the best combination for business processing on the planet. Using that as your business logic, I see the most common front end being a combination of JavaServer Pages and Java. The flexibility of JavaServer Pages, and the ability to use Web designers to design your application, makes it the most powerful technique by far. Combined with an RPG back end, I think it's unbeatable.

boler299643: What do you think of IBM's Web Facing Tool?

Joe_Pluta : I went to the demo at the Fall COMMON and unfortunately it wasn't available. That's all I've seen of it.

jsarmiento169740: Do you need WebShere to use XML or can the HTTP server be enough?

Joe_Pluta : You don't need WebSphere provided you use CGI programming. You need WebSphere to run servlets and JavaServer Pages. However, you only need the Standard Edition, which comes free with OS/400.

clark855993: I recently purchased the Fast Path to the Web book, but I had trouble figuring out what the fast path was. I just want to take an existing application and be able to run it from a browser while accessing native AS/400 files. Any advice?

Joe_Pluta : Yes, there are topics marked with a lightening bolt which can route you through the steps to take the application that is in the book and quickly put it on the Web. If you need any further assistance on which chapters or pages, just drop me an email at joepluta@plutabrothers.com.

davidc737860: Can this solution be a stair-step to creating a better interface for AS/400 applications?

Joe_Pluta : This is EXACTLY what the solution is intended to be. By first using server/client, you create a GUI interface for your end users, but the tiered design also creates what I call a "region of change" between your user and the business logic. At that point, you can begin to re-engineer your application in stages. This allows you time to prioritize and do things correctly, while still keeping your end users happy.

jsarmiento169740: What exactly is Swing?

Joe_Pluta : Swing is Java's thick-client platform-independent GUI. It's very powerful and runs on pretty much any machine.

cscinocco271905: Does it matter if VARPG or RPG is used for legacy applications?

Joe_Pluta : It shouldn't matter at all.

kenm500554: Have you seen IBM's WebFacing Tool and what do you think of it?

Joe_Pluta : Like I said, I tried to go see it but never got the chance. I know that the folks working on it are very, very good at what they do. I'll be interested in seeing the product.

xkong881547: Any tips for database programming in Java with real world examples?

Joe_Pluta : My single biggest tip is: don't do database programming in Java! Seriously, I highly suggest encapsulating your entire database I/O in RPG servers (or Cobol if you're so inclined) and calling those programs from Java, rather than doing the database I/O in Java itself.

boler299643 : Does the eDeployment technique you mentioned require changes to the existing legacy programs? How does it work?

Joe_Pluta : The changes to the RPG program are minimal. Wherever there's an EXFMT, you replace it with a call. The changes are so unintrusive, that, with the newest version of the APIs, the programs still run as traditional green-screen applications.

millerj317514: Is the AS/400 Model 170 processor feature 2291 able to run WebSphere successfully?

Joe_Pluta : I'm unsure what the 2291's numbers are. I've been running on a model 170 with a 416CPW rating and 3GB of RAM, and it's very responsive.

nathan.roberts61566 : Do RPG programs, which generate HTML, have good enough response times to use on a local Intranet?

Joe_Pluta : Absolutely. Then again, so do JSP/servlet programs. I have applications written using JSP/servlets that are actually faster than green-screen (at least subjectively!) because they send less data. They are literally subsecond response time on a local network.

maldearn556706 : Do you need to know a lot of Java for that?

Joe_Pluta : To implement JSP and servlets, you need surprisingly little Java. I teach people how to create a servlet in a two-hour lab at COMMON. For some of the more advanced techniques, you will probably need at least one person in your shop dedicated to Java/400 development.

Jan.Kilgore570138 : There seem to be a lot of tools available, we have lots of green screens that we would like to move to a GUI environment, what is our fastest path of getting this accomplished, we have a lot of RPG experience in our shop.

Joe_Pluta : It depends on your needs, Jan. It's hard to make a "one-size-fits-all" pronouncement. But I think that if you implement a server/client approach you will be able to quickly move applications to the Web, but position yourself to move to more advanced solutions when you have time. Server/client requires almost no changes to your existing applications --far less than any approach other than screen scrapers.

skinnerf886970: Will Microsoft's announcement about getting out of "Java" have an effect on developing AS/400 Web applications that use Java?

Joe_Pluta : Microsoft and Java have always had a rocky relationship... this isn't anything new, and will have little effect.

pisaksson647100: How does your approach differ from Web Facing?

Joe_Pluta : I require some changes to the RPG program. On the other hand, my user interface is not ultimately tied to the original program and can be reused later for true client/server development.

thea.goldsby826150 : In your opinion, what specifically about RPG-CGI makes it a "short-term tool"?

Joe_Pluta : Primarily the fact that RPG-CGI requires that RPG programmers learn how to code HTML. That's not a good strategic approach. Instead, you should have HTML designers and business logic designers.

jsarmiento169740: Are you suggesting that JSP is the quickest or best way to go? Also, what of Net.Data?

Joe_Pluta : I am flat-out stating that servlets and JSP are the best way to go, if you can afford the time and resources. It's the best architecture available. Net.data and RPG-CGI are good short--term solutions.

davidc737860: At Interactive Advantage Corporation, we develop computer-based and Web-based training for AS/400 systems. Could your system make it easier to launch small components of an AS/400 application with unique data streams for training purposes?

Joe_Pluta : Absolutely. In literally hours you could put small portions of an application on the Web. With minor modifications, you could use whatever datastream you needed.

majidy942149: The Webmaster's Guide (GC41-5434-01) is not very clear to configure the HTTPCONFIG, is there any new book out there?

Joe_Pluta : Not to my knowledge.

Joyce.Riordan44110 : What about security? What do I need to be concerned about?

Joe_Pluta : You need to exercise the same caution you would with any other sensitive application, using sign-ons. HTTP server does that quite nicely. Your bigger concern is putting your AS/400 on the Internet. That's an entire different discussion.

proubekas241682: Do you think IBM will ever give the iSeries a GUI interface?

Joe_Pluta : Not directly -- I expect instead for them to continue the Web facing direction.

larrym79548: Does WebSphere expect a Java UI only, or are there other options?

Joe_Pluta : WebSphere works with servlets and JavaServer Pages to output HTML. It is primarily used to interface between client systems using HTTP protocol and a Java program on the AS/400 (which can in turn call RPG).

nwilcox863154 : Is VisualAge for Java worth learning?

Joe_Pluta : VisualAge for Java is crucial to my development. Because it is a repository-based IDE, I find it to be essential to my productivity.

jangell649543: How tough is the learning curve using your approach?

Joe_Pluta : The learning curve is very small, because I provide all the tools you need to get started. I provide a complete step-by-step example. You just need to then begin expanding your knowledge in the directions most appropriate to your environment.

xkong881547: Which storefront software do you recommend?

Joe_Pluta : I've had good results with a company called Zilron.

mjasmin962662: What's your thought on Websphere vs Domino?

Joe_Pluta : Domino for documents, WebSphere for transactions. It's pretty clear-cut to me.

yves.marquis491892 : Can you describe a step-by-step approach to get an RPG program convert for interfacing with the Web?

Joe_Pluta : Yes I can -- it's in my book, Yves. It's really simple: replace I/O opcodes with API calls, create a display file proxy, and then create your UI.

Joe_Pluta : I've really enjoyed the discussion, folks! I'm only sorry we're limited on time here, because you've asked great questions. I'll work with the fine folks here to get the other questions answered. Please e-mail me with any other thoughts at joepluta@plutabrothers.com.

Moderator: This concludes our Live Expert Q&A session with Joe Pluta. Please come back soon as the questions that didn't get answered during the live event will be posted in a few days.

Moderator: These additional questions were answered by Joe after the live event concluded.

clachance933688: Do you have, or know studies about the market behavior on developing with Java, RPG or anything else?

Joe_Pluta: Sorry, no, I don't know about any such studies, but I do know that productivity studies have repeatedly shown that object-oriented development techniques, while more expensive in upfront development costs, more than pay for themselves by easier maintenance and enhancement down the road.

millerj317514: Should WebSphere 2.0 be uninstalled before installing 3.5?

Joe_Pluta: No, that's definitely not necessary. In fact, you may want to keep both environments up and running for a while. WebSphere 2.0 is a little easier to play with, especially until you get the hang of the administration client. But the benefits of WebSphere 3.x far outweigh the ease of use of 2.0, and you should migrate to 3.x as soon as it's convenient.

rdeardorff227528: Any recommendations on connecting a Linux Web server to an AS/400 data and application server?

Joe_Pluta: Well, that's an interesting option. Personally, I don't have any experience splitting a Web server (that is, an HTTP server) and an application server (a servlet engine) onto different machines. On the other hand, running your HTTP server and servlet engine on a Linux box and using the AS/400 as a back end processor is a design strategy that has a lot of merit. That architecture has a much better ability to scale your Web applications as well as providing an extra level of security for your business data. If you?re looking at a high-volume type of Web application, or you want to provide access to very sensitive data, you may do well to investigate a Linux front end.

xkong881547: How do you like commerce suite?

Joe_Pluta: I don't have any experience with it, sorry.

majidy942149: Do you have any new book for Webmaster's guide (GC41-5434-01)?

Joe_Pluta: No, sorry.

larrym79548: What is a good resource to help interface legacy applications to the Web through WebSphere?

Joe_Pluta: It depends on your goals. There are really two basic business objectives for interfacing legacy systems: providing Web interface to existing applications in lieu of a green screen, or exposing legacy business processes to distributed applications. For green screen replacement, you can use anything from a terminal emulator to Web refacing strategy. IBM and Seagull are two places to begin your research for those options, or you can take a look at my book, "e-Deployment: the Fastest Path to the Web". Exposing business processes is a bit more complicated, and you need to first decide what exactly your business issue is. For example, connecting a commercial storefront package to your existing order entry process is a different question than providing email distribution of business reports. Whatever the requirement, you'll need to find someone with experience actually doing what you need to do. There aren't many companies with that experience yet, but we do exist.

nathanma76565: Joe, you've used the term "Java widget" in some of your writings. Is a widget the same as a Java Bean?

Joe_Pluta: No. A widget is a term many GUI designers use to identify a user interface component. I've sort of co-opted the term to specifically mean a UI component that provides access to business application data. This sort of component can be written either using a thick-client approach such as Java Swing, or using HTML. The trick in HTML is to use the features of the HTML specification in conjunction with the servlet technology to create the equivalent of an input/output field. It's somewhat involved -- checkboxes act differently than text fields, for example -- but it can be done. Widgets also include meta-constructs, such as rows and tables. As the level of abstraction gets higher, widgets can even take on application characteristics, making it possible to create entire applications using simple, generic JavaServer Pages and very little Java programming.

msimmonds505952: What (if anything) can I use to give access to AS/400 green screen applications over the Web without having to rewrite any of the legacy code? Should I wait for V5R1, and if so when is that supposed to be coming out?

Joe_Pluta: To have no changes whatsoever to your existing applications, you'll have to use a technology that interfaces with the 5250 data stream. Several companies, including IBM and Seagull, provide that sort of technology. Also, V5R1 is supposed to include the new Webfacing tools from IBM, although I haven't yet seen a working demonstration of that technology, so I can't give you much information. Word on the street is that we'll see V5R1 in late second or early third quarter of this year, but I don't have any confirmed release dates.

xkong881547: What do you use to test and develop your JSP?

Joe_Pluta: I'm sort of old-fashioned in that regard. I do nearly all of my development for my JSPs in Visual Age for Java. Since my widgets are designed to be self-contained, I actually do most of my testing right in Visual Age. It's an incredibly productive platform for Java development. I've designed my own servlet testing environment, and it's usually just a matter of porting to the AS/400 and running the classes. Due to the component-based nature of my widgets, my JSPs generally have very little code ? typically 20-30 lines ? and don't require much testing at all.

Joyce.Riordan44110: You've only referred to RPG in your discussions. Are there any special challenges related to Cobol apps?

Joe_Pluta: No, not at all! In fact, one of my most successful clients has done all their development in Cobol. They're doing client/server development, migrating a standalone PC application to become a Web-enabled AS/400 application using a centralized database, which sort of counters the prevailing wisdom that people are moving off the AS/400 to "generic" PCs. This client realized that security, reliability and centralized access to data outweighs any initial cost benefits of the cheaper PC solution. They're doing this entire client/server application in Cobol, and the revitalization architecture, which is built on the same framework, also works just as well with Cobol.

nathan.roberts61566: What would you suggest to use to let local users access AS/400 reports through a Web browser via the local intranet?

Joe_Pluta: Like most questions having to do with TCP/IP access, that depends on your requirements. If printing is not a high priority, it's fairly easy to convert existing reports to HTML using CPYSPLF and a simple conversion tool. On the other hand, if printed output is important, I recommend using PDF format. There are several commercial spool-to-PDF options, depending on your needs; I even have a free version.

casey_r74405: How difficult would it be to have your servlet/JSP UI include an applet? This would be for those cases where you need a more involved interface than HTML alone can do

Joe_Pluta: You can include an applet in any HTML, and this includes a JavaServer Page. The trick would be interfacing the applet with the host data. While I haven't done much work specifically with applets, I've done plenty of thick-client work, which is the same architecture.

jburton125929: If we were developing a customer portal to give them access to data on our AS/400, which would work best: ASP using ODBC, WebSphere, or e-RPG? We think we will have to build from scratch since our legacy applications are not a good fit.

Joe_Pluta: My first option is to always review the legacy applications, but this is more important for data going into your system than data coming out. For inquiry applications, it's relatively painless to develop simple queries and display the information in Web pages. In either case, however, I still recommend the JSP/servlet approach over ASP or e-RPG. ODBC is a bad idea for a whole host of reasons, foremost of which is that your clients are tightly bound to your host database. This will greatly hinder your ability to change your systems down the road. I prefer a message-based approach, because it's so much more flexible. While such a system can be implemented in RPG-CGI, I recommend JSP and servlets, because they do a much better job of separating user interface design from business logic.

Joyce.Riordan44110: My head is spinning with all of this --- where do I obtain the knowledge necessary to pull all of these suggestions together?

Joe_Pluta: Believe me, my head has done its share of spinning, too. But to be honest, it's not that difficult, it's just a lot of pieces. Once someone shows you all those pieces, you'll be developing applications in no time. That sort of training can be done either onsite or at seminars. Midrange Computing has seminars, some of which I teach and I do onsite training myself.

braddavidson216187: Can you suggest any development tools to speed Web app. development?

Joe_Pluta: I use Visual Age for Java. There is no better tool for production-level Java development, including servlets. VAJ is a repository-based IDE, which means that it's ideally suited for developing the sort of sophisticated class hierarchies that a good business application requires. VAJ immediately shows you the impact of your changes, and also makes it very easy to move methods from one place to another within the hierarchy. In addition, VAJ's import and export capabilities make it very easy to develop Java code and package it for use on the AS/400. I'd be lost without it.

heatherd35768: What is a Java Server Page and how do you implement it?

Joe_Pluta: Good question. JavaServer Pages are different things to different people. In the simplest terms, I like to think of JSPs as HTML++... HTML enhanced by the ability to access Java objects and methods. You can do many things with a JSP, all the way up to writing an entire application in your Web page. But to me, the purest use of a JSP is to access objects sent from an application servlet to present data to the user, and return data back to the application. Your servlet actually gathers the data from your AS/400 and puts it into objects for the JSP to display. This way, you can have Web page designers who know about designing great Websites and programmers who know about writing great applications, and they can work together to build outstanding Web applications.

heatherd35768: How is a Java Server Page different than CGI?

Joe_Pluta: Actually, a CGI, or Common Gateway Interface, program is closer to a servlet than a JSP. Both CGI programs and servlets receive HTTP requests and either one can output HTML directly back to the user's browser. However, a servlet can also take advantage of JavaServer Pages -- it can create Java objects and insert them into the session to later be used by a JSP. A JSP is more of an enhanced HTML page. It has all the capabilities of a simple HTML page, but in addition it can access the Java objects passed from a servlet. Interestingly enough, when a Web server processes a JSP, it compiles the JSP into a specialized type of servlet; that's part of the reason that servlets and JSPs work so well together.

jburton125929: I have WebSphere 3.5.2 on the server, but don't have the console of the same version. How do I get the right version?

Joe_Pluta: Contact IBM. You should be able to get the WebSphere disks. If not, there is a command called "setupClients" up on the IFS that should create the appropriate clients, but I haven't used it yet. Drop me an email if you'd like more information on that.

cscinocco271905: What's better Java or VAJava?

Joe_Pluta: Visual Age doesn't compete with Java. It's a tool, known as an integrated development environment, or IDE, that makes it easier to develop application in Java. Think of it as a combined PDM and ISDB for Java. There are other IDEs out there, but in my opinion nothing compares to Visual Age for Java, especially for working with the AS/400.

diaber364242: How does of Domino Designer as Web designer stack up against using WebSphere?

Joe_Pluta: Lotus Domino is by far the best application for document processing. Its abilities in the areas of workflow processing and document presentation are unparalleled, but it falls short for transaction processing. Every attempt I know of for creating Web-based business applications with Domino has run into a number of issues related to how Domino does things. If you can live within Domino?s restrictions, it's a great development environment. However, Domino is like any other proprietary interface: when you run up against its shortcomings, you can find yourself with no recourse.

kenm500554: Will NET.DATA be a viable solution for the future in your opinion?

Joe_Pluta: I haven't done much work with Net.Data. The folks over at Ignite/400 have been doing tons of development with it, so I'd direct you to their site (www.ignite400.com) for more information.

guest40: Any different approach for COBOL legacy applications?

Joe_Pluta: No difference whatsoever. I've done development with Cobol and RPG, and they both work just fine. The interface I use is really very simple, and programmers comfortable with either language have learned them quickly.

oscar236286: Can you summarize your top strategies then? What should we be doing now?

Joe_Pluta: The single most important thing to do is to realistically decide what you need. Do you need to give Web access to your legacy applications? Do you need to interface your business logic with other applications? Do you need to provide access to printed AS/400 reports? Do you need to allow inquiry into AS/400 data? Once you've done that, you can then decide what architecture best suits your needs. For example, if you don't want to learn any Java, you may need to settle on RPG-CGI. But I highly recommend that you begin to develop in-house expertise with servlets and JavaServer Pages; that technology allows you to implement any business strategy that you need, and provides the most flexibility in terms of deployment.

alanf70936: Do you prefer WebSphere, the standard HTTP server or Apache?

Joe_Pluta: Apache and the IBM HTTP server are both designed simply to either serve static Web pages, or support CGI programs. Not only that, the upcoming "standard" IBM HTTP server is actually a version of the Apache server, so it's pretty much a moot point. As to the question of WebSphere vs. another servlet engine, the only other option I've used is Tomcat, which is the Apache open-source servlet engine. I've tried it and it works, but it's not nearly as well integrated with OS/400 as WebSphere. WebSphere continues to get better and better, and it would take a major problem for me to change. However, I highly recommend that whatever development you do, you stick to using only those features that allow you to move from one servlet engine to another --this allow you the maximum flexibility in deploying your applications.

clachance933688: If you had to develop and sell a solution to a customer for handheld and core system apps, how would you do it?

Joe_Pluta: I've already modified a green-screen application to run with a Palm Pilot. JSP and servlets work quite well with the Palm. That's the direction I would pursue.

xkong881547: Do you use EJB? When should I use it?

Joe_Pluta: I am not an EJB expert. Others know that architecture much better than I do. Don Denoncourt is probably one of the most knowledgeable people in the industry about using EJBs and the AS/400. When developing a distributed application from the ground up, you might want to look into EJBs. But for the vast majority of applications requiring the interface of the Web to existing legacy applications, business processes or databases, EJB is not required.

skinnerf886970: Will e-Deployment work in our situation? Corporate dictates that our main Web server be a NT IIS. We currently have applications where the UI is on the NT, it sends the request to an AS/400 Webserver that we use only as a CGI server (ERpg/Net.data). That system accesses the production AS/400 via SNA..

Joe_Pluta: I have in fact implemented exactly this sort of environment. If you can justify the expense, having one AS/400 for application serving and one for back-end processing is by far the most secure. The back-end AS/400 can then be entirely isolated from any TCP/IP access, which drops the likelihood of unauthorized access dramatically. For highly sensitive applications, this is the sort of tiered architecture I recommend.

rhealey835210: So because of performance you would recommend a hybrid RPG back-end/java, servlet,jsp front end, or is this just a stepping stone to the final solution being all java back-end and servlet,jsp front-end?

Joe_Pluta: At this time, there is no better architecture for business logic processing than RPG and DB2/400. But I don't think of this as a "hybrid", I think of it as the ideal use of the n-tiered design. You should implement each layer of the design with the hardware and software best suited for it, and then connect them with a flexible middleware layer that allows you to change the implementation as business needs and technology advances dictate. And today, that interface is servlets and JSP for the user interface communicating with RPG and DB2/400 for business logic processing.

jsarmiento169740: You stated that server/client is the quickest way to the Web but not the best. What would you suggest is the best method to re-engineer your apps for the Web? JSP, Java, CGI, RPG, or a combination?

Joe_Pluta: I suggest a two-stage approach. First, identify those programs that need to be Web-enabled and use the revitalization approach to give them a simple, practical GUI. This gives you time to evaluate which of your applications need further work. For those, I then suggest a gradual re-engineering to a message-based client/server design, using a JSP/servlet front end communicating with an RPG server back end.

rich1865480930: Do you know what IBM Manual covers Web Sphere?

Joe_Pluta: The online documentation for WebSphere is at the following URL: www-1.ibm.com/servers/eserver/iseries/software/WebSphere/
wsappserver/docs/doc.htm

pisaksson647100: What considerations do I face when trying to scale a non-telnet application?

Joe_Pluta: The biggest issues I've found with scaling any sort of business system is application maintenance. What seemed like a good idea for one or two or even ten screens quickly becomes a nightmare when the numbers grow. Each well-intended shortcut has the possibility of becoming a disaster. That's why I recommend generating as much of your interface programmatically as possible, which in turn dictates a design that can be programmatically generated. Remember during your design that everything you handcode will have to be repeated for every screen; and any change will also have to be repeated. Whereas, any generated code, the modification needs to be made only once.

jsarmiento169740: Why not use Java for database programming?

Joe_Pluta: Because Java isn't intended for either high-speed access or high-speed calculations. For example, there is no primitive fixed-precision decimal number. You must either use integer arithmetic or floating-point arithmetic. In order to emulate the standard calculations we are used to in RPG, you need to use the bulky and poor performing BigDecimal class. Database I/O must be performed either via the Java Toolbox, which is somewhat acceptable, especially when encapsulated in decent support classes, or else you have to use SQL, which is simply a horrible way to develop business applications, in my opinion. Either way pales in comparison to the native I/O capabilities of RPG or Cobol.

msimmonds505952: Where do I found out more about eDeployment? You replace the EXFMT with a call to what? Is this an IBM product?

Joe_Pluta: EDeployment is my architecture, and you can either get the book "eDeployment: The Fastest Path to the Web", or drop me an e-mail. My address is joepluta@Plutabrothers.com. I?ll also have a fully functioning demonstration system up and running on the net by June of this year. In simplest terms, you replace each EXFMT (or other display file opcode) with a call to a simple API. This API sends the data to a holding area, which is later queried by the UI portion.

xkong881547: Should I use Dataq or socket to do server/client communication?

Joe_Pluta: There's no need to use sockets, because the Web portion of the application (the servlet) and the host portion of the application (the RPG) reside on the same machine. Therefore, you can use any of a number of inter-program communication methods, including data queues, JDBC procedure calls and direct program calls from Java. Personally, I prefer to directly call an RPG API from Java, and for queuing I use data queues because they are easy to manage and use.

scott.pepperdine7606: What is the API you mention for replacing EXFMT in legacy code? I'd like to look into it. We need to continue to support green screens while desiring Web presence.

Joe_Pluta: The API I use to replace EXFMT is one I designed. The API is very simple. The display file proxy object that supports it is a little more complex, but it's nothing mysterious. I simply designed an object that emulates the functions of the display file. For a simple display format, it's really pretty simple. The interesting part is supporting subfiles and message subfiles.

rhealey835210: Do you recommend not using java for database I/O because of performance or, in the interest of not completely rewriting business logic already in existing RPG programs?

Joe_Pluta: Well, as I mentioned earlier, Java is not designed for business processing. Performance is definitely an issue, but you bring up a great point, which was actually the main driving force behind the creation of the revitalization architecture: you probably already have all the business logic you need, already written in RPG! Why lose all of that? Why rewrite it? If this were 1998 and you still had the Y2K problem in front of you, I might suggest thinking about a rewrite, but now? Now your code is probably in the best shape it's been in for years, and you ought to take advantage of that. With revitalization, you leave working code in place and only rewrite those portions that really need to be rewritten.

casey_r74405: Along the lines of encapsulating all database I/O in RPG or Cobol servers -- do you see stored procedures (either SQL or HLL) being useful?

Joe_Pluta: Great question. More and more I'm finding that stored procedures, especially HLL stored procedures, may well be a more "portable" option than my personal preference, using the Java Toolbox to call an RPG API. I'm just beginning to determine where stored procedures, or at least the JDBC ProcedureCall concept, may have a place in a distributed architecture. However, the "standard" stored procedure concept of returning a result set is not something I'll use, since at the core of my architecture is the ability to return heterogeneous datasets, where each row might have a different format.

casey_r74405: Server/client uses the "screen contents" (your display file proxy) as the information to pass between the HLL server and the servlet/JSP or Swing UI. Do you see that as a limiting factor when you move to redoing the business logic?

Joe_Pluta: I've spent considerable time with this question. I've come up with a three-step strategy. First, use revitalization to put a GUI interface on your existing application. A side benefit of this approach, though, is that what you?ve done is basically provide a message-based interface to your applications. The next step is to encapsulate those interfaces into business application "macros". For example, a relatively simple program could reformat an XML document describing an order into the appropriate messages for the order entry program. This now creates an XML interface. The final step is to write a true client/server application to directly process the XML document. With this process, you can rewrite your applications one step at a time, with minimal disruption to your users, and taking as much advantage of your legacy programs -- and legacy programmers! -- as possible.