Application Server Architectures

[Guest.Visitor]

One time in an attempt to show that the as/400 could do web stuff I put up a small application at http://area781.com click on "A pretty face for the AS/400" Moving beyond the 5250 Green Screen. All the links on this page are hosted on an AS/400. Although it shows the AS/400 can do web pages natively, the response to date has been very very low. Perhaps it's the 10x cost factor for the AS/400. Regards, Tom Birchmire

[johnfoldager]

First of all I should tell you that I do a lot of web development using one or several of the following technologies (depending on the requirements): Lotus Notes/Domino, Java, ILE RPG, JavaScript (Ajax etc.), XML etc. This article is great because it tells us some of the different technologies we can use to create web solutions, but all of these articles often just scratches the surface of solutions and technologies available to us. I have already mentioned Lotus Notes/Domino which can be used for some web solutions which I have (and still do) used for many years. Now I will tell you about another product (please note that I'm not working at the company that created this!) which I don't think that so many people knows exists. It's an application server that uses ILE RPG (fixed- or free-format) or Cobol (for those who uses this) to serve webpages (HTML, XHTML, CSS, JavaScript, XML, etc.). There are several similar application servers that - at first sight - does the same - but this one does it so much faster and does it natively; just as we know from "old" 5250 applications. Thus performance far outperforms CGI and Java just to name a few. To create a HTML webpage (or XML file or the like) you simply create your RPG business logic, and mix it with the HTML tags then you call the program using a URL in your favorite browser. The application server can see that you have changed the source (which is located in the IFS) and then compiles the program and displays the result to you. You can use your existing RPG skills and just learn a few specific built-in commands to server content for the web. The application server is very cheap compared to other application servers and extremely fast to get jobs done because you already know the RPG language. Just mix it with the content (HTML, XML etc.) and you're done. You can read more about the application server which is called IceBreak at http://www.icebreak.org . You can even try to create a program on that site and have it compiled to show the result. If you have any questions about this application server you can contact the vendor from the link above or respond to this thread and I will try to answer any questions you might have about it.

[R.Daugherty]

Hi Tom, I saw on the other AS/400 site an article that iseries spec'd to run OneWorld at $20,000. The sales/marketing people quoted make an argument that it is inclusive while other solutions are just a start. I will agree with IBM on this. They don't include 5250 interactive processing, but it does serve up the web pages. (At least I assume many of OneWorld's point solutions are browser based.) And not only is it not 10x Wintel, the iseries system i is a better deal to run your business on than Wintel. Does that mean companies will do it? Not when an IT staff would have to get out of their comfort level. Probably only way that changes is when companies running their business on the AS/400 win out because of it. But believe it or not, I've seen several large companies grow large enough on the AS/400 to buy out competitors and then try to trash the horse they rode in on to go to Unix or the like. I hope to see a swing back when they check out the color of the grass on the other side. rd

[J.Pluta]

I think this is part of a much bigger issue, Tom. Saying there is a 10X cost factor implies that the Windows system is actually equivalent to the iSeries, and it's not. There are two kinds of programming in the world. Actually there are three, if you count the extraordinarily talented folks like Barbara Morris and Hans Boldt who design languages and develop compilers. But if you stay down at the level of us mere mortals, there are really two kinds of development: 1. Application logic development. This is stuff like ERP systems, market forecasting, banking, and so on. It requires the ability to design databases and to write logic that applies logical transformations to user input to create new data. My classic example is an MRP generation, which takes orders and inventory and bills of materials and so on and forecasts the demand for materials. It doesn't have to be quite so complex, of course; another example could be as simple as checking a grade history database and flagging those students whose grade point averages have steadily dropped for the last several grading periods. Note that this is barely one step above a simple SQL statement (and in fact, a really good SQL developer could probably come up with a way to do it). 2. Inquiry applications. Inquiry applications are those things that get the already processed data and present it to the user. They may allow limited interactivity, such as drill downs and so on, and maybe even maintenance to individual records, but they don't actually perform any business logic. This is the domain of SQL and Visual Basic. Note how SQL falls into both places. Well-written SQL is as much a part of a good enterprise application suite as anything else. But simple queries dumped to an Excel spreadsheet is not programming. However, it is something that just about anybody can do these days with the toolsets available. And that's where I'm going with this long-winded diatribe. If there are tools that allow people to generate pretty graphs, they don't really care where the data came from. But they want to use them. Today those tools only exist, for the most part, on Windows systems, and if you need such functionality, I say by all means use Windows (of course you could use Java and be platform independent, but that's a different discussion). So, inquiry applications is where Windows excels (no pun intended). There are also "enterprise-like" systems that run on Windows, such as those based on SQL server. These do NOT run better than applications on the iSeries, and once you factor in the costs of disk and licenses and redundancy and support, they don't even match in price. Thus it makes perfect sense to have your business application logic (and data) on an iSeries, and then different interfaces to that data and logic: browser, terminal, thick client, cell phone, you name it. But what often happens is that the two types of applications get confused, or worse yet, the person managing the IT budget decides they don't want the "complexity" of two types of systems, so they figure they may as well run everything on Windows, TCO be damned. Of course, this is silly. That would be like a general contractor who likes driving a Corvette to and from work deciding to use a fleet of them for delivering building supplies. Two completely different jobs, which require two completely different solutions. And of course the vast majority of companies who make the data inquiry tools aren't going to jump up and tell their clients that. Instead they sell their tools as "application development suites", and leave the actual data entry and manipulation--the hard part of enterprise programming--out of the conversation ("Pay no attention to the man behind the curtain!"). The client gets a great inquiry tool and then has to figure out some way to get data into their database, and they end up with some frightening mishmash of off-the-shelf code and Visual Basic running their business. What we need to do is to re-educate the end users and the decision makers that there are two kinds of systems: the ones that allow you to input, process and transform your data, and the systems that present that transformed data. For business systems, you definitely want the former on something that has a high reliability and low cost of TCO and easy scalability (e.g., an iSeries). What you build you inquiry applications on is then up to you. If your users want to dump data into spreadsheets, they can access your data through stored procedures and so on and pull the data into Excel. Or, if you want mission critical access, you might have a browser interface run from the server or (Heaven help us!) a green screen. But until we definitively split those two workloads and make it politically acceptable to use different tools for those two jobs, we're going to continue to see a LOT of Windows machines with their bumpers dragging on the pavement, if you followed my badly mixed metaphor . Joe

[Thomas Birchmire]

An interested reader sent me a question about "a pretty face" and my reply is below. Although the AS/400 remains my favorite machine, I make my living doing web pages using php, CSS, javascript, and MySQL along with a lot of Photoshop. In short nothing I do today resembles an AS/400. Sometimes the operating system is some flavor of WinXX and sometimes it's Linux/Unix. I moved away from the Java/JSP/Bean world because I refused to learn the 100,000 classes and 1,000,000 methods it all seemed to be moving to. Now the buzz is Ruby and Rails but until someone wants to pay me money to program in it, I'll ignore that too. Regards, Tom Birchmire

Hi, Essentially, my test AS/400 has been set up to process cgi programs. If the request has no .mbr or .pgm the IFS (the dark side of the as/400) system dumps out some html code and jpgs. (The web page) If the cgi request ends in .mbr then the contents of a source member is returned to the web. If the cgi request ends in .pgm then the ile-rpg program is executed and the html code is processed and returned to the web. As you can see the code returned is almost the same in all three cases. The above oversimplifies things a little but I liked the method because it allowed me use my knowledge of rpg-ile and the native db2 database.

An interesting tutorial can be found at

http://www.web400.com/download/RPGCGI/RPGCGI.htm

After fooling around with the three methods, I saw that the AS/400 was quite capable of web stuff and it didn't need Websphere and Java to do it. This method may have come from IBM but it wasn't supported and the party line was "Java is the answer". Regards, Tom Birchmire

[R.Daugherty]

Do you plan on trying the new PHP being released for the iseries? rd

[Thomas Birchmire]

If my test as/400/iseries supports PHP, I have some scripts I can easily upload and try. I share a timeshare iseries where I can try out various ideas and I haven't asked if PHP will be installed. Perhaps I might have to depend upon the kindness of strangers to let me practice PHP on their iseries if my timeshare doesn't want to install PHP ;-) Regards, Tom Birchmire

[MCWebsite.Staff]

** This thread discusses the Content article: Application Server Architectures **
0

[Guest.Visitor]

What about WinDev/WebDev (PC-SOFT)? It's a good AGL to develop interactives programs. It can access to DB2/400 by ODBC or a native access (developed by EASYCOM). And we can continue to use RPG for the batchs programs. For the two parts,we can use SQL in combination.