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. So if the "language" doesn't do it, it doesn't
seem to be interesting. JavaEE is a platform that is "standardized". Jini is a
platform that is "standardized", just not by Sun, IBM, Oracle or any of the
other big JavaEE behemoths.
There was the whole "java is not open source" movement that drove the "I'm an
open source developer" development toward "web pages should be used for every
UI", because then they weren't making their friends developing new languages for
simple silly web page tasks feel bad. Sun developed the silly business
of thinking (well there was actually just one person at the top of Sun that
created this problem and Jonathan fired him for not wanting to open source Java)
that web pages solved all problems, but that was too little too late.
Over the years, Sun focused their support of Java JSRs on nothing but huge,
ugly, completely insane software systems in JavaEE that require nothing short of
mammoth machines and software packaging systems to get useful things out of the
JavaEE applications. I shutter at the thought of how many useless man years of
intelligent design time got wasted...
I was on the Sun developer advisory council for years, 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. Mr. Green tried to make sure we knew
that Sun was focused on JavaEE.
In the end, so many people find it more acceptable to use XML based data
encoding and transport, rewritting/repackaging 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 have worry about during development. One is security, the other
is mobile code management. Since the configuration of these things are don't
strictly done programmatically with language features, out of the box, people
get frustrated and overwhelmed with details that they have to manage. It's all
over the list here and on the internet too. The abstractions that are in place
to create the platform are not fleshed out in concrete, usable classes, for all
the more typical scenarios. Instead, we have X.500 and Kerberos authentication
which just doesn't sit around on everyones network, ready to go and fully
managed and configured to work at the moment it's needed.
When Java1.4 came out, JAAS was there, but with completely useless login
modules. The provided OS login modules do nothing more than go and get
credentials from the OS for who the process is running as, and provide those in
the returned Subject. There is no authentication provided. The OS login
modules should have provided for authentication so that you could say, this user
is allowed access to this system and here's the authorized principals that
apply. But no, that wasn't possible because Sun engineers thought that people
writing applets might exploit it by running background loops trying to
authenticate by exhaustive search while web pages were open with invisible
applets running, and that would then allow people to exploit that knowledge to
get into authenticated networks. There was a security model in Java which could
keep this from happening. The login modules could have used the SecurityManager
to control things.
Look around at some of the things started early in our community, where these
issues are "buried" into deployment systems (com.sun.jini.start) and containers
(RIO, Seven, etc) , 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, we have no
ability to say that there is a level playing ground or equal opportunity for
deployment needs. I don't want to demean anyones work at trying to solve the
problems they have with these projects. I'm just saying that because they've
evolved in lots of different directions with regard to configuration, that we
have lots of ways to configure things with varying capabilities and it means
that no one can move anything anywhere else trivially, and thus things are going
to remain fragmented, forever, from my perspective. Just to make it clear, I
feel that the disparate state of configuration and deployment in Jini is like
saying I have a check balancing service to your friend who has linux, and then
saying, ohh I wrote it for the MAC, you'll have to port it.
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 a 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 codebases.
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.
Different mechanisms and details like this mean that the way you package your
service has implications on how it works in other peoples environments! My
solution is at the network layer so that it works for all codebase. Mark's
works at the classloader layer so that it works with Jars composed in particular
ways. We each have found different, working ways, to solve problems, but
compatibility is at different layers which creates incompatibilities at other
layers.
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
containers that have different operating base environments.
We really, really, did I say really yet, need to make some decisions about
packaging and container interfaces 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. People can put in
compatibility layers for their existing systems to meet with those standards if
they so choose.
As a community, we are not making many 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. But, clearly, most if not all of them have other
responsibilities, if not interests now.
What we need to do now is get moving on making the system easy to use. There
are packages of things in the communities efforts that we can make into standard
parts of the River distribution. From my viewpoint, JavaEE is starting into a
spiral path out of "preference" because more simple ways to do web apps are
falling into view as the frustrated people decide enough is enough. If we make
some of the hardest parts of River configuration and deployment much more
manageable, we have the opportunity to finally get the attention of the people
who are searching for the next solution, since what they last tried is not working.
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.
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 able to and where needed.
Gregg Wonderly
