Re: Jini vs/and OSGi

Jim Miller-Cushon wrote:

> I leave it others more expert to comment on the merits of the the
> approach, and the accuracy of what it says about Jini.

With regard to Jini
-------------------

They only refer to Jini in terms of lookup and discovery, not to any of
the other parts of Jini, such as leasing, transactions, Jini ERI and
probably more important the philosophy behind it. I think they haven't
heard of Jini ERI [1], but it is clear they also don't want to.
The OSGi Platform is not an extension of J2SE as it also supports
other platforms that don't have RMI included. And although you can use
something else with Jini than RMI for the protocol, Jini relies on RMI
(for reference see
http://archives.java.sun.com/cgi-bin/wa?A2=ind0410&L=jini-users&P=25495).


The merit of their approach
---------------------------

I've done a quick read and what strikes me are these statements:

"Transparency: For each local OSGi framework, the distributed character
of the whole federation should be masked. Remote services should be
accessible as if they were locally present in the framework."

"Consistent Behavior: The default behavior of OSGi services should not
be influenced by the distribution. The perspective of a remote peer on a
service has to be the same as that seen by an entity within the local
framework."

I wonder how do they do that, RMI has pass by value semantics and not by
reference (as for local computing). So I fail to see how they can make
that statement in the light of having mutable objects in the service
interface. Also given the way how they implement the remoting part I
can't see how they can keep up with this statement.

I haven't seen any language of how they think of implementing all
security aspects such as integrity, confidentiality, authentication
which was a huge effort that resulted in Jini 2.0. They do mention
mobile code, but maybe this will end up the same way as security is
arranged for in clustered application servers (one node trust whatever
the other node is supplying).

To me this seems all about remoting and transparent discovery and join
as part of the OSGi platform. The fact there is an intrinsic difference
between local computing and distributed computing shows to me they are
heading the wrong way with this, but no doubt the larger percentage of
developers will cheer when this transparency has been arranged for them.
To make them converts my hopes are on those with Gilad Bracha's [2] blog
style to slaughter them all ;-), but maybe those capable of that died 65
million years ago.

Jini is all about defining your service to the network regardless of the
way it is implemented at the backend giving you the ultimate freedom
and no need to bet on one horse. The fact each of them can operate as a
Jini Platform arranges for interoperability. This attempt (I believe
this is not formal OSGi work) is clearly based on the assumption
OSGi is the uber-container (they want to extrapolate the current
requirements into the remote domain) and that interoperability is
defined by OSGi. Exactly this leads to the feeling that people must
bet on OSGi or J2EE, and that I (out of the same fear) must read these
specifications :-(

I'm also not so sure whether the "proxies" to the remote servers
are by itself distributable or that the transparency only works in one
instance of the OSGi platform. To me the fact you can marshal service
proxy to storage, for crash recovery, etc. or to pass them to
other remote entities over the network is something important.

Don't get me wrong, this might be very valuable to a lot of people and
when something similar becomes part of the next OSGi standard I wish
them all the best. It is however only a pity they refer to Jini, as
people might conclude from that they created an improvement upon what
Jini provides. At some points they validate their choices in the context
of Jini and to me some of them are not completely fair, but heck that is
part of life and to necessary "to make your point" I guess.

Sometimes I wonder how the Java landscape would have looked like when
Jini ERI and Jini security would have been accepted by the JCP as part
of J2SE and the application server vendors would have shared the Jini
vision ...

[1] given their reference of overhead of DGC it is clear they haven't
kept up with Jini ERI (I expect nobody uses DGC and uses something else
to keep the service alive).

[2] FYI Gilad Brach is also busy with Service Objects, see
http://gbracha.blogspot.com/2007/03/sobs.html . I'm still not sure what
the scope of these are and how to position them, but certainly
interesting to follow.
--
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]