First What if any experience does the support staff have in maintaining a GUI application that runs under a browser? I say to each his own. There are lots of ways to make a GUI application. In some shops I’ve seen ColdFusion used very well and in others Java or visual Basic worked well for them. The key here is not only the expierence level but whether the software used allows for good change control management. Dependant on the complexity of the application it is imperative that good change control be an integrated part of the actual panels developed such that you can upload the changes to the server seamlessly and know exactly which version is in use.

The next decision is what will serve up the pages/panels. After trying several different offerings from IBM and others I like the simplicity of a Linux server running apache. Linux is very stable and so is APACHE. In 2004 we created a large application that handles between 40,000 and 65,000 concurrent users. Let me repeat that upwards of 65,000 users at the same time accessing the same server and the same data all with subsecond response time.

In this shop they had very skilled Java programmers and the GUI pages were written in Java with a little visual basic. The whole was designed to run under an apache server and it ran quite well. You will note just about any server under the sun will support an apache server. So this means the appliaction itself can run on just about any server because of APACHE. In this case the APACHE server was run on 2 separate Unix servers in 2 different locations with fall over and load sharing such that it was designed to split the load so that about half the requests were serviced on a server at a time.

All of the requests from both Apache servers connect with only One large AS400/Iseries. The trick here was that requests from the GUI application to the AS400 were all to compiled procedures that were made part of service programs on the AS400. The GUI application is allowed to read files/tables directly on the As400 however anytime the GUI application needs to add or change a record the request is made by calling a procedure on the AS400. This gives full troubleshooting and visibility/control to the As400 side where the data resides. In this particular application we had standard data such as name, address, and account information but also we had over 70 million jpegs of pictures stored on the IFS.

On the AS400 there was one and only one procedure/program per table/file. This meant that all requests to add or change a record in a table came through one and only one program/procedure. We set up variables for the call so that we had parameters for each field in the table plus The name of the calling GUI application, the type of change add/change, date and time stamp, and a 512 byte result field. The procedure did a complete check of the data to be sure all the fields met editing criteria. If all was well then the change or add was made and the first bytes of the result field was returned with “success”. If any of the edits failed like a duplicate was trying to be added or the state field didn’t have a valid state, the result field was returned with “failed” in the first few bytes followed with the name of the failing field and the error message explaining why the update or add failed.

This methodology maintains the veracity of the database files. When multiple updates were requested by the GUI application the GUI application is aware when an expected update didn’t happen and why. We even developed a procedure using commitment control such that unless all of the updates to several files were successful we wouldn’t allow the change to be committed.

By keeping the actual adding and changing of data on the AS400 instead of allowing direct writes from the GUI application you make trouble shooting one heck of a lot easier. In addition before we committed to this methodology we found ways where the gui applications when trying to add or change records wasn’t as consistant at enforcing data rules and the gui application thought it had updated or added a record when in fact the AS400 had not updated or added because of enforced restraints at the field level. Besides who wants to figure out which one of 20 or 30 panels is the offending page that is trying to put bad data in the files.

I know this was long but I thought I’d pass along what worked very well for me. The application I described has now been in Production for 2.5 years and has sucessfully served more than 100 million requests.

http://www.easy400.net/easy400p/main.html

I have not used it, but it may be what you are looking for.

The idea is almost like MicroSoft ASP, and any development tool can be used.

Read more at: http://www.icebreak.org, and try it for yourself, or we can give you a demo.