The iSeries: The Once and Future King

[J.Pluta]

The iSeries: The Once and Future King

Up early? HAH! With a 13-month old, this is late . Actually, not really, but he's battling an infection so he's a bit distraught these last few days. I feel a lot is getting lost in the translation here, Duncan. An IDE is different from a code generator, as I hope I've made clear. IDE = GOOD, CODE GENERATOR = BAD. As to the debugging, with WDSC I can put a breakpoint right in the JSP. Can't do that with RPG-CGI. Maybe with your tool, but I continue to firmly insist that vendor tools are not part of this discussion. Joe

[J.Pluta]

The iSeries: The Once and Future King

Okay, now we're going to get into some disagreement, Duncan. Let's start... I'd have such a device even if I was serving pages from a Unix box using JSP or PHP or whatever. But the point is that you CANNOT have a firewall device when running RPG-CGI unless that firewall is another iSeries. CGI Web page requests come in and out of these jobs as necessary, with the helper job queuing up requests if the number of simultaneous requests exceeds the number of currently available open jobs. So it is not correct to say that a new job is opened up every time a page request comes in. You can optimize the number of open jobs when you start the web server instance. We usually have just 5 running, and that serves us fine (pun intended) - although we probably don't have as much traffic as many of our clients. However, they usually find that 10 jobs at the most is adequate. Okay, I'll need more education here. I have 20 people doing order entry simultaneously. They all need persistent connections, since this is an order entry application with lots of temporary data. How many CGI jobs do I need for this? If I only need five, where is the persistent session data stored? How is it saved? How is it restored? How do you keep files open between calls? We literally have many clients running AS/400 270's as web servers - something that is impossible from a practical standpoint with WebSphere (although, admittedly, Tomcat isn't so resource-intensive)! Okay, now you're simply incorrect. Feel free to go to http://www.plutbrothers.com at any time. This website runs entirely on a TINY little 370 CPW model 270, and was built completely using nothing but WDSC. There are lots of people running WebSphere on a model 270. I don't know where you get your information, but it's way wrong. We've also written a program called 'loadtester' that automatically submits x number of real requests for a given CGI program (it's not something we distribute without extreme discretion, because in the wrong hands it could be used for DOS attacks). I use a product called Web Roller. Wonderful product, lets you build scripts, even use data sent to you in your response (really important for session testing). Again, though, we need to be sure what the jobs are doing. That's why I try to separate online transaction processing programs from data query. I'm still waiting to see how you get 20 persistent session from 5 jobs. while there may be more 'standards' for JSP, I doubt one would write JSP's without some sort of development tool from a third-party vendor. It depends on what you mean by tool. An IDE such as the JDT in WDSC is fine (and indeed, almost mandatory). A code generator such as the web service wizard in WDSC is not acceptable, because I wouldn't use the generated code in production. I believe in IDEs, I do not believe in code generators. One of the points someone else made in this discussion was about 'build or buy'. I have always been an advocate of leveraging our developer's intelligence by minimizing the hand-coding they have to do and making them as productive as possible. I'm sure you'd feel the same way, Joe. It depends. I absolutely abhor using application code generated by a "wizard" or a "4GL". I prefer that developers become productive by writing code once and encapsulating it, using the many capabilities of OS/400 to do so, such as data queues, batch jobs, service programs, and the like. One of the reasons Java has not yet met its potential (and believe me, I'd love it to - I love the idea of write once, run anywhere) - is that the reality is: write once, test everywhere - JVM's are just not consistent. This was one of the major reasons Java applets failed for general business use. I absolutely disagree. JVMs are completely consistent. Please name an instance where, for example, Sun's JDK1.4 differs from IBM's JDK 1.4. Application servers tend to differ, which is why you need to be careful not to use vendor extensions, but that's pretty easy to do. Programs converted by PSC/400 run under Tomcat just as well as they do under WebSphere. I feel strongly that many writers (and not just you, Joe) have been overly enamored with the WebSphere /Java technological superiority argument that IBM has so successfully marketed to the detriment of their readership. A considered examination of the alternative SOLUTIONS (not 'technologies') provided by vendors such as BCD by respected names in the industry such as yourself would enhance the image of the i5, IBM, the vendors in this marketplace, and all of us - developers and users- who believe so strongly in the superiority of the i5 hardware/software platform over Unix and Wintel. Duncan, if you'd like to continue this conversation, you need to quickly dial down the rhetoric. I am not "overly enamored" of Java, I am an advocate of JSP Model II as the best browser interface for the iSeries. IBM did not market this technology to me, Sun did. I've been coding Java for nearly 10 years now, long before IBM got into the game. In fact, I taught this architecture TO IBM in Israel around the turn of the century. So, I'd really appreciate it if you give me a little more respect than calling me an "enamored writer". As to the superiority of the IBM platform, did you even read the article? Have you read anything I've ever written? I am perhaps the most ardent advocate of the iSeries writing today. Not only that, I am stridently opposed to converting RPG code to Java, and I insist that RPG is the best language available for writing business logic. It is, however, less suited to static problem sets like HTML generation. OO languages flourish in environments where the rules rarely change; that's where you can really take advantage of the rigid typing and hierarchical nature of Java. Anyway, you've made some points, but some have started to veer away from the technical and into the realm of opinions. And of course, you've continued to mention WebSmart, which is not the focus of this discussion. I'll wait for our specific technical answers to my comments, though, and see if we can keep this conversation on topic. Joe

[D.Kenzie]

The iSeries: The Once and Future King

Wow! Joe! You are up early! It must be 5 am your time. And, I notice you mention WDSc - so in this case you are referring to the TOOL you use, not really JSP per se (which can be written by hand - like RPG-CGI a la CGIDEV2). And - debugging is possible with RPG-CGI, too (from green-screen, even!) And - some tools do have debugging facilities! (ok - that's 4 responses). Duncan

[D.Kenzie]

The iSeries: The Once and Future King

Ralph, Sorry I haven't answered directly - please read my post in response to Joe's comments for a description of our experiences with CGI, and a technical outline of how CGI jobs are handled. Duncan

[D.Kenzie]

The iSeries: The Once and Future King

Ralph, I've written a post later on in response to Joe that discusses the scaleability debate over CGI. It describes technically how the web server works. It's not quite accurate to say a new job is spawned every time - I explain why there. Regards, Duncan

[D.Kenzie]

The iSeries: The Once and Future King

I suppose we could keep going back and forth like this for quite a while. I'd just like to address your last set of comments. 1. I understand your initial comparison was RPG-CGI to JSP, and not product-specific. I don't want to drag WebSmart into the discussion, either - Chuck is already a great advocate of it, and has noted it generates CGI-protocol compliant as well as JSP-based applications. I do hope, however, that you will take the opportunity to look at WebSmart some time. I'm pleased to see you've looked at Nathan Andelin's work. It would be nice, as an industry expert, for you to take a detailed look at a more prominent product in the marketplace (if you've already done so, my apologies). I was trying to expand the discussion somewhat by referring to 'ILE CGI' versus 'RPG CGI' - for reasons I've already mentioned. However, I'm willing to confine my responses to your original playing field. Security: I agree with you (as you can see from an earlier post I wrote before reading your last one) that a dedicated firewall/web applicance is useful. I don't see how this affects running JSP versus CGI though - I'd have such a device even if I was serving pages from a Unix box using JSP or PHP or whatever. Scaleability: First, it is not quite accurate to say each CGI requires a new job. And, Ralph- you might want to read this- this answers some of your questions too. The web server (Apache or Original) has a main helper job that farms off requests to other jobs running in the HTTP subsystem. These other jobs behave like Unix daemons - they remain open for as long as the subsystem is running. CGI Web page requests come in and out of these jobs as necessary, with the helper job queuing up requests if the number of simultaneous requests exceeds the number of currently available open jobs. So it is not correct to say that a new job is opened up every time a page request comes in. You can optimize the number of open jobs when you start the web server instance. We usually have just 5 running, and that serves us fine (pun intended) - although we probably don't have as much traffic as many of our clients. However, they usually find that 10 jobs at the most is adequate. These are 'passive' jobs - meaning they take up no processor resources unless something is actually running in them. So 10 jobs can serve literally thousands of requests an hour. Because of the demands of WebSphere, and because of IBM's marketing push of WebSphere (until recently!) IBM has done a good job of keeping quiet about just how successful their HTTP/CGI team has been at getting incredible performance with miminal impact on system resources. We literally have many clients running AS/400 270's as web servers - something that is impossible from a practical standpoint with WebSphere (although, admittedly, Tomcat isn't so resource-intensive)! While it is true that Java pages are threaded, there is incredible initial overhead to load the WebSphere web server in order to provide the benefits of threading. If we are talking about huge enterprise-level i5's, this initial overhead is probably (I'm guessing here) not significant. But for most SMB's (or small departments of large corps) with small AS/400's -iSeries-i5's the overhead is completely impractical. Just go through IBM's hardware sizing wizard and look at their recommendations for WebSphere to see what I mean. I realize this may not be the case on other platforms (or web servers, such as Tomcat), but I think we all agree that the benefits of the i5 far outweigh the benefits of other platforms - at least that's the context for my thinking and my business model. We've also written a program called 'loadtester' that automatically submits x number of real requests for a given CGI program (it's not something we distribute without extreme discretion, because in the wrong hands it could be used for DOS attacks). We use it to simulate thousands of users hitting a web site, at varying intervals (which we can set). We've done this for skeptical clients who don't believe our claims of scaleability. In every case, both we and the client have been pleasantly surprised. I don't believe we've ever had a case where someone said the results of the simulation indicated inadequate performance. Flexibility: while there may be more 'standards' for JSP, I doubt one would write JSP's without some sort of development tool from a third-party vendor. One of the points someone else made in this discussion was about 'build or buy'. I have always been an advocate of leveraging our developer's intelligence by minimizing the hand-coding they have to do and making them as productive as possible. I'm sure you'd feel the same way, Joe. In which case- your point is really about availability of information on JSP versus CGI, not technological superiority. The term 'standards' is also open to interpretation. One of the reasons Java has not yet met its potential (and believe me, I'd love it to - I love the idea of write once, run anywhere) - is that the reality is: write once, test everywhere - JVM's are just not consistent. This was one of the major reasons Java applets failed for general business use. BTW- I am not a fan of CGIDEV/2. I think it encourages inconsistent coding practices and cultivates a 'let's just code it by hand' mentality that flies in the face of modern application development practise and modern law (SOX). It's fine as a primer on the subject, but woefully inadequate as the basis for a robust, controlled development environment. A couple of other points - I believe 'server side includes' are a web server construct, not dependent on the underlying CGI implementation. In other words, you embed a 'standard' tag for SSI in your script that the web server either recognizes or doesn't (depending on whether you've turned on support for SSI). I don't like SSI's at the web server level simply because it slows performance - the web server has to parse all the HTML before delivering to the client in order to determine if an embedded SSI directive exists that must be executed. A better approach is to use 'standard' i5 API calls to IFS routines to include files. Again, many people have written and published such routines for the iSeries etc. Cost: I think you've helped make my point here. Many small AS/400s (270's etc.) can run CGI no problem. They cannot run JSP. That latter fact doesn't seem a compelling reason to me to try to run a Unix web server. Again, this is a TCO argument. We may have problems getting developers to learn Java, but it's probably nothing compared to the headaches of getting AS/400 Sysops to run Unix boxes! Java does run better on PC's than AS/400's - but Java on PC's does not run better than CGI on AS/400's- taking into account AS/400 security, reliability, ya di ya di ya... One last point on this statement: "but more importantly BCD advertises with MCPress and I'd rather not try to find fault with an advertiser. " I'd like to go on record as saying that the AS/400 press in general has assiduously avoided favoritism towards vendors based on their advertising arrangements. I think this is a testimony to the integrity of the various publications. Ironically, it is often a source of great frustration to our marketing team that this is so. We receive no special favors even though we spend considerable amounts of money with several publications. However, perhaps a more legitimate source of frustration is the apparent lack of willingness on the part of some members of the press and editorial teams to objectively and comprehensively examine the offerings of third party vendors. We have often encouraged senior editorial staff to contact us to have objective, technical reviews of our products. I feel strongly that many writers (and not just you, Joe) have been overly enamored with the WebSphere /Java technological superiority argument that IBM has so successfully marketed to the detriment of their readership. A considered examination of the alternative SOLUTIONS (not 'technologies') provided by vendors such as BCD by respected names in the industry such as yourself would enhance the image of the i5, IBM, the vendors in this marketplace, and all of us - developers and users- who believe so strongly in the superiority of the i5 hardware/software platform over Unix and Wintel. Regards, Duncan

[J.Pluta]

The iSeries: The Once and Future King

Duncan, I went through in great detail why JSP is better than RPG-CGI. It can be moved off the machine, it uses a standard tag set, and so on. It does indeed provide several clear technological advantages. As to your asertion that generally the development methodology is much easier with CGI, that's simply not true. With WDSC I can test the entire JSP -- includign setting breakpoints in the JSP itself! -- on my PC. Try that with RPG-CGI! Joe

[D.Kenzie]

The iSeries: The Once and Future King

Joe, What you have described, in terms of the JSP model vs CGI, does not provide any clear technological distinction or advantage. CGI on the iSeries does exactly what you describe JSP as doing- it's just that. generally, the development methodology is much easier with CGI. I'm glad to see you state 'you believe' - that's a much fairer statement than asserting your claims as fact. Duncan

[J.Pluta]

The iSeries: The Once and Future King

By the way, in case I wasn't clear about this, JSP Model II is the sderver-side technology used to both generate a browser UI and handle user responses. The browser renders the data sent to it, which is generated by the JSP. In my simple world, the data to be rendered consists of HTML, CSS and JavaScript, along with the occasional image. That being said, I believe JSP Model II is architecturally superior to RPG-CGI, for the reasons I've stated. Joe

[J.Pluta]

The iSeries: The Once and Future King

Sure, it will deny service of legitimate web accesses mixed in there, but the job allocation for servicing sockets ports should just dwindle until the attack dissipates. What makes you think this, Ralph? What feature in the operating system controls this "dwindle factor"? The only thing I know of for sure is that when a job hits timeslice end it will be knocked down a microstep in priority, but this isn't a regular job in a CPU loop. This is the overhead associated with lots and lots of hardware interrupts. Interrupts tend to run at a very high system priority (it's the nature of interrupt processing) and so an overflow of spurious interrupts can indeed shut down processing of any machine. Joe

[R.Daugherty]

The iSeries: The Once and Future King

I don't think there's anything to find fault with in any event. But that aside, does CGI require the memory of Java for JSP? No, we all know it could be written in C as far as that goes. The job overhead? I have a pending question about that, but I thought I saw many moons ago something about CGI job overhead being taken care of by IBM. I don't know. That's why I'm asking. But it's hard to believe that a job is still spawned for CGI to create a web page, unless IBM just deliberately wants to cripple non-Java Websphere SQL solutions, which I wouldn't put past the dudes in Armonk. We all know the Sys/3X only exists as it is because Rochester told Armonk they were building an accounting machine. As for DoS, it would seem to me to be brain dead to have socket code that is allowed to tie up the AS/400 responding to DoS attacks. Sure, it will deny service of legitimate web accesses mixed in there, but the job allocation for servicing sockets ports should just dwindle until the attack dissipates. I do understand the "we don't want our crown jewell exposed to the internet" thinking, sorta, as far as port 80 goes I guess is what they have in mind. Still, it should be a smaller AS/400 with DDM communications to the crown jewell AS/400's, although only an OS/400 knowledgeable person will believe that. I think PC's are used because web people in most corporations are not AS/400 people and they require their OS to run on a PC, not because the PC is cheap. That's just an excuse that justifies corporate behavior in deference to their web people who don't give a rat's behind for the AS/400 and how OS/400 can kick their butts six ways to Sunday. For that matter, IBM doesn't have a clue about it either. Just look at their i5 ads. They really think they're going to sell i5's to consolidate those cheap PC's from those people I was talking about. Give me a break. It's integration within OS/400, not outside of OS/400, that sells the AS/400. But only Rochester would know that. rd

The iSeries: The Once and Future King

Joe, I only respond in kind. It's a little late to jab and then walk out of the room claiming you don't like return jabs. chuck Opinions expressed are not necessarily those of my employer. "Joe Pluta" wrote in message news:6b229b3b.61@WebX.WawyahGHajS... > This sort of provocation is why I chose to leave the conversation. > However, Duncan raises some points which I was unable to address, as I had > a sick baby on my hands. Now that he's down hopefully for a bit of a nap, > I can respond. > > After this latest personal attack, however, I shall ignore your posts, > Chuck. > > Joe

The iSeries: The Once and Future King

Joe said: "Why is a cheap PC dumb? Offloading web serving tasks to a PC is exactly equivalent to offloading I/O tasks to an IOP." Not exactly, I've never had an IOP fail in 30 years of using IBM midrange. Can't say that about a PC. However on the Power 6 this will be a moot point as Frank Soltis claimed at Spring COMMON that IOPs will go away in the Power 6 version of iSeries. chuck Opinions expressed are not necessarily those of my employer.

[J.Pluta]

The iSeries: The Once and Future King

Okay, I have an opportunity to respond, and hopefully I can do it as professionally as you, Duncan. First off, though, I want to be sure what we're takling about here. We're talking about RPG-CGI out of the box vs. JSP Model II to an RPG bakc end. In no way am I implying anything about BCD WebSmart. I submit that there are vendors who have managed to get RPG-CGI to work quite well; Nathan Andelin does some stuff that's just incredible. At the same time, people like Paul Holm have done incredible things with the JSP Model II approach. I was trying to compare technologies, and the conversation kept getting dragged to WebSmart, which is NOT a technology, it is a vendor tool. If you disagree on that point, please stop reading here, because i guarantee we will be unable to reach consensus on anything else. If, however, you are willing to grant that comparing JSP Model II and RPG-CGI is an exercise worth further discussion, then please continue. Security: I hope I've explained that point above. With a dedicated web appliance front end, be it Unix or Windows, you open ZERO potrs from your iSeries to the Internet. This is better from a security purist standpoint because even one open port can be sbujected to a DoS attack, thereby affecting the operation of your production machine. There are ways to limit this, of course, but it's simply one less hole. Does that make sense? If you wanted to get REALLY twisted about it, you could write your own SNA routines and not have any TCP/IP connectivity at all, but that's probably overkill . Scalability: Each RPG-CGI session requires a job. Each Java thread does not. Now, if you create a sufficiently thin RPG-CGI layer, much like the way I talk about a JSP Model II veneer, then you can conceivably avoid many of the issues. However, most CGI deployments I've seen basically have a big old program responding to each HTTP request. This is another reason I avoid the discussion of tools like WebSmart. Since I don't know the tool that well, I don't know how they've engineered their infrastructure. But even if they've done it well, the fact that one vendor has such an infrastructure doesn't mean that RPG-CGI programs in general are scalable. So in the end, all I'm saying is that I think threads are more scalable than jobs, and the folks I've talked to at IBM tend to agree. Flexibility: I wasn't rigorous enough here. There are three ways to create CGI output. You can format and write your stream yourself, you can use a template language such as CGIDEV2 or you can use a vendor tool. Leaving the vendor tool out, that means that you must either build your own infrastructure for doing things like includes, or you have to rely on the tags in the CGIDEV library. Either one is more than what is required with JSP Model II. JSP Model II already has all of those features in place in a standard, well-known format. There are even external tag libraries that can simplify many tasks, although I personally don't like them (but that definitely is a presonal bias). In any event, the point is that there is no standard tag language for RPG-CGI to perform standard UI generation tasks such as server side includes and dynamic data access. Is that clear? Cost: A cheap Unix box is an excellent choice for people with small AS/400s (not iSeries!) who either cannot afford 1GB of AS/400 memory or who are simply running on older machines that don't handle Java well. In these cases, RPG-CGI may run better, I don't know. But I have no problem offloading web serving to a dedicated machine, especially when security is an issue (see above). People always complain about how Java runs better on their PC than on the iSeries; here's a way to take advantage of that! Anyway, I hope I've made my position clear. This is simpyl RPG-CGI vs JSP Model II, and completely divorced from vendor tools, mine or anyone else's. It's quite possible that WebSmart has addressed these and many other issues, but frankly I cannot in good conscience get into that discussion. At the fringes we compete (really we don't; my clients and BCDs have clearly different requirements sets), but more importantly BCD advertises with MCPress and I'd rather not try to find fault with an advertiser. Thanks again for a cogent and reasoned discussion, Duncan! Joe

[J.Pluta]

The iSeries: The Once and Future King

Why is a cheap PC dumb? Offloading web serving tasks to a PC is exactly equivalent to offloading I/O tasks to an IOP. Since all it is doing is presenting the web interface, and not serving any critical data, it's a perfect solution for some situations. Personally, I dno't think its optimal, but I have one client using a FreeBSD box to serve pages using data from an AS/400 and they're quite happy. Joe