web to 400 communicaiton methods
Man, I am getting tired of seeing this crap. Time to debunk it once and for all. I was suggesting HTTP as a faster, cleaner, easier means of messaging from IIS to the AS/400 to process data in real time from the web page in IIS, with no tradeoffs to weigh against other than scorn from the messaging gurus. Complete rubbish. The HTML data stream is NOT a faster, cleaner method of messaging, and the tradeoffs are immense. The tradeoff is in the fact that you have to have an HTTP server instance, a web server and a CGI program suite (such as the Strategi stuff that you "don't sell") all running on your AS/400 instead of a simple API call to a server. And the Strategi crap is actually third-party extra-cost software, while messaging COMES FREE with the AS/400. It is not cleaner, because you have to parse the outbound HTML stream from the AS/400 to the NT box, and that is not a trivial feat. In fact, it can be all but impossible, and it's obvious that you haven't really done it, Ralph, or you'd know that. I have a thing against Rube Goldberg layers of technologies, and if the others haven't had their eyes glaze over reading a laundry list of technologies that are recommended to serve web pages, then maybe I'm the only one who noticed... but I doubt it. Rube Goldberg? What in the WORLD do you call that contraption you're foisting on us? Let's see if I get this straight... end user to browser to to Microsoft IIS to NT CGI program to HTTP to IBM HTTP server to Strategi web server to RPG program (to generated HTML to NT CGI to generated HTML to browser to end user)... how many layers is that, Ralph? Any consultant who came to me with a solution like that would be let go immediately. Not even a question asked. Instead, end user to browser to web server to servlet to RPG to JavaServer Page to browser to end user. Cleaner, quicker, with complete separation of design and business logic. For user interface, somebody designs the screens in HTML, then we make the following modifications: This: changes to: <%= dataBean.getFormattedField("Field") %> That's pretty much the extent of the changes. In fact, I have a hard time understanding how the CGI program in your incredibly convoluted design approach is able to get the data from the AS/400 out to the end user; the initial value of a field is imbedded in the actual HTML script, so would have to be passed to the CGI program PRIOR to it being invoked... and how do you do that? It's easy to get data from the user, but much harder to actually intialize the values in those entry fields; that means when the user initially calls a URL, the URL has to invoke a different page on the AS/400, which in turn has to invoke an RPG program, which spits out data as fields on the screen, with the syntax I mentioned above ( maxlength=256>). Then, the CGI program on the NT has to read that screen, find the "INPUT" label in the HTML stream, and parse out the data (welcome to the world of HTML, Ralph). This is why XML was devised as a means of computer-to-computer communication. You see, it's much too hard for a computer to parse out the information content in a web page. The parsing I just told you is a perfect example. There is no clean way to identify each of the "fields" in an HTML stream. This method of "wrappering" one website over another is very difficult and highly dependent upon the coding used. Even more difficult, if the data is only meant to be displayed to the end user, you can't even tell where one field starts and another ends, because the data is just embedded in the HTML stream: Customer Name: My Customer How do you tell the NT program how to find the customer name? Do you scan on "Customer Name:" and then skip one space, then read until a ? What if the HTML designer (who should be completely independent of the process, right, Ralph?) changes it to "Name of Customer:", or even more subtle, changes the to a ? Or adds another space? Or changes the ":" to a "-"? So, Ralph, if you're continuing to insist that you can write an HTML application that runs on the AS/400 (using the Strategi system that you "do not sell"), and then another application that runs on the NT machine, and then "map" the two of them together, I say it might work for a simple prototype but will immediately die when you try to scale it up to anything industrial strength. It's a bad solution and a bad architecture. There. I've stopped mincing words. Joe
src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit
Man, I am getting tired of seeing this crap. Time to debunk it once and for all. I was suggesting HTTP as a faster, cleaner, easier means of messaging from IIS to the AS/400 to process data in real time from the web page in IIS, with no tradeoffs to weigh against other than scorn from the messaging gurus. Complete rubbish. The HTML data stream is NOT a faster, cleaner method of messaging, and the tradeoffs are immense. The tradeoff is in the fact that you have to have an HTTP server instance, a web server and a CGI program suite (such as the Strategi stuff that you "don't sell") all running on your AS/400 instead of a simple API call to a server. And the Strategi crap is actually third-party extra-cost software, while messaging COMES FREE with the AS/400. It is not cleaner, because you have to parse the outbound HTML stream from the AS/400 to the NT box, and that is not a trivial feat. In fact, it can be all but impossible, and it's obvious that you haven't really done it, Ralph, or you'd know that. I have a thing against Rube Goldberg layers of technologies, and if the others haven't had their eyes glaze over reading a laundry list of technologies that are recommended to serve web pages, then maybe I'm the only one who noticed... but I doubt it. Rube Goldberg? What in the WORLD do you call that contraption you're foisting on us? Let's see if I get this straight... end user to browser to to Microsoft IIS to NT CGI program to HTTP to IBM HTTP server to Strategi web server to RPG program (to generated HTML to NT CGI to generated HTML to browser to end user)... how many layers is that, Ralph? Any consultant who came to me with a solution like that would be let go immediately. Not even a question asked. Instead, end user to browser to web server to servlet to RPG to JavaServer Page to browser to end user. Cleaner, quicker, with complete separation of design and business logic. For user interface, somebody designs the screens in HTML, then we make the following modifications: This: changes to: <%= dataBean.getFormattedField("Field") %> That's pretty much the extent of the changes. In fact, I have a hard time understanding how the CGI program in your incredibly convoluted design approach is able to get the data from the AS/400 out to the end user; the initial value of a field is imbedded in the actual HTML script, so would have to be passed to the CGI program PRIOR to it being invoked... and how do you do that? It's easy to get data from the user, but much harder to actually intialize the values in those entry fields; that means when the user initially calls a URL, the URL has to invoke a different page on the AS/400, which in turn has to invoke an RPG program, which spits out data as fields on the screen, with the syntax I mentioned above ( maxlength=256>). Then, the CGI program on the NT has to read that screen, find the "INPUT" label in the HTML stream, and parse out the data (welcome to the world of HTML, Ralph). This is why XML was devised as a means of computer-to-computer communication. You see, it's much too hard for a computer to parse out the information content in a web page. The parsing I just told you is a perfect example. There is no clean way to identify each of the "fields" in an HTML stream. This method of "wrappering" one website over another is very difficult and highly dependent upon the coding used. Even more difficult, if the data is only meant to be displayed to the end user, you can't even tell where one field starts and another ends, because the data is just embedded in the HTML stream: Customer Name: My Customer How do you tell the NT program how to find the customer name? Do you scan on "Customer Name:" and then skip one space, then read until a ? What if the HTML designer (who should be completely independent of the process, right, Ralph?) changes it to "Name of Customer:", or even more subtle, changes the to a ? Or adds another space? Or changes the ":" to a "-"? So, Ralph, if you're continuing to insist that you can write an HTML application that runs on the AS/400 (using the Strategi system that you "do not sell"), and then another application that runs on the NT machine, and then "map" the two of them together, I say it might work for a simple prototype but will immediately die when you try to scale it up to anything industrial strength. It's a bad solution and a bad architecture. There. I've stopped mincing words. Joe
Comment