from http://www.tensegrity.hellblazer.com/2008/06/distributed-osgi---on-the-scent-of-red-herrings.html
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)
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.