Having worked in OSGi for quite a while, the most frequently asked question I get on the technology is “what’s the value proposition.” Being a rapacious capitalist at heart, I think this is an eminently fair query from anyone looking at this OSGi stuff and scratching their head and wondering why the heck they would even want to consider using this technology in their systems. There’s a non-zero and usually non-trivial cost associated with changing technology – a cost which usually grows in direct proportion to how “low” the technology is on whatever technology stack you are deploying. OSGi is pretty low on that technology stack, so it has the potential to be very disruptive and hence very costly to an organization which adopts the technology. Surely the benefit of making the switch should be at least proportional to the costs and a prudent business would like to understand what they’re going to get for their trouble, and more importantly, their hard earned money.
To answer this question, what I first ask is that people think about their current environment. Assuming you’re not a startup – a domain which I’m not considering in this post – then you are undoubtedly dealing with a mature system which is now or quickly will resemble Frankenstein’s monster more than anything else. If your system is successful to any degree – and if it isn’t, then we aren’t really having this conversation – what you find is that your system is a victim of its own success. Grizzled veterans remember the “good old days” when builds would take less than an hour and everyone could sit in a room and share a common understanding of what the hell was going on in this money maker of yours.
Sadly, one day you look up and find that no one knows what the hell is going on anymore. Build times – perhaps one of the more visceral measurements of complexity we have – have jumped dramatically. These days, people fire off builds and then go on lunch breaks. Worse, your projections are that in just a short time in the future, the nightly “integration” builds you kick off will still be running well after your developers have shown up for work. It’s at this point that one panics and decides that dramatic action is required. Something MUST be done. Well, as long as that something doesn’t require any change to what you’re currently doing – i.e. one starts searching for a silver bullet which will slay this beast of chaos that you’ve collectively created and return your life back to the way things used to be. Before “IT” happened.
One of the more painful lessons that I learned in business is that good contracts keep good friends as good friends. I had to learn the hard way how stressful it is on even good, solid relationships between very smart and honest people when misunderstandings occur about things that mean something to them – i.e. MONEY, or more generally BUSINESS. When things are just left up to good intentions and the belief that “we can all just work this out like normal people”, I invariably find the trail of debris in broken friendships and business partnerships.
I am of the opinion that no one actually sets out to do stupid things. Rather, stupid things happen almost invariably for the best of intentions. Thus the phrase “The path to hell is paved with the best of intentions”.
And so it goes with standards. In the past week, I’ve been privileged to witness two crystal clear examples of first class paving of the path straight to the gates of hell. The root of both of these examples is the simple fact that the specification organization doesn’t have a process in place for dealing with the changing of a specification after it has been accepted as final. Basically, in this organization, the “final” version of the spec is presented to the members, and the members vote on whether to accept it. Sounds simple, right?
Well, the devil is always in the details and due to the way these things are scheduled, the reference implementations and conformance tests for these specifications aren’t finished at the time that the members vote on the “final” version of the specification. Consequently, if anything shows up in either the creation of the RI, or in the creation of the conformance test which is to verify that the behavior in accordance with the specification, there’s a serious problem that needs to be resolved.
In the two cases I’ve been privileged to see this week, the first was an issue with time. As with all things, resources are limited, and certain resources are scarcer than the sympathy in a banker’s cold, dead heart. Consequently, when the time pressure to produce something gets unbearable as the deadline approaches, the reality will set in and like survivors on a sinking lifeboat, everyone starts looking for stuff to throw overboard. And because this process is done under pressure, there’s not an awful lot of thought and strategy put into the choice of what is being chucked overboard.
This week at EclipseCon, I discovered that I had inadvertently opened a can of worms and found the entire Landsraad of the Open Source community arrayed against me. My crime? Apparently it’s simply that I’ve had the audacity to pick up an OSGi specification that has been in existence – and in the public domain – since 2005 (i.e. OSGi RFC 112, the OSGi Bundle Repository) and attempt to work out the issues with that specification so that we can finally formally release it as part of the OSGi specification.
Much of the suffering I was dealt was due to serious misunderstandings of those involved with the process that is currently being played out. Some of this misunderstanding is due to ignorance of the OSGi process – and note that I use the term “ignorance” not as a pejorative, rather simply as a statement of fact. Those who aren’t involved in the OSGi process, nor familiar with the way that specifications in general are produced can sometimes be left bewildered by the array of TLAs and the process by which consensus is reached. Certainly in the Open Source world, sometimes things are done quite differently than they are done in standards bodies (note: I’m not saying that this is universal, only making the point that standards bodies are their own beasts and Open Source communities rarely conform to such formalized systems).
So let me make a couple of points, and talk about how I’m going to carry out the process of specification of the OSGi Bundle Repository to ensure that the world outside of OSGi can participate in this process.
Well, it seems our friends at Sun have decided that their Spicetm Enhanced brains are completely sufficient to create an entirely new – but far simpler, mind you – module system for the JDK. Mark “I’m just a simple Guild Navigator” Reinhold has spent a number of blog posts doing the electronic equivalent of the Dance of theSevenVeils, culminating with revealing the aptly named Project Jigsaw.
First off, what Spicetm Enhanced marketing mind came up with the name Jigsaw? I mean, really. Who thought it would be a good idea to associate a “simpler” module system with a 1500 piece puzzle set that is composed of pieces that look terrifyingly all similar and takes multiple people multiple months to put it together?
But this, of course, is really just the beginning of the insanity.
So, this morning my alarm clock was inexplicably set to the central time zone and consequently I arose 2 hours before my regularly scheduled time. Unable or unwilling to go back to bed after my morning “get ready for work” rituals, I settled down to read a few articles from my RSS feeds. The first one I read was a rather odd post on Distributed OSGi – Tilting at Windmills by Roger Voss. Laughing a bit as I read the opening paragraph, I didn’t think much more about the post as it really had nothing to do with what the OSGi RFP 119 “Distributed OSGi” really is about. Fortunately or unfortunately, several people started peppering me with tweets, IMs and emails asking if I had read the post in question and what were my thoughts about it. So, here they are.
Basically, I’m not really going to defend the OSGi EEG RFC 119, “Distributed OSGi” as my own interest in the matter rested largely with the acquisition of the so called “registry hooks” which allow infrastructure developers such as myself to hook into the queries of the OSGi service registry and do cool things like manifest services on demand. Once this capability was present and decoupled from the 119 RFC, I felt I had all the tools I needed to do any damn thing I wanted to, regardless of what the 119 RFC was doing. (for background as to how I fell in love with the idea of the registry hooks, see my posts on remote OSGi, which predated the RFC 119 here and here and a post during the formulation of the RFP which led to RFC 119 here)
Update: Part II – the long kiss goodnight, Part III – The First Cut is the Deepest
This is the first in a series of posts documenting the research I’ve been doing into a different way of thinking about system management infrastructure. For quite some time, I’ve been obsessed with the idea of how to simply and effectively manage large scale systems. Throughout this obsession, I’ve travelled down various roads and found myself in several box canyons along the way. I’ve tried out a lot of different strategies and have finally settled into something which provides the kind of framework I’ve been looking for which I haven’t found replicated anywhere.
Note that I’m certainly not making the claim that it is “Teh Best” management infrastructure. Rather, what I’m making the claim is that it’s the most interesting management architecture to me. As anyone who knows me can testify, I have rather peculiar tastes and I am a strange bird at times. So fair warning, eh?
In any event, what I plan to do is to provide a fairly deep dive into the architecture that I’ve come up with. In the standard tradition of all literature scientific and technical, it will be presented in precisely the opposite order in which I actually came up with things – i.e. from the top down, in a semi coherent form that makes sense. Lord knows that actual discoveries and explorations are more a matter of luck in which you discover something and then spend an inordinate amount of time tracking down why the heck you managed to stumble upon it and where it fits in the larger picture of things that you’re trying to map out. I’ve always found this cognitive dissonance amusing, myself, and hope you won’t mind to much when I veer off into seemingly irrelevant paths rather than sticking to the point at hand.
If you’re one of those people who can’t wait until the end of the story to find out what’s going on, by all means download the PDF of my talk on the subject at last year’s Spring Experience entitled Digging the Trenches on the Ninth Level. If you’re not familiar with Dante’s Divine Comedy, then you won’t get the joke. But suffice it to say that I’m a big believer in the principle that every time you solve a problem, you discover ten more problems that you didn’t know you had.
A perfect example of this sometimes perverse law is something as simple as email. Email solved a lot of problems that a modern economy and social population have, but in doing so it created a lot more. Without email, we would never have been subjected to the sublime beauty of penile extension spam nor would your grandmother be subjected to the horror of id phishing which you discover has snagged her bank account and drained all her life’s savings leaving you with a predicament that makes you wonder what all this progress was supposed to do in the first place.
Likewise, I firmly believe that in solving the problems I believe have been addressed by OSGi, Spring DM and management architectures like mine, we’ve inadvertently unleashed new levels of horror that will ensure future generations will curse our names as they suffer from the fall out and live the unspeakable abominations unleashed from these “solutions” and witness them unfold in ways that we couldn’t possibly imagine.
So, with that cheery panorama as the back drop, I’ll end this introductory post and start working on the next post, which provides high level overview and ten dollar tour of the sewers that I’ve been digging for your benefit on the ninth level of hell.
Remember. I dig because I care. After all, you do want that frozen crap to be routed somewhere and dealt with, don’t you?
My talk at last year’s Spring Experience talk on the next generation of application server architecture is available here.
The talk is about OSGi and how the next generation of application server platforms will simply do away with the cumbersome and rather dated component models that we all know and hate in favor of the vastly superior OSGi platform. Or that’s the theory at least. Only time will tell if I’m correct or just another mad hatter sniffing too much mercury outgassing from the various toys littering his office.
In addition, I also lay out the management architecture I’ve been experimenting with for the past year. Obviously, it uses OSGi as its base, but OSGi – by itself – isn’t sufficient to provide the kind of management infrastructure you need to manage large numbers of processes. I call this management architecture – for lack of a better name – Event Driven Autonomic Management. I’ll be kicking off a series of posts going into far more detail on this architecture as a means of documenting the research I’ve been doing.
Think of it as therapy, as talking about it on this blog – posting, so to speak, to the wind about concepts and issues that no one else seems to find terribly interesting or useful. You can tell I’m a great hit at parties, can’t you?
I’ve been having a great time working on my MMOG framework, 3rd-Space. Since December, I’ve been focussing on the actual event driven simulation framework, as this framework is key to the system’s performance and scalability. The work is based on the simulation framework described by Rimon Barr in his thesis, An Efficient, Unifying Approach to Simulation Using Virtual Machines – something he calls “JiST” (Java in Simulation Time). It’s a very cool event driven simulation framework that uses Java, itself, as the simulation scripting language. He turns the Java classes into a simulation by transforming the Java classes using a byte code rewriting framework. The result is a very easy to use, completely type safe simulation framework that completely blows the doors off the closest competing C++ event simulation frameworks in terms of raw performance and scalability. The performance is so good because the framework uses the Java virtual machine as the engine for running the simulation.