Re: Jini vs/and OSGi
Dennis Reedy <[email protected]>
| Newsgroups | gmane.comp.java.sun.jini |
|---|---|
| Message-ID | <[email protected]> |
> > > 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 ... 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. 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]