Re: Jini vs/and OSGi

Dennis Reedy wrote:
>>
>>
>> That's what I would've thought, but the action of removing Jini as a
>> recommended
>> spec to track/follow/integrate with, by the OSGi alliance seems to
>> indicate
>> otherwise.
>
> I personally was not tracking that announcement or move over in OSGi
> land (not sure who from the Jini community was). One can never be sure
> of the motivation behind this, and from the description o the link you
> provided I would have to say that the author did not keep up with the
> Jini technology, the community and the many improvements made.
>
> Regardless, I think its moot right now.
>
>> Recall that OSGi's initial focus was embedded devices (which could be
>> networked) and being able to dynamically manage services on these. Sounds
>> familiar...
>
> Yes, quite aware of OSGi's initial domain. The categorization of Jini
> technology in the embedded space has (and always will be) something that
> was incorrect. For OSGi it made sense, for Jini it never did.
>
>>
>> This, along with the imminent release (around May) of OSGi support
>> from the
>> Spring framework (http://www.springframework.org/osgi - one of the
>> most popular
>> and widely used open source server-side (primarily) do-all glue
>> frameworks),
>> points to a clear move, IMO, to bring OSGi to the enterprise space.
>>
>> What horse to bet on?
>
> Why do you feel you need to bet on a horse here? OSGi (and Spring) are
> great for wiring up components within a VM. They are both somewhat
> ill-suited for distributed computing. Yes Spring has remoting, but it
> doesnt address the wider issues that deal with discovery, federation,
> fault detection, recovery, partial failure, etc ...
>

+1

Why do we need to bet on a horse? Because we've always done that leading
to all the bad things that go with it like premature "standardization"....

> Using OSGi as a micro-kernel architecture and Spring as a component
> model still perpetuates the stand-alone app server model, albeit one
> that can have module (bundles) easily installed. It does not address the
> reality that there need to be collections of services discovered through
> the network, that when harnessed together can deliver scalable adaptive
> systems.
>

+1

All these solutions are about building a single application out of bits
that all live/run in the same JVM.  And, in fact I was at a Sun tech day
yesterday which made it clear to me that most people still think this
way including, scarily, a number of people at Sun.


> There are a number of projects in (and through) this community that
> offer these advanced capabilities (along with Spring support I might
> add). I run one, its called Rio. On Rio's roadmap is OSGi
> interoperability, both from a micro-kernel architecture basis and the
> dynamic provisioning and allocation of bundles. There is also the Newton
> project that provides OSGi and Jini interoperability. I encourage you to
> investigate these and others. Links to projects can be found at the wiki
> here (http://www.jini.org).
>
> As Jim Waldo pointed out, the “Highlander Principle” (“there can be
> ‘only one’”) is a fallacy. Why perpetuate it.
>
> Regards
>
> Dennis
> --------------------------------------------------------------------------
> 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]