Re: Jini vs/and OSGi

Thought the list might find this interesting, in light of the Jini
and/or/versus OSGi thread:

I noticed this from from Peter Kriens' (OSGi evangelist) blog at
http://www.osgi.org/blog/2007/03/if-you-followed-this-blog-you-have.html

"...A good example of the power of the service model was shown by Jan
S. Rellermeyer from ETH. He made the service registry distributed,
allowing applications to use each other's services even if they ran on
different machines. Distribution is a cornerstone for the Enterprise
Expert Group so Jan's presentation was very interesting in this
light."

Some googling quickly turned up links to Rellermeyer's work at
http://www.iks.inf.ethz.ch/publications/eclipsecon07.html  There's a
link to Rellermeyer's paper that discusses alternatives for
distributed computing with OSGI, and presents R-OSGi.
http://www.iks.inf.ethz.ch/publications/files/rellermeyer_eclipsecon07.pdf

Here's the abstract: "Distribution is increasingly becoming an
important issue in
both enterprise applications and mobile computing. OSGi itself
has only rudimental support for distribution, in forms of
interfaces for interaction with Jini (R3) or UPnP (R3 + R4)
infrastructures. When it comes to interconnecting different
OSGi frameworks, there are only few solutions so far. In
this paper, we present these existing solutions and compare
the different approaches with our own R-OSGi. The goal of
our open source project is to provide a seamless and noninvasive
middleware for accessing remote services in OSGi
frameworks. We explain the basic design principles of ROSGi,
such as transparent service access and spontaneous
interaction, and briefly mention the internal structure and
techniques used in R-OSGi, such as service discovery and
smart proxies."

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


On 3/15/07, Thor Wolpert <[email protected]> wrote:
> I did some work on combining Jini and OSGi.  I was looking at using
> Spring as part of the glue, but was advised by yhe OSGi spec group
> not to use Spring as the it didn't align well with OSGi and the
> config overlap was better dealt within OSGi.  Maybe they have changed
> their minds due in part to the success of Spring.
>
> I was using Felix as the OSGi container in hopes that the Jini
> codebase would move to Apache, which is still underway.
>
> My thoughts were to steal some of the ServiceUI techniques to provide
> ServiceBundles that make it easier to load into an OSGi environment
> (and also isolate some of the classloader issues that were present in
> the R3 Jini implementation).
>
> In talking to the OSGi folks it was the classloader issues in the R3
> Jini connector that posed problems that no one had an itch to fix.
> Fair enough.
>
> I'm hoping to restart my Felix / River work as the code starts to
> show up on Apache.  Apache is a meritocracy, which comes out more as
> a doacracy (if you want it, then do it and get people to join in so
> it stays) as one of the examples in the River package, day job
> permitting.
>
> Cheers,
> Thor HW
>
> On 15-Mar-07, at 4:08 AM, Dan Creswell wrote:
>
> > Adrian wrote:
> >> Hello,
> >>
> >> Would anyone care to comment on where they see things heading with
> >> the
> >> aforementioned specifications? There seems to be significant
> >> functional overlap
> >> in current implementations. My impression is that OSGi is gaining
> >> a lot of steam
> >> (mostly due to the huge success of the Eclipse project, I suppose)
> >> and will
> >> probably be evolving to offer more and more of what Jini does. While
> >> Jini/Javaspaces has also been in the news recently, OSGi seems to
> >> be leading in
> >> developer/tool maker mindshare and there is a lot of 'real' work
> >> done in terms
> >> of advancing the spec. This article, written at the end of 2005,
> >> http://www.osgi.org/blog/2005/11/why-did-we-let-jini-out-of-osgi-
> >> r4.html doesn't
> >> doesn't make it sound very promising for Jini (viewed through the
> >> subjective
> >> eyes of the OSGi Alliance at least). I'm curious why there was no
> >> one (I'm
> >> thinking GigaSpaces or Dan C., for example) to beat the drums for
> >> Jini to be at
> >> least kept in the "Recommended" section of the OSGi spec.
> >>
> >
> > Personally, I had no involvement or awareness of what was going
> > on.  So
> > I couldn't have banged a drum even if I'd wanted to.
> >
> > I have had feedback since about why's and wherefore's and as it
> > happens,
> > there's some work to fit Jini's own packaging model into the OSGi
> > mould
> > which I am aware of.
> >
> >> Would it make sense to think of a JavaSpace as an OSGi service
> >> instead of a Jini
> >> one when and if OSGi evolves to provide service lookup across a
> >> grid? Are the
> >> security/classloader issues mentioned in the article areas that
> >> Jini will
> >> address in the near term?
> >>
> >
> > Haven't read the article but Jini 2.x has pretty strong security.
> > As to
> > "fixing classloader issues" can't comment until I see what issues are
> > being referred too.
> >
> > To the best of my knowledge, until very recently the OSGi folks had
> > zero
> > familiarity with Jini 2.x and work in R3 was all around Jini 1.x which
> > was a totally different beast.
> >
> >> The following presentation talks about using OSGi and Jini
> >> together, so not
> >> everyone seems to agree on where the future is headed for both specs.
> >> http://www.jini.org/wiki/
> >> 10th_JCM_Sessions#Service_oriented_components_on_the_grid_using_OSGi_
> >> and_Jini
> >>
> >
> > Well, the long and the short of it is that neither spec is
> > dependent on
> > or needs the other.
> >
> > That's not to say that there isn't benefit in the two efforts working
> > together but that's all about politics not tech.
> >
> > Dan.
> >
> > ----------------------------------------------------------------------
> > ----
> > 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]
> >
>
> --------------------------------------------------------------------------
> 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]
>

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