river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: OSGi and Jini
Date Mon, 29 Jun 2009 20:20:10 GMT
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.

I do see it "around", but I guess I'm not seeing it "everywhere" in a way that 
makes me feel like "it's not leaving" yet.

> 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'.

They understand a lot about both systems, clearly, and have put together a 
package that seems to be a great step towards integrating both.

> 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! :-)

Here's another "my perspective" "rant".

Frankly, I believe what is killing small package, easily reused software 
development is the "everything is just a web page" mindset that all the new 
"software developers" are toting around on signs.  The driving force, I believe, 
is the "your language doesn't do what my language does" mentality that is driven 
by the ignorant who think that if you can't type it in text without a library 
loaded to support it, then it's not a "language feature".   People want their 
lives to be simple.  They want to carry around as little extra "stuff" in their 
development "kit" as they can.

There was the whole "java is not open source" movement that drove the 
development of "web pages should be used for every UI", and Sun's silly business 
of thinking (well there was actually just one person at the top of Sun that 
created this problem) that web pages solved all problems.  Sun focused on 
nothing but huge, ugly, completely insane software systems in JavaEE that 
require nothing sort of mammoth machines and software packaging systems to get 
useful things out of the JavaEE applications.

I was on the Sun developer advisory council, as were about 6 other Jini people 
as I recall (who regularly attended until it disappeared last year without even 
a goodbye or thank you).  We hounded those folks over and over at the complexity 
and ugly nature of JavaEE.

In the end, so many people find it more acceptable to use XML based data 
encoding and transport, rewrite it for every language and every platform that 
needs a tweek.  They then start buying packages that do the work for them when 
it seems that it really is quite expensive and costly to get "right" after so 
many times doing it.  They eventually discover JavaEE tools and IDEs that "do" a 
lot of the work for you, and then figure out that well, they don't quite do it 
all, quite right, and then they start patching and moving away from the tools 
into privately maintained, ugly codebases, still swearing that it works great 
for them.

Jini, as a simple system, has a couple of very complex issues, which people 
don't want to worry about.  One is security, the other is mobile code 
management.  Look around at some of the things going on in our community, where 
these issues are "buried" into deployment systems and containers, and you can 
see incompatible differences in "where" and "how" these things are managed.

The end result, is that because the community won't decide on a "standard" 
container, other than the built in com.sun.jini.start package.  That package is 
quite usable if you like to hand edit configs, or have written tools to do it 
for you.  There is a simple life cycle management thing.

My org.wonderly.jini2.browse.JiniDesktop class in the 
http://startnow.dev.java.net project provides a simple ServiceUI client desktop 
that utilizes several other things that I found valuable in managing the load on 
the network and the startup time of the client UI when there are 100s of 
services to discover and downloading everthing in the codebase is slow.

Mark Brouwer uses a different strategy of packaging his codebase in a way that 
the PREFERRED.LIST is in a jar with minimal size, and that jar "includes" 
references to the other jars needed, or he has multiple jars on the codebase list.

We don't have standards in Jini for packaging and deployment of services and 
codebase jars.  We don't have things that allow people to move between contains 
that have different operating base environments.

We really, really, did I say really yet, need to make some decisions and move 
on.  We need to have a WAR like file that is the "service".  We need to have a 
more simplified "base security" setup which uses "user logon" credentials, not 
explicitly specified certificates and other hard to maintain and manage bits of 
information.

As a community, we are not making any decisions because Sun has been the 
caretaker of Jini.  The Sun Jini folks have done an amazing job of creating some 
very useful software that is, from my perspective, a great platform for 
distributed systems.

What we need to do now is just get moving.  There are packages of things that we 
can make into standard parts of the platform as it is packaged here.

What happens next is what the community decides.  I'd like to play a part, but 
to date, everything that I've found to be interesting and wanted to do 
differently in Jini has not been that interesting to the rest of the community. 
  So, I'm setting back, waiting for something to start rolling that I am 
interested in, and I'll jump in to assist as best I can, as I am needed.

Gregg Wonderly


Mime
View raw message