river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <...@dcrdev.demon.co.uk>
Subject Re: Apache River Roadmap
Date Sat, 10 Feb 2007 11:02:31 GMT
Mark Brouwer wrote:
> 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.

In your opinion Jini is a technology, not a product.  Perhaps other
people don't view it the same way?

Perhaps other people think it needs to be more "productized"?

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

No, you shouldn't dare to say it because you would then be seen to be
speaking on behalf of other people with apparent authority.

> 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

And we will continue not to get a share of that cake until we get
sufficient "gravity" to encourage that change and we won't get that kind
of gravity if we sit on the side.

You can either accept the world is the way it is or go out and change
it.  Personally I've never been good at acceptance of the status quo.

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

That is until you explain some core benefits of the other services at
which point people get it and buy in.

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

Why would I bother to put a spec into River?  If River is going to be
this small in focus, I'll develop services and API's elsewhere without
bothering to do specifications.

Then I'll wait for the day users ask me to put a spec into River which I
think is a good deal less likely than them asking me to contribute the
service itself to River.  And I think that's less likely than them
continuing to use my service and asking me to enhance it independently
of anything in River because they see that as the fastest way to get
something done rather than being dragged down by the red-tape of working
within River.

I think another interesting question to ask is, what is it about River
that would make it an appropriate body for handling/developing specs?

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

Boring == few developers == project that doesn't need to be at Apache
with high visibility and might as well sit on SourceForge in a dark corner.

It might be successful to you but IMHO, having such a thing so visible
at Apache will be a PR disaster:

"Some quiet little project at Apache that no-one's interested in, that
has a couple of committers tinkering away on little things that no-one
appears to care about.  Wow, is that all there is to Jini?"

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

Personally, I see plenty of opportunities for Jini coming over the
horizon.  I spend a lot of time convincing people of it's utility
successfully whilst constantly having to drag behind me a largely
developer unfriendly core which makes the whole process less efficient
than it should be.  There's another class of developer that can see the
benefits for themselves (after putting in far too much hard work to
understand) and then run into the brick wall of the core.

If we are indeed never going to be mainstream so be it but we are
currently failing to convert the small group of interested people into
regular Jini users because of the obstructions we have.  And that means
we have even less adoption than we should have and with fewer users, we
have less feedback and less direction to follow.  And with less
direction, we have fewer developers wanting to become committers. And we
are _failing_.

The kinds of minutae (e.g. PreferredClassLoader changes) we've talked
about thus far will not address any of these problems.  If River is not
going to tackle any of these problems it will be largely irrelevant and
worse, anyone trying to address these problems elsewhere could be
baulked as River goes off in some other esoteric direction.  If River
wishes to be this irrelevant it should go somewhere less visible and
allow some other project to take advantage of the visibility Apache
gives us.  Or what is currently River should become a small, quiet
sub-project of some much bigger thing deserving of and able to leverage
the kudos of being an Apache project.

If what you describe is the destiny of River as a user and committer, I
see minimal value in what the project will be doing.  I might as well
take a simple snapshot of the source code and then evolve it and package
it independently in a direction I find more useful to customers/users
whilst avoiding the need for endless debate with people that want a
small quiet project that does little.  I'd also be crossing my fingers
that I can attract attention away from River to avoid the PR disaster I
mention above.  Kind of sounds like the behaviour of a number of
commercial Jini efforts out there using but preferring not to talk about
Jini, why?

My two cents,


View raw message