As statement of my perspective...
IBM leads the OSGi thrust, and the bad taste that I got from IBM/Eclipse doesn't
leave me feeling excited about doing anything to "work with" IBM. I found it to
be impossible to "work with" eclipse developers. They insisted it was their way
or the highway.
I am interested in simple software assembly techniques. I am interested in
manageable software systems. Currently, I have no problems getting all of this
out of using Jini and the power of the Java ".jar" mechanisms and dynamic class
loading features of the language.
OSGi from the outside doesn't seem to be "adding" anything to the features that
I need. I currently use netbeans, and not eclipse. I currently don't have a
software development system nor a server deployment system based on OSGi. So, I
don't have an easy road to using, trying or developing in the OSGi "way".
The divisions in systems that developments like OSGi create, are not near as
helpful as they could be if OSGi developers would snuggle up with others in the
industry already doing such things.
From my perspective, the lack of IBM/OSGi knocking on the door, and the lack of
there being netbeans plugins and other more "ever present" OSGi "stuff" visible
in day-to-day Java news, really tells me that IBM is once again, like Eclipse,
on the path of "Our way or the highway", trying to not work with anyone else.
NIH seems to be the name of the game, and they will either steam roll everyone
into submission, or they will fail because such a huge wall gets built up around
them, that they can't get through.
The absolute panic that the Java community was in when it looked like IBM might
buy Sun, I believe, speaks directly toward similar feelings, to mine, being
present elsewhere.
I'm not saying that I should have these feelings, but I'm just laying my biases
out so that it is clear where I'm coming from.
Gregg Wonderly
Sam Chance wrote:
I'm "pleasantly stunned" to hear someone mention OSGi in this list. OSGi is
effectively the norm for Java modularization and all the other things that
come with the standard. All the big guys are migrating or have migrated to
OSGi as there internal architecture. (See [1], [2], [3]) Distributed OSGi
(RFC 119) and OSGi in general exhibits *many* analogies to the Jini model.
I do mean "many". It's a missed opportunity that Jini/River has not
embraced OSGi and sought to be the de facto standard for [managing]
Distributed OSGi.
Jini was touted to be "all things distributed." OSGi is going to be the
common denominator across Enterprise, Mobile, Residential, Automotive and
other sectors. What better choice is there than Jini/River to be the
distribution element to create the seamless interoperation of OSGi bundles
(i.e. services) for intra- and inter-sector interoperation? Jini/River
could/should power the upcoming "wave" of convergence across all the
sectors.
To the best of my knowledge, only Paremus has seen the vision and began to
implement it (See [4]). Their runtime fabric is fully autonomic,
decentralized and dynamic. It features no single point of failure and no
single point of control. It's also a self similar architecture, meaning it
eats its own dog food! The runtime manages OSGi bundles and the fabric
services are also OSGi bundles. It uses Service Component Architecture (SCA)
to assemble bundles into systems; and yes, the fabric bundles are similarly
wired together using SCA to form the fabric services.
As a disclaimer, I get nothing for extolling the Paremus fabric! But as far
as I know it's the only one! What a vision! Yet, no one in this community
- to the best of my knowledge - even considers OSGi as a managed artifact or
an organic aspect of Jini/River.
[1] http://www.osgi.org/wiki/uploads/News/2008_09_16_worldwide_market.pdf
[2] http://www.osgi.org/wiki/uploads/News/2009_02_24_OSGi_Emerging.pdf
[3] http://www.osgi.org/wiki/uploads/News/2009_02_12_100Members.pdf
[4] http://www.infoq.com/news/2008/02/infiniflow-12
Thank you!
Sam
On Fri, Jun 26, 2009 at 6:23 AM, Peter Firmstone <[email protected]> wrote:
I'll contribute too, let's get that Paypal account going, what a good idea
;)
I've recently spent some time going over some of the content on jini.organd
feel strongly that key information there will assist us with River's
future, both technical and philosophical.
I've listened to the speeches in JCM more than once and still find the
information relevant.
There is too much opportunity and potential left for us with River to let
it die, if anything I think that the shortcomings of Java have held us back
to some degree, namely classpath, jar, the complexity of security and the
challenges of the internet. It'll be interesting to watch how the OSGi and
project Jigsaw evolve and see if there's potential to use relevant pieces.
I've been thinking that rather than transferring whole jar files via
classfile servers, versioned classes, individually compressed on demand
(using caching with deflate compression and nio byte buffers) to speed up
code transfer over slow networks (provided your not using whole package
imports) and provide greater flexibility if required. Furthermore,
individual classes can evolve and exist alongside legacy copies, if they can
be versioned. There are other issues in doing so, however, such as, when to
evolve a class with a new version, much like the versioning issues with
serialization. That would of course require OpenJDK7.
But first we must make it easier to participate, I think that the current
focus on changes to the build and testing structures will help us grow, we
must continue to do so while preserving the past in order not to forget
important lessons or repeat old mistakes in the future.
N.B. Thank you very much Jim Waldo, for going to the trouble of retrieving,
getting approval for and uploading very relevant documentation. And for
inspiration...
Cheers,
Peter.
Greg Trasuk wrote:
On Thu, 2009-06-25 at 14:42, Sam Chance wrote:
Wow! This whole topic is scary. I know factually Jini is still
relevant in certain places. I don't want it to die, personally.
Is there an easy way for individuals (like me) to acquire the content
on jini.org?
Can we set up a fund or account using Paypal? This would allow us to
individually contribute, as long as a trusted agent disperses funds to
pay the bills.
Also, can we change the wiki model to a controlled access site? Casual
visitors get read-only rights. Others may apply for write-enabled
accounts.
I am willing to pay the bills as the trusted agent, if the group is
willing to allow me.
Just don't let it die.
Sam
I agree. Don't let it die, and I've always thought that Jini should
have an identity apart from River. I very much like the idea of a
Paypal donation page. Does anyone know how to do that? If there were
sufficient funds donated, it would be great to setup some sort of entity
to hold the Jini trademarks and own the domain.
Cheers,
Greg.
On 6/25/09, Jeff Ramsdale <[email protected]> wrote:
jini.org is currently hosted at Dreamhost and is run on Mediawiki.
I'm open to whatever the community decides. It's been frustrating
combating
the spammers while trying to keep jini.org as open as possible (per
wiki
culture). I'd be more defensive of keeping the site if the community had
taken greater ownership of it, but a lot of the content is stuff I
copied
from the previous site (like the Jini specs and all the content from
Jini
Community Meetings). I'd really hate to lose the JCM stuff, in
particular.
-jeff
On Thu, Jun 25, 2009 at 8:23 AM, Rick Innis <[email protected]> wrote:
This is just a heads up that we have to decide if we want to
keep Jini.org around. The site has been around since the
inception of the Jini Community in 1999, and has gone through
a number of transformations over the years. It's current state
is that it is wiki-based and hosted by Dreamhost.
I use Dreamhost for my own hosting, and I'd be happy to add the
jini.orgsite to that.
We have an outstanding bill for $239.40 that is due by July 8th to
keep
the site going.
I' also happy to chip in towards this.
We can either:
- try to consolidate and move the content to Apache River,
- figure out how to fund the Jini.org site, or
- just let the site (and content) expire.
I agree with Patrick that the domain name should be kept up. I think
migrating the useful content to the Apache River project is probably a
good
idea, and eventually redirecting jini.org there - it makes it clear
that
there's one source for the project.
R.
===========================================================================
To unsubscribe, send email to [email protected] and include in the
body
of the message "signoff JAVASPACES-USERS". For general help, send
email
to
[email protected] and include in the body of the message "help".
To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html
--
Sent from my mobile device
Sam Chance
443-694-5293 (m)
410-694-0240 x108 (o)
