river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Chance" <sgcha...@gmail.com>
Subject Re: Future of Jini/River
Date Mon, 10 Nov 2008 14:45:12 GMT

I'm typically a lurker, just watching to see what deployment/operational
issues emerge that inspire healthy discussion on the list.  However, I
occasionally pop in and offer my humble opinion.

There are a few topics I'll add into the mix that I think could make
Jini/River gain some prominence.  These might include a visual,
browser-based lifecycle service management, explicit use of OSGi technology,
and/or the seemingly allusive killer app.

Firstly, I'll mention a couple of dynamics that I believe continue to hold
Jini down.  As a point of fact, when I mention Jini, it's always in the past
tense.  For example, I might say to someone, 'Do you recall Jini?' or 'Have
you ever heard of Jini?'  Usually they acknowledge in a 'weak affirmative';
however, they may or may not actually know to what I'm referring.  One
really sad fact is that no one who has been part of the community will jump
up and down screaming that we need to do something.  It seems every time the
"future of Jini" topic is raised the 'community' simply defends the status
quo.  It's almost like a self-licking ice cream cone, and the folks who make
the ice cream are happy to eat the ice cream.  Accordingly, the
(exceptional) technology remains stagnated in mediocrity and relative

We can't even seem to get Jini/River adopted as a SOA framework. I've seen
no efforts to create and market a River-based BPM/Orchestration capability.
Is there any Web 2.0 type application? What about Web 3.0 and linked data?
Better yet, what about "linked services"?  What about dynamic service
"publish, find and bind" (PF&B) over the intranet or even internet?

We had a visual Jini IDE called IncaX that was, I thought, an awesome
capability that never really got hardened and adopted by the community, much
less the outside world.

I struggle to fathom there remains no browser-based (AJAX) management
framework!  If there is one, please excuse me and show me the link. In
today's world, it's a minimal requirement.  That's something the whole
community could rally around.

 We had (have?) Seven.  We have, I think, RIO.  GigsSpaces? Infiniflow?
Those are either exeedingly obscure in the mainstream or are COTS.

If any of you, who are much smarter than me, have looked at OSGi technology,
one of the first things that SHOULD scream at you is the exceeding symmetry
between Jini and the OSGi service platform.  To my knowledge, only Paremus
has the vision to leverage that symmetry.  And guess what?  I'm doing all I
can to help their cause!

We have Bantam which is another creative use that facilitates dynamic PF&B
over HTTP.  But of those who know about it who is helping build it out?  Who
is helping market it?

We say Jini is protocol agnostic, but to my knowledge, only RMI is
implemented.  We need other bindings, like an ATOM binding.  How "Web
2.0'ish"! What about REST? SOAP?

At the end of the day, all these would probably work, but the community
seems content to remain "within itself".  It fails to coalesce around any
particular vision.

So I offer a vision:  Using River, build an internet scale, decentralized,
autonomic, dynamic PF&B service management APPLICATION that is browser base,
OSGi technology based and Service Component Architecture (SCA) based.  The
framework should allow rapid creation and deployment of services.  The
binding protocol should be based on ATOM or something similarly open.  It
shoud allow end users to build ad hoc worklfow by combining services.  It
should not be wed to SOAP, but allow SOAP.  It should allow REST also.

That is a River that allows all manner of things to flow through it!  :-)

Thank you!

On Sun, Nov 9, 2008 at 11:50 PM, Niclas Hedhman <niclas@hedhman.org> wrote:

> Taking this on-list, which I perhaps should have done in the first
> place. Never-the-less,
> On Mon, Nov 10, 2008 at 12:17 AM, Dan Creswell <dan@dcrdev.demon.co.uk>
> wrote:
> > For a long time now, I've been waiting to see a conversation around
> > "what next for River".  This is something of a good start but....
> People don't like to work alone and 'against all odds', so I think all
> of River's problems are related to a couple of real problems;
> * It is perhaps too complete! Not that many things that is in
> desperate need of repairs.
> * Overload of Information and Technology Fracture. We have a million
> documents, a couple of sites, dozens of related projects that are
> spread out and for a newcomer it is unclear what is essential, useful
> vs not initially relevant. It is in fact the total opposite of most
> projects at Apache.
> * Corporate Approach to software distribution. You get something that
> you install and use, pretty much like a big fat database, application
> server or similar. Modern developers, often test driven and agile, are
> not fond of "System Requirements" when writing their own software.
> "Check out, compile, run tests" is the motto for many, me included.
> For Jini, it means it is hard to create other open source projects
> that depends on Jini. The downstream users have to do too much to get
> going. This is probably my pet peeve at the moment.
> These things are not very concrete. We need to make River more
> accessible for non-hardcore Jini users. It must be easy to "see the
> light" (samples), "to touch the light" (try yourself) and "follow the
> light" (embrace) at a very fundamental level. Jini applications
> doesn't live in a vaccuum, the technology must be easier to integrate
> into other projects. The hardline view that "we are best and everyone
> else should learn from us" ain't gonna cut it.
> My own view is that the following areas are first up for review and
> rectification;
> * Build System. It must be a breeze to build and test River itself.
> The current split between tests and source code should IMHO be
> eliminated, tests should be executed on all builds, and I think we
> should break up the sources into modules instead of a single large
> src/ dir with everything in it. If people wants to move towards Maven,
> I will support that, primarily since it simplifies artifact
> consumption for downstream projects. Same thing can however be
> achieved with Ant.
> * Right-sizing of the Jini Starter Kit. IMHO, the JSK is a misnomer
> unless you intend to write your own Jini implementation of the
> Specification services. I think that Apache River could just organize
> the whole project better, to get around this problem altogether. I
> think we can see a "infrastructure product" separate from the
> "developer's tools".
> * Configuration System. Although I like it in principle (after all I
> was in the JSR-78 EG where it came to light in the first place), BUT
> it needs better adjustment to agile and TDD methodologies. Perhaps it
> is only a documentation issue, but I have been faced with using
> filesystem files to get things going. InputStreams are the way to go.
> * Security System. Although extremely important in many scenarios, the
> impact on developers for Jini is too big, too soon. Needs to soften
> that up in the documentation, which currently deals with experts and
> novices alike.
> * RMI & JERI, Activatable, Persisten or Transient... Duhhh... Give me
> choices that I initially don't care about, and I give you a system
> that is booted out from the candidate list. The information around
> what each means is overwhelming. I would say that RMI has such
> (undeserved IMHO) bad reputation that drop it out of the mainstream,
> push JERI as "The Java Binary Communication Layer", and IIRC it is
> well suited to have other serialization protocols than std Object
> Serialization Streams, which would allow people to experiment, measure
> and conclude the true story around serialization (what ever that might
> be). So, big tasks in place to make JERI more easily consumable.
> * River/Jini 3.0. I think a healthy community needs lofty goals. At
> ApacheCon Europe 2008, Roy Fielding was talking about this for Apache
> Web Server. He basically called for "next level" of what is possible,
> put up serious ambitions and 'screw compatibility' to get there. I
> think River could start flowing if some discussion is created along,
> "What's the Next Thing?" and see where that leads us. I can imagine
> Clouds, Distributed Storage, Network Graph Navigation/Search, new
> "Distributed Worker Model", maybe even standard solutions for load
> balancing http traffic. Well, I am sure there is a lot to discuss and
> dream about. From those dreams come itches, the itches get scratched,
> and so on...
> All in all, I love Jini, but I think the current situation stinks and
> if we (those who care) don't do something really soon, it will be a
> blip on the radar of Java history. I can unfortunately NOT be the
> driving force behind the technology. First, I lack the know-how
> required, and secondly I am tied up in a really large open source
> project (http://www.qi4j.org), but where I hope to use Jini/River as a
> distribution platform. So I could help out in various areas, just to
> make my own situation more bearable (scratch the itch).
> Cheers
> Niclas

Sam Chance
443-694-5293 (m)
410-694-0240 x108 (o)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message