We have always looked at the building of HTTP interfaces for IBM ‘i’ with a view that they should run on the IBM ‘i’. Our main reason for this was performance, if we are running a web server on a Linux box which has to talk to a web server on the IBM ‘i’ to get related information this would certainly slow things down significantly plus the complexity would certainly take some managing.
We have for a long time said the IBM ‘i’ HTTP server is very slow in comparison to the Linux Server, we did try to install the Sugar CRM package on the IBM ‘i’ but had to give up and move it back to our Linux server because it was simply too slow.. Add to this the complexity PHP brings to the IBM ‘i’ when Zend Core was first introduced and we felt it was a non starter where Application modernization was concerned. Zend Server did change our view a bit, not having to use the PHP server as a proxy was the first improvement, using FastCGI improved not only the complexity involved in setting up the PHP environment but it also lowered the overhead and improved response times. This made us look at using PHP based interfaces for our products again.
Before we take this story further I would also like to point out that we have looked at the Look Software products for providing an interface to our products, the products are certainly first class and do bring a lot of potential to the market in terms of application modernization. Our concern is the cost of the runtime which we would have to impose on our customers if they wanted to use this kind of interface, plus we had to provide our own changes to the screens etc to make it really worthwhile. I still firmly believe the Look Software products are the best way forward for application modernization where you are looking at refacing to start off with and then add more integration with other platforms and servers as you move forward. Their announced support for the new RPG Open Access and availability of handlers is certainly something RPG shops need to consider. However for our products we feel providing a new PHP interface would be the better option, we don’t need to provide cross product integration and we don’t use RPG for our display management. Starting to develop in RPG just to get access to the technology doesn’t seem the right thing to do?
We have been talking around our use of PHP for a long time, in fact our websites and a number of others that we have developed are all PHP based. Our concern has always been with the setup and management of an environment to support PHP on the IBM ‘i’, we have also noticed a number of issues with the new Zend Server on the IBM ‘i’ as well as a number of IBM HTTP problems particularly the slow response times from the *ADMIN servers and the constant need to manage the JAVA environment. So we need to make sure what ever direction we take it is maintainable.
We recently moved our development from a 520 system running with 2GB of memory to a new system running with 4GB of memory. The 2GB system performed more that adequately for the programming and testing of IBM ‘i’ based programs but really struggled to run very well when we turned on the HTTP server and tried to use it with any degree of simulated loading. The new system with 280GB of DASD (15% utilized) and 4GB of memory does start up the HTTP servers a lot quicker and the overall performance of the applications running under HTTP have improved, although to be honest it is not enough. Once you add the PHP server to the mix which we use to interact with IBM ‘i’ programs/objects and the response times certainly leave something to be desired. I expect if I double the memory again things will change but the cost of that is pretty steep, probably a lot more than a new PC server to run a Linux based Web Server even with IBM’s new memory pricing.
This had us thinking about how we could interact with the IBM ‘i’ from a Linux server running PHP, could we supply the programs and data from the IBM ‘i’ and leave the Linux server to manage the HTTP side of the house.
Our first thoughts were to write some kind of client server tool which would correspond from Linux to the IBM ‘i’ passing it onto the Linux HTTP service. This would require us to create a module for the HTTP server (something we have not done so the impact would be quite heavy in terms of learning curve and time to market) which could be bolted in by our customers. It would not have to be too complex because it would only be for our programs. Next we thought about the PHP modules available from EasyCom, after all this is how the i5_Toolkit works on the IBM ‘i’. As it turns out this is the route we took, our initial concern about having two HTTP servers talking to each other raised their ugly heads but after installing the EasyCom solution we found something which came as a big surprise, they do not require the HTTP or PHP server to be running on the IBM ‘i’!
If you are using the i5_Toolkit already you will know that the I5_COMD server has to be running for PHP to service i5_Toolkit requests. It turns out this is the same service which is used for a remote i5_Toolkit request from a Windows or Linux server, it just needs an additional key to enable the functionality. We did ask about how this is installed when Zend is removed from the IBM ‘i’ and it is simply a FTP of a few objects from the Linux server as they are shipped in the Linux package.
Installation of the Linux modules did take some figuring out (the EasyCom manuals are not the best) but one we did and we moved the same code we had used directly on the IBM ‘i’ to the Linux system to test it out, it worked like a charm.
So what is the downside? Well there will be a cost for the runtime! I am not sure what that cost will be as EasyCom has yet to provide me with any indication on that. That could put this in the same position as the LookSoftware proposal, as we do not know either cost we cannot make the comparison. You also lose the db2_ functions from the PHP stack because these are IBM supplied and no Linux or windows variants are available as far as I can find. Having said that our tests using the i5_Toolkit functions performed just as well if not better than using the db2_ functions.
Upside? well first of all you can get away from all the complexity of setting up the webserver on the IBM ‘i’. I have run Zend PHP on the Linux server for over 10 years and it has never folded on me like the IBM ‘i’ installation did recently! It is faster, I ran the very same pages on the Linux system as I used for testing on the IBM ‘i’ and the responses with data were significantly better. A file which had 30,000 records in it came back in probably half the time. I can remove the terrible *ADMIN servers, I don’t need the HTTP servers for anything other than running PHP services, this means I get a lot of the CPU and memory back which was taken up with running the *ADMIN servers. I can entirely remove the Zend Server from the IBM ‘i’, I am not saying the Zend Server is to blame but removing it will simplify the management of the system. I will have access to more support by going for the open source servers than I do with Zend, our IBM ‘i’ Zend support ran out a long time ago and the cost of re-instating it isn’t worth it in our case. Probably one of the biggest gains is I do not have to expose the IBM ‘i’ to the internet if I want to provide a web service which accesses the IBM ‘i’ for data! If you already have a Windows webserver or Linux webserver which is controlled by a specialist group they can integrate the i5 functionality very easily.
I am sure there are a lot more benefits and drawbacks we will encounter as we move forward and we do have a long way to go before we can be certain this is the right option for us, but the initial responses are favorable.
As we find out more information we will post it, if you are interested in looking at how you can build a similar solution let us know and we will be happy to engage.
Call us if you have any questions or wnat to know more about what we have done so far.
Chris…