river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: Apache River Roadmap
Date Fri, 09 Feb 2007 10:43:33 GMT
Hi Mike,

Thanks for sharing your opinion, it is really interesting to see how
other watch this pass by.

Herrick, Mike wrote:
> Hi,
> 
> I'm a Jini/JavaSpaces newbie.
> 
> I've been observing a bit on this list and am quite excited about the
> potential of Apache River.
> 
> I lived through years of J2EE, SOA, ESBs, etc. and could have lived
> through years of Jini/JavaSpaces - this saddens me.
> 
> I view Apache River as the second (and likely final) chance at taking
> Jini/JavaSpaces mainstream. I saw somewhere on this list someone
> question if this was even a goal. Seems rather insane to me for it NOT
> to be the goal.

I have no clear view what I want to say to you, besides that I only want
to show that we at Apache River might be facing an expectation problem.
Jini is a technology and not a product and as such it requires a
buy-in by people of the philosophy and concepts.

Jini getting mainstream acceptance would mean that (going back to 1999)
people envision Java (as in bytecode) everywhere and Jini as the vehicle
to bring services (that allows for proxies based on bytecode) and
although many people don't dare to say it the Jini Platform everywhere too.

Looking at 2007 I see that Java is not everywhere, we have a huge amount
of PHP, Perl, Python, Ruby, etc. code running that will never be able to
speak to Jini services and for that reason many people prefer shipping
plain data (XML, JSON, etc.) that can be parsed/read/interpreted by any
language. So we've lost a huge piece of the cake here, I can only hope
that in the future those (often dynamic) languages move to the JVM such
as with Jython, JRuby so that it would possible to win them back
(anybody wants to do a proof of concept for "JRuby on Rails talking to a
JavaSpace"?).

So that leaves us to Java based systems, well for Jini you need to have
the Jini Platform available and as many of us know a general J2EE
application server is a crippled environment due to the fact that what
Jini requires hasn't become a core part of J2SE and in none of the J2EE
specfications you can see they have even thought of the concequences of
having mobile code (it is just an implementation aspect). Java SE/EE
took a road in favor of the component model instead of the (mobile code)
service model, although nowadays you get your data shipping SOA (web
services) for free as part of the core. And don't forget J2ME which is 
also not a Jini friendly environment.

So we have lost another major part of the cake. From what is left there
are still many places where Jini could be utilized but I begin to doubt
whether I can call that mainstream and can be targeted as such. You can
write vertical frameworks for which you might get thousands of people
applauding but I won't call that mainstream and I won't call that
Jini, it will merely make use of Jini.

Sure it will be possible to buy-in a bit more people with better
documentation (such as patterns), but still I have a feeling that no
matter how much documentation we write most people won't understand the
value if they don't see it right away after reading JiniTM Architecture
Specification
http://java.sun.com/products/jini/2.0.2/doc/specs/html/jini-spec.html
, or the spiced up versions of it. I'm not going to discuss the
documentation of the starter kit, because IMHO it ain't a starter kit
for those that want to write a Jini service in 10 minutes, writing more
documentation won't get them up to speed any faster I guess.

Here I take some shortcuts, but I think the fact JavaSpaces gets all the
attention is because in the eyes of many it is the only Jini service
that brings value to them (the others are just because you need them to
work with JavaSpaces). There are no other compelling services or you
have to write them yourselves.

So maybe the way forward would be the availability of more types of
services. E.g. why should I use a JavaSpace if I really want to have a
high quality distributed FIFO queue, or why do I have to write my own
Log service, etc. etc. As soon as the portfolio of Jini services grows
we might attract people looking out for that kind of functionality.
Utilizing more services might inspire them to write their own systems
more in line with the Jini philosophy.

There are a few things that would make the creation of those services
easier and there are various initiatives around the globe, so I don't
believe this is an area River should focus on without proving that
these are not adequate. Although as I said before, if there are a bunch
of people who want to do that as part of River I doubt whether I'm in
the position to say they shouldn't.

Personally I hope we could focus on improvement of the basic
infrastructure what I always tend to call the Jini Platform plus things
that are of great value to anyone such as the Jini utilities (decent
utilities is something River is a nice repository for) and I hope in
time it can become a breeding ground for new great Service
specifications such as Queue service, Logger service, etc.

But I doubt whether any of the above is something that directly
correlates to making Jini mainstream and I really doubt whether Joe the
programmer (BTW nice piece Sean) will get a cozy feeling by.

It might turn out that River ends up being a boring (in terms of action)
low level project that delivers the foundation for all those exiting
things going on elsewhere. If that is the case Apache River is still a
successful project in my eyes, even while it stays very quit on the
users list.

> etc.? There is a lot of buzz around Jini/JavaSpaces right now - people
> are watching and the clock is tick tick ticking.

Clocks are always like that, and wise men never wear a watch and/or read
TSS ;-P

> I mean no offense, I know there are issues being worked out with getting
> the code free and clear etc., but how about making a goal of having a
> DRAFT Road Map for year 1 in say 2 weeks from now? Not everyone has to
> agree, but something - a first rattle out of the gate. Something here
> other than what is there now:
> http://incubator.apache.org/river/roadmap.html
> 
> Step 1: March 1 - Working build with Apache River package names (or
> something) 

I hope this is just an example? Changing the package names will have
a huge impact and consequences for all current users and for those who
built upon, wrote books, articles etc. against the Sun implementation of
the Jini Standards. To me this seems to be a task I want to postpone to
2 minute before asking for graduation to TLP.
-- 
Mark




Mime
View raw message