Re: Jini vs/and OSGi

On 30/03/07, Niclas Hedhman <[email protected]> wrote:
> Sorry for jumping in late, but I have been out of commission for long...
>
>
> It is with tears[1] in my eyes I read this thread. The misconceptions on both
> sides are large, and I even here disrespect among some fellows here for OSGi.
> And this "impedance mismatch" between understanding each other will probably
> lead to perpetual separation, exempt Newton and similar rebels.

Okay, as I see it (not necessarily how everyone else sees it) Jini and
OSGi do significantly _different_ things by primarily messing around
in the same _area_ of Java - classloaders.

OSGi does it, for the packaging of components to facilitate a well
encapsulated component model that allows for linking of components
through defined without having too many knowledge about the
implementation to remove issues with multiple dependencies.

Jini does it to support the use of Mobile code and to allow the
dynamic loading of that code from the network at runtime, with only
the knowledge of the interfaces to allow a channel between client and
dynamically dwnloaded stub needing to be required at compile-time and
indeed runtime; a side effect of which is the creation of classloaders
per service (ish)

Just because two technologies use the same tricks does not make them:
a) fundamentally the same
b) competitors in the same technology space
c) unusable together in some form

> The OSGi community's main complaint about Jini is the "undefined classloading
> model". The security complaint from OSGi towards Jini is probably moot at the
> advent of 2.0.

I think it could be more a case of ' your classloader tricks are not
our classloader tricks'

> AFAIU, the Jini community's main complaint about OSGi is the attempt
> at "remoteness transparency".

Transparency of remoteness is to be approached with caution, yes, but
I would not say that it is 100% a bad thing

> So both camps close the door and throw dirt at the other side's door. Bad!

I think this comes down to two issues
1) People believe these two technologies do the same thing, therefore
they have to make a choice - they don't. I can run a SDM from a OSGi
bundle if I so wish...
2) NIH syndrome

> Do I think it can be resolved?? Honestly; No. The mentality is lacking. Each
> side refuse to educate, and be educated by, the other side.

I actually think it can be resolved, if people stop trying to
assimilate one technology into the other.

> The Jini zealots speak of all the things that can't be done if Jini is inside
> OSGi. OSGi crucifies the lack of strong classloading model in Jini. The Cold
> War persists.
> "Man the barricades. There is an on-slaught of criticism to our perfect
> technology."

I've been using Newton and I don;t have aproblem with it - in fact I'm
building a desktop system that is built up from OSGi bundles but
automatically binds ServiceUIs into icons on a dekstop so you have
applications locally from OSGi and remotelty connected applications
through Jini - it works so far. If I run into a problem then I'll deal
with it then.

> I recall I tried to bring up ~9 months ago or so, the window of opportunity to
> marry Jini with OSGi. Criticism here wasn't overly positive (understatement
> of the day) and the window is practically closed. The OSGi Enterprise Expert
> Group is not even considering Jini as a player in the field. It is WS-*, SCA,
> ESBs and OSOA from one end to the other. Bandwagon mentality and mob
> behavioral "me too"...

Well perhaps with River and Felix we can look at that?

--Calum

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]