Re: Jini vs/and OSGi

Some more comments after the ones of Dennis and Gregg that made a lot of
sense.

I'm not an OSGi expert but based on my past reading of the specs and
discussions here it appears OSGi doesn't take *real* code mobility into
account. It does to the extent that you can download bundles, but it
assumes code is not escaping your JVM and doesn't flow in from over the
network by a remote method invocation. Also the security framework in
place in the OSGi specs is not what is required for all the security
aspects involving mobile code (as solved in the Jini Platform [1]) or
authenticating clients, enforcing integrity, confidentiality, etc.
Neither does the J2EE specifications, so it is not the first
specification that considers code mobility/distributed communication as
a second class citizen. Given the origin I don't find this strange
though. So IMHO OSGi itself might be fine for local computing only, or
for clients and servers that utilize a wire protocol that doesn't
involve mobile code i.e. exposing your OSGi service as a web service
shouldn't be problematic.

This is not saying you can't make an OSGi implementation work that
exposes Jini services to the network (as has been done by members of
the Jini community). But IFAIK you can't do it in a portable way, i.e.
writing a bundle you can deploy in a random OSGi container and expect it
to work.

Given the scope of the OSGi specs I can understand why the Jini
specification was dropped, because making it *really* work would have
been a major task. Some of the points in Peter Kriens' criticism I can't
place and some of his criticism seems to implicate OSGi in its current
form is not very well suited for the tasks solved by the Jini Platform.

Whether OSGi in the future will specify features related to distributed
computing and code mobility on par with Jini might be possible. If Jini
is not going to be *really* successful, the momentum stays with OSGi,
people want to do type based distributed computing and you assume
people get smarter every year there will be a point in time where Jini
will be reinvented in one form or another ;-)

I can imagine where one could write a 'thing' that takes code
mobility as a first class citizen and that also provides an OSGi
framework for assembling the inner working of your service [2]. Although
in writing many dedicated Jini services I haven't felt that need. It is
easy to talk hours over this subject (I'll keep it short) but it is
my experience that when you partition your system as many Jini
services (fine granularity of responsibilities) there is not much use
for those gluing frameworks (because the glue is Jini here, and the
servers are often relatively simple). But if you use only one Jini
service and the rest are (fatter) clients around that Jini
service then those 'clients' might be helped by OSGi, etc.

[1] I use Jini Platform here for if security is an important
characteristic of your environment it is assumed certain conditions are
met by some rules captured in a local Platform definition, i.e. some
classes have to be locally available to ever establish a trust
relationship and to dynamically grant permissions, etc.

[2] Although I don't know the mileage here, as I think there will be
many cases where you run into problems with where classes are defined in
the class loader hierarchy
--
Mark

--------------------------------------------------------------------------
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]