river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: OSGi and Jini
Date Sat, 27 Jun 2009 10:54:06 GMT
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 <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
>>     
>
>   


Mime
View raw message