Distributed OSGi – On The Scent Of Red Herrings

red-herring_color.jpgSo, 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)


Oddly, I happen to agree with the basics of what Roger Voss has to say in his post which really doesn’t have much to do with Distributed OSGi qua RFC 119. I mean, I was doing orthogonal persistence and distribution before Microsoft even invented the term Object and when the OMG was a toddler. All the issues that have since become well known regarding distributed computing, RPC and “transparence” are well known to me and something that I internalized quite a long while ago.
There’s something that I’ve tried to get across in the various forums I’ve been a part of – SCA and now the OSGi EEG – but the point doesn’t seem to get across too well and that is this:

Fine. You don’t like transparent, RMI style distribution. You think there’s a huge difference between ‘remote’ communication and ‘local’ communication that you believe should be ensconced in the very bowels of a ‘distributed’ interface. Fine. But what you seem to be completely missing is that the API presented by the ‘service’ is a Java object. It has Java semantics. If you want an exception thrown to indicate remote communication issues, then you had damn well put it in the interface specification. If you want to expose the wonderful rawness of the asynchronous communication patterns underlying all distributed communications, then by all means encode it into the interface of your Java object.

The point being simply that you have a Java object there. You don’t like “transparency”. Then you can pretty much define any interface you damn well like. My only request is that you don’t “force” it on the rest of us.
Look. OSGi services aren’t anything magical at all. One thing that I think people who haven’t used OSGi at all are extremely confused about is that OSGi services are simply Java objects. They are not proxied – meaning that you have access to the actual, honest to “Bob” Java object that is the service. They do not have to implement an interface – meaning that there is literally no restrictions on what you can publish as a service.
And so all this whining and moaning about how we don’t need yet another failed “transparent”, “RPC-based” distributed object model is really just whining and moaning without understanding what is going on. RFC 119 (so far!) doesn’t say jack about what the actual model for the distributed object model actually is. Yes, there’s a lot of people working on the spec who honest to “Bob” believe that they really, really do have the uber distributed computing model sewn up and that’s what all the really cool (and productive) programmers will be using next year. But RFC 119 doesn’t promulgate any such model.
And that’s the way I hope it stays. There’s always a lot of loose talk about defining an “asynchronous” model or another god forsaken web services model, but these are and should remain orthogonal to the oddly named RFC 119, “Distributed OSGi” specification. My personal opinion is that the days of communist inspired, five year centrally planned API specifications by standards organizations are long, long gone and will be quite infrequent in the future. POJOs rule and there’s really absolutely no reason to specify much beyond what is already specified in RFC 119 (there’s already, imho, too much specified in RFC 119, but that is purely my personal opinion and in any event, it’s done in such a way as I don’t have to pay attention to it if I don’t want to).
However, what is important is the way services are used in OSGi and the way the service registry hooks allow some highly sophisticated and quite magical (if I may be so bold as to use that term) capabilities in OSGi that really are quite handy. Regardless of whether you have Ajax communication, JMS messaging, god’s own event oriented communications APIs or (shudder) straight up RMI “transparent” communication, the facilities that RFC 119 relies on (and, of course RFC 119 itself) will make not only the development, but the actual interaction with your services from the end programmer’s perspective a fantastic experience.
Focussing on the API of some mythical dream of transparent, RPC style (or even event oriented) distributed communication is completely missing the point of what is happening with OSGi and distributed communications – and RFC 119, “Distributed OSGi”, in particular.

Leave a Reply