Re: OSGi and Jini

[Peter Firmstone]

Keep it above the belt please, lets have healthy debate, state your 
position and be prepared to back it up with evidence or patches, not 
insults, have respect for each others position, so decisions can be made 
and we can move forward.  Otherwise you risk becoming part of the 
problem instead of the solution.

Our current focus is making the River build and test processes easier 
for new developers, which on a more positive note, is making progress.

Peter Firmstone.

Sam Chance wrote:
Well, if you aren't excited about OSGi as a module system, then what
about SCA as an assembly model?  SCA is language- and
technology-independent. It's being used to build composite systems
comprised of heterogeneous components.

I really hadn't thought of using OSGi bundles to represent
configuration or properties documents. I've only 'seen' it used to
deploy functional software. In fact, OSGi standardizes metadata in the
manifest file of a jar/zip file. The runtime then uses the metadata to
manage the dependencies, imports, exports, etc.

Developers I know who've been introduced to it resonate with it.
Management likes it as a way to normalize/standardize software modules
(i..e. pre-built, pre-tested, pre-approved components).

I don't know. I think its adoption is past or almost past the knee of
the curve.

Sadly, Jini is somewhere in the white noise. I believe OSGi could
bring a resurgence of Jini/River. And to be frank, I feel like Richard
Nicholson and his team at Paremus are the only ones who 'get it'.

To be sure, however, the languishing nature of the Jini technology and
the lack of a forward leaning vision with enthusiastic, committed
developers forging the vision has lead to the current state of
obscurity. We can't even figure out how to pay a sub $300 bill.

Accordingly, Jini/River is unlikely on anyone's radar, much less
critical path. I highly doubt, Paremus, for example, is critically
dependent on it. No one can afford to because of things just mentioned
and the fact that Jini veterans cling defiantly to a myopic view that
steadily drives it into the grave.
Wow, that's pretty harsh! I must have pent up frustration or anger issues! :-)



On 6/26/09, Gregg Wonderly <gr...@wonderly.org> wrote:
  
On Jun 26, 2009, at 11:18 AM, Sam Chance wrote:

    
That's a very emotional reply. :-)  I don't share the same "IBM
domination"
view.  One can kick and scream, but the fact remains that the
largess is
moving to or has already moved to OSGi.  Sorry.

You can stay on your path but you will increasingly find yourself an
outlier.  It's a high risk, high reward proposition.  The customers I
support use IBM, Oracle, Sun, Red Hat, SpringSource, TIBCO, etc.
They also
use open source things like FUSE, Jetty, Tomcat, Apache _____, etc.
Most,
if not all, are going to OSGi or are already there.

Your assertion that "OSGi from the outside doesn't seem to be "adding"
anything... [you] need..." suggests you may not fully understand
it.  I
could be wrong.  OSGi is certainly not a competitor to Jini, but
rather an
exceptional complement. Further, your own "interests" suggest you
would
embrace OSGi and SCA.

Anyway, my aim is not to convince, but rather illuminate.
      
I appreciate your perspective Sam.  I'll add some more of mine.

I provide products/services to my clients, and they use many of the
things that you list.  My services utilize things like JDBC for oracle
access, I don't see OSGi visible in that API, but I guess one could
elect to use an OSGi package to "document" the parameters for access
to a database server, instead of something like a properties file, or
a jini Configuration.  I've used Jetty (see http://
jetset.dev.java.net) to allow me to deploy a servlet into a
com.sun.jini.start configured set of services.  There are lots of
different places that I've "configured", "packaged", "described" how
things work together, and that is, for me, more often than not, the
simple part of what I do.  I try to use existing and appropriate
"standards" for these types of things so that I can "fit" my services
into a framework of configuration and manageability that is
appropriate for my customers.  I don't see that OSGi adds enough
value, for me, to get excited about it.  Primarily, it greatly changes
the "foundation" of what I will do, and how I will do it, in a way
that just seem like "change", not value.

Statements like the following (off the OSGi website), highlight, for
me, the fact that there is nothing "defining" and "exciting" about
what OSGi is doing.

Explaining OSGi technology to those unfamiliar with it is remarkably
difficult. There are numerous articles on the web that somewhat
indignantly tell you that there is no good explanation of OSGi
technology and that the article will solve that. Unfortunately, quite
often the articles still fail to explain it to absolute newcomers
because OSGi technology provides solutions to problems that many
people simply see as intrinsic aspects of software development in Java
and would not call them problems.

This, seems to say, we've been around, do something for so long, and
without really trying to solve a problem, that we have a lot of tools
for a lot of people to use, and if you can get some value out of all
this work that we've done, we think you like that.

Gregg Wonderly