OSGi vs NetKernel

[andrew ennamorato]

Craig,

From another post, you mentioned "OSGi is more about taking discrete components of an application and breaking them into their own individual deployment units. But unlike a typical ESB scenario, these components are deployed in the same VM." You also mentioned that OSGi is a little bit like "SOA in a VM".

I'm not real familiar with OSGi, so pardon the ignorance, but these statements sound familiar to what I've seen/read about NetKernel - i.e., using resources or services as objects. Is this a valid comparison? Or am I way off base?

If it is the latter (which I'm guessing), does OSGi help with the "resource oriented computing" aspect of Java development? In other words, does OSGi help us look at objects not just as objects and data, but as services or resources from another network/system/Internet?

[Craig Walls]

andrew ennamorato wrote:I'm not real familiar with OSGi, so pardon the ignorance, but these statements sound familiar to what I've seen/read about NetKernel - i.e., using resources or services as objects. Is this a valid comparison? Or am I way off base?

My No-Fluff/Just-Stuff friend, Brian Sletton, will be disappointed to hear me say that I'm not real familiar with NetKernel. So pardon my ignorance on that subject and let me try to answer your question in a way that may clear it up (of course, if it doesn't, then by all means ask again).

Way back when, we wrote programs as a series of imperative statements. That was great, but then we realized that we could collect a set of imperatives into procedures. These procedures provided a form of modularity in our application. They were reusable, cohesive (ideally), and easy to understand chunks of an application. Furthermore, the contents of the procedure are unimportant to those who call that procedure, so we get a little data-hiding benefit as well.

Then we decided that those procedures (and the data they work with) could be wrapped up in things called classes and objects. The same benefits came from that, just at a slightly more coarse level.

OSGi represents another level of modularity where we take a set of classes, interfaces, and other artifacts and wrap them up in units that can be reused, tested in isolation, understood in small doses, and that hide the internals to those who consume those units. Internals are hidden by default unless (1) packages are explicitly exported or (2) services are explicitly published into the OSGi service registry.

Note that Java packages don't achieve any sort of modularity...they're just an organizational trick. And plain-vanilla JAR files don't achieve any true modularity because there's no way to hide internal details...once a JAR file is put on the classpath, the JAR file boundaries dissolve and it's just a bunch of stuff on the classpath that everyone can see and use.

So...looking at it from this view, OSGi doesn't try to solve the same kinds of problems that SOA solutions solve. It just happens to employ an SOA model within a given VM. (Again, OSGi's SOA has nothing to do with web services, REST, HTTP or any other remoting.)

[andrew ennamorato]

Craig Walls wrote:
My No-Fluff/Just-Stuff friend, Brian Sletton, will be disappointed to hear me say that I'm not real familiar with NetKernel. So pardon my ignorance on that subject and let me try to answer your question in a way that may clear it up (of course, if it doesn't, then by all means ask again).

Ha! That's where I learned about NetKernel (Brian) and he did a really great job of 'opening' my eyes to new ways of thinking, especially in regards to REST/semantic web.

That was a great response and definitely put some meat to the concept of OSGi that I've had floating in my grey matter. Thanks!

So...looking at it from this view, OSGi doesn't try to solve the same kinds of problems that SOA solutions solve. It just happens to employ an SOA model within a given VM. (Again, OSGi's SOA has nothing to do with web services, REST, HTTP or any other remoting.)

Gotchya. I read your "SOA in a VM" quote as what you mentioned here, basically separating things into useful modules that can be used without knowledge of the internals. But again, thank you for the very well described definition.

EDIT: Now my brain is wandering off to thoughts of OSGi modules/units that don't have to be running in the same JVM. Is there any plan/future goal of such a thing? What would be interesting is to apply the shared-cache model of say, Terracotta or Coherence, to OSGi? Is that even possible?

[Craig Walls]

andrew ennamorato wrote:EDIT: Now my brain is wandering off to thoughts of OSGi modules/units that don't have to be running in the same JVM. Is there any plan/future goal of such a thing? What would be interesting is to apply the shared-cache model of say, Terracotta or Coherence, to OSGi? Is that even possible?

Well, I suppose those ideas (Terracotta/Coherence) are possible, but one thing I've avoided talking about until it came up (and now it has come up) is that OSGi R4.2 defines distributed OSGi...or that's what it used to be called (I think it's called OSGi remoting now). With OSGi remoting, services in one OSGi runtime can be consumed in another OSGi runtime. I blogged a little about this at http://www.jroller.com/habuma/entry/pax_runner_profiles_and_distributed.

[andrew ennamorato]

Interesting. In my humble opinion, these shared cache tools (Terracotta) and frameworks like OSGi (and NetKernel, or whatever is doing the resource oriented computing) are going to set the future for really neat cloud computing applications - with a bunch of servers all in one big "cluster", where's the limit? And the neat thing is it can all be done in JVM/POJOs...

thanks again for all the info.