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
