I think there really is no serious question that OSGi is a huge
advancement beyond the horrid Java class loading default model. Greg,
so far as I can tell you are willing to go down with the ship and are
against all change. I doubt if many will have the desire to battle
your tremendous and admirable energy in support of the status quo.
Sent from my iPhone
On Jun 29, 2009, at 6:51 PM, Gregg Wonderly <[email protected]> wrote:
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
