Agility = Pluggability

Jan Burse, created Oct 10. 2011 We live in a brave new world with the promise of ubiquitous communication. When I was travelling to India some 18 months ago, the internet connection in my Hotel was faster than at my work place. The internet connection even remained stable during the regular electrical black outs during the day. The TV and the ventilator in the bath room went down, but my laptop switched to batteries and the Hotel Wi-Fi hubs probably did the same. But the biggest problem in planning the trip was to decide what devices to take with me. There was the requirement of bringing the laptop of the contractor with me. Question was how could I manage to do the minimal service required for other projects as well? Working fully remotely has not been an option. Neither the Hotel nor the work place connections were fast enough given their cheap price. Security concerns also forbid using the Hotel connection. So the idea was to carry the work with me. This could be solved by bringing a couple of laptops to India. But wait, I don’t want to travel with a couple of laptops to India for a short trip! So what I tried was to move all the relevant projects at that time onto one single laptop. Since most of the used technology is Java this should not be a problem one might think. In fact I had to move a project that was running on a Mac OS X and another that was running on a Linux. It turned out that Java is not the main problem. The Java code is executed by the Java virtual machine. Java virtual machines are available for a couple of operating systems. All one roughly has to do is copying the Java byte code of the application. But the Java virtual machine sits like a sandwich in the middle of an application. What we then have most likely is some platform dependent storage layer beneath. And in fact the different applications were all running on different database management systems. But I didn’t want to install all these database management systems on my target system. I wanted to reuse the existing database management system here. So the architecture of our Matula database layer once more saved my life. It is based on a plug-in architecture. Plug-in architectures have been early on pioneered by Unix and its driver concept. The idea is based on a uniform view of hardware, everything is a file. Today we can easily implement plug-ins in an object oriented programming language by using the object factory pattern. In the object factory pattern one uses an additional indirection for object creation. The object factory pattern is used in many places in the various Java editions. The standard edition already makes use of this pattern in so many places that it is difficult to name them. Cryptography, Audio, Web Connection and Character Encoding are only a few examples to mention. The object factor pattern is not as restraint as the driver concept. A hard ware unit does not need to locally exist and the created objects can be very fine grained and in large numbers. The plug-in concept has only recently been introduced in the Matula database layer for both the code generation and the runtime. Before the plug-in concept we just used some rules dispersed over the database layer and were mainly relying on the JDBC standard. But the JDBC standard neither hides vendor specifics nor does it compensate for functions missing by certain vendors. Via the plug-in concept all the requirements by the Matula database layer for the vendors are now described and realized in one place. Unfortunately the trip to India was too short to put the super fused laptop really to a test. When autonomous for the first time it turned out that the relevant plug-in still needed some fixes and fine tuning. But what could be archived was proof of concept for one more vendor. A new problem we will face in the future will be the presentation layer. The Jekejeke Prolog console is based on SWING, but Android would demand a different GUI toolkit. So we are currently looking into a plug-in concept here eventually combined with a XUL component.