There is an interesting thread on Perlmonks discussing the problems that J2EE developers feel that they are having, asking is Perl a viable alternative for light weight applications.
There are lots of comments and ideas, including one from me. I don't dislike Java, XML or XSLT, and while I know XML/XSLT, I don't know much about Java or J2EE. I use XML and XSLT with LibXML2 and LibXSLT from Perl, and I can usually get the technology to work, and work reliably. I can't say the same about Java which I usually find doesn't work.
We use a Java middleware thing made by webMethods called the Business Connector (BC), to interface with our backend AIX/SAP system. The idea is that you send it a piece of XML over HTTP, it maps that into an appropriate structure to make a SAP Remote Function Call (RFC), does the call, and maps the result back to XML, which it returns over HTTP to the calling client. While I accept that we made a number of mistakes in using this product, it's still fair to say that it's a very poor piece of technology.
It's pig slow. It takes for ever to parse and return XML. Generating input XML and doing the XSLT on the output XML in the Perl layer is much faster. In this case I even know it's not a problem of hardware, I've testing things on the same box. The problem here is that BC is just very slow.
It's a swine to develop with. All you get is a visual GUI developer tool, which is good in a demo, but a nightmare to actually use. Debugging is a joke, and you have no idea what the thing is doing underneath. I think it's converting it's visual drawings into a sequence of XML transformations, I don't know if it's SAX or some proprietary thing.
So because we had problems we tried Piers Hardings SAP::Rfc module. Basically this is a OO Perl interface to the same SAP provided c library that the BC uses.
I installed it on the DEV box, and after some stupid problem (probably operator error) it started to work. Basically you point the tool at a SAP system, give it the name of an RFC and ask SAP for the interface. SAP does it's stuff, and you get either an error, or a large Perl structure back with the detail of the input and output structures. You then set the parameters you want, and the run the RFC, again you get an error or a Perl structure. You disconnect from SAP and you are done.
It's so simple to use that as I say in my Perlmonks comment I had it running on the command line in less than 15 minutes, and a working HTML in/out page the following day.
Our SAP BASIS team are very opposed to bespoke code, as they think it's wasted development, so they like to stick with standards when ever possible. I can see their point, but with my approach there is less code in total, and thus less bespoke code too. Less code as a general rule means less bugs, and it runs faster. In my (simple) tests Perl+XSLT+SAP::Rfc+SAP is nearly 10 times faster than Perl+XSLT+BC+SAP, I think with the XSLT stage removed I can get my speed up over 10 times faster!
Sometimes this attitude is appropriate. However, my personal experience suggests that more often than not this is a sign of timidity and it does not bode well for an IT department.
Nice writeup, by the way.
Re:Bespoke Software
ajt on 2003-12-16T10:31:12
I can understand their fears. Who hasn't inherited a job that was easier to scrap and start from scratch than to continue with?
However like you say favouring a known buggy, slow and expensive solution in favour of a smaller well written bespoke one is a false economy.
Re:yes! yes! yes!
ajt on 2003-12-16T10:01:29
The sad thing is that Perl is faster at the XML stuff than the damn Java layer! So much for Java and XML being the natural choice!
By removing the XML/XSLT which becomes redundant once you migrate to native data structures, I think I can achieve a better than 10x speed improvement.
At the end of the day the front end of this application is Perl on Apache, and by removing the webMethods BC Server, we remove a whole tier of code, and simplify the existing Perl front end. While the BASIS team don't like bespoke code, moving away from Java reduces the code in totality and hence there is less bespoke code.
