river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Chance <sgcha...@gmail.com>
Subject Re: OSGi and Jini
Date Sat, 27 Jun 2009 04:07:16 GMT
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 <gregg@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

Sent from my mobile device

Sam Chance
443-694-5293 (m)
410-694-0240 x108 (o)

View raw message