Management Platform, Sum of Technologies (part 1).
Since no one attempted to disprove statement I made in my last post (Management platform, Open source or bust. 09/15/2005) I will assume that every one think that Open Source Management Platform is a brilliant idea (just for the records, I can not claim ownership of this particular idea, but it does not make it any less brilliant). Today I will try to create “shopping list” of other Open Source projects which could be used as a building blocks for such Platform. But of course, Java This is not per-say open source project, but none of the less choice of “the language” will play major role in selection of Open Source projects available for consideration. In my mind, there is only one answer to this – Java. Despite relentless attempts by Mr. Gates, enterprise networking landscape is as diverse as ever. And the only way to avoid porting nightmare is to do Java. It might not be 100% “write once, run anywhere”, but for none-GUI applications it is damn close. Last thing to consider in regards to “the language” is what version of Java to use? It is very tempting to go along with Java 5.0 but I think we need to stick with 1.4. Though Java 5.0 provides bunch of new functions/features none of them are “must have” kind and I have a feeling that its proliferation in the “enterprise world” is not that wide yet (just a couple years ago I run into customer who still used 1.1.8) Built to be customizable There are at least two level of customization which need to be addressed: ability to add new functional modules (plugins), ability to implement new functions by combining basic functions provided by plugins. Many Open Source (and closed source) applications implement support for plugins in one way or another. I think JBoss does it best. JBossMX is clean room implementation of Sun JMX API. It is available as a part of JBoss server source distribution. One additional benefit of using JBossMX as a “container” is ability to do “cross-plugging”. It should be possible to plug JBoss modules into the Platform and Platform modules into JBoss! With such a flexible container as a JBossMX it will be a shame to require to do any Java codding to implement “new functions”. Also if we are trying to build Platform which could be “customized” by end user it is not reasonable to expect such an end user to know how to program in Java. What we need is nice scripting language. It should be: well known ( we do not wont to invent our own and then expect people to learn it)