Apache River - My Lowly Impression

["Jeremy R. Easton-Marks" <J....@gmail.com>]

First off let me say I am a huge fan of Apache River, and its predecessor
Jini. I even have a Jini leather jacket. :-) I think this technology has a
lot of potential to do some amazing things especially in my area of
interest, distributed computing. I think the people who are working as
developers on this project have done an amazing job.

That being said great technology all the time does not mean that it will be
used or even noticed. I think River is lacking in certain areas that has
nothing to do with the programming, or the ideas behind it. The following
list of things is not meant to assign blame to anyone, or anything. These
are just things that I think need to be addressed in my very humble opinion.

1. *Accessibility*
River is an incredible concept, but the conceptual ideas can be daunting to
people starting out with it. I think explaining the concepts by using real
world examples, this could attract more people and make River more
approachable. As an example I found the explanation behind the MapReduce
incredibly easy and I was able to get a system setup, tested, and run in a
few hours. It provided some great examples, as well as explained why they
worked. Furthermore it explained some real world cases for using it, such
as log querying.

Increasing the ease of people approaching Jini will probably increase the
number of people/companies who want to be involved in it.

I would love to start playing around with River but I don't know how to
start. The "Getting Started" page says that I need to check out the code
from SVN trunk, and build it myself. Has this changed?

2. *River Site*
The site itself doesn't provide much information about the project except
that it has been released. When I explore a little deeper I noticed some
broken links to sites including the links to original Jini documentation,
and the link to Jan Newmarch Jini tutorial is broken. This directly impacts
the first impression that people get when they are looking into River. Is
anyone in charge of the site?

3. *Roadmap*
What is the future of River? What is the overall goal of each point
release. What about goals for major releases?

I think if we come to a general consensus on what are goals are we can move
forward together as a group of programmers since we all know where we are
heading.

4. *Mission*
One of the overall thoughts I have had while reading the correspondence in
the group is that I don't know what the mission is? I know the group is to
continue the development and advancement of Jini technology but that is a
very broad and generic statement. Does this group want to help people
implement the technology, only work on the specifications, what level in
the tech stack does River start and stop, or is some combination of all of
these?




Are any of these things the group as a whole interested in implementing?
What are your feeling on this?


As a side question: Could something like the Hadoop YARN be implemented
using River?


-- 
Jeremy R. Easton-Marks

"être fort pour être utile"

Re: Apache River - My Lowly Impression

[Dennis Reedy <de...@gmail.com>]

On Jan 21, 2014, at 426PM, Greg Trasuk <tr...@stratuscom.com> wrote:

>> 
>> 
>> As a side question: Could something like the Hadoop YARN be implemented
>> using River?
>> 

Hi Jeremy, 

Yes, I think you should be able to do this. The "River" way I think is a bit simpler because it does not require the use of a Resource Manager or a Scheduler. The common pattern here is a worker pattern (check out an example here http://www.rio-project.org/examples/workflow/index.html) where Workers are hungry and take as much work as they can handle. Workers on faster machines naturally consume more, work can be transactional. Workers take work based on registration of a "template" (obeying class matching semantics), and are generally configurable based on the number of CPUs.

A side suggestion: You could also use Rio (http://www.rio-project.org) for the development and deployment of your services. Rio provides an easy to use, out of the box approach to create a multi-module project that includes a testing framework all easily integrated with Maven. Rio uses River for dynamic discovery, remote events and leasing of resources through the network.

HTH

Dennis

Re: Apache River - My Lowly Impression

[Greg Trasuk <tr...@stratuscom.com>]

Hi Jeremy:

Thanks for the feedback.  I’ve added some comments interspersed below…

Cheers,

Greg Trasuk

On Jan 21, 2014, at 3:30 PM, Jeremy R. Easton-Marks <J....@gmail.com> wrote:

> First off let me say I am a huge fan of Apache River, and its predecessor
> Jini. I even have a Jini leather jacket. :-) I think this technology has a
> lot of potential to do some amazing things especially in my area of
> interest, distributed computing. I think the people who are working as
> developers on this project have done an amazing job.
> 
> That being said great technology all the time does not mean that it will be
> used or even noticed. I think River is lacking in certain areas that has
> nothing to do with the programming, or the ideas behind it. The following
> list of things is not meant to assign blame to anyone, or anything. These
> are just things that I think need to be addressed in my very humble opinion.
> 
> 1. *Accessibility*
> River is an incredible concept, but the conceptual ideas can be daunting to
> people starting out with it. I think explaining the concepts by using real
> world examples, this could attract more people and make River more
> approachable. As an example I found the explanation behind the MapReduce
> incredibly easy and I was able to get a system setup, tested, and run in a
> few hours. It provided some great examples, as well as explained why they
> worked. Furthermore it explained some real world cases for using it, such
> as log querying.
> 
> Increasing the ease of people approaching Jini will probably increase the
> number of people/companies who want to be involved in it.
> 

Yes, we definitely need to do a better job with the introductions.

> I would love to start playing around with River but I don't know how to
> start. The "Getting Started" page says that I need to check out the code
> from SVN trunk, and build it myself. Has this changed?
> 

Yes and no.  There certainly is a binary distribution, so you don’t need to build from source.  Also, the binaries are now in Maven Central.  But it’s important to remember that the original donation from Sun was the “Jini Technology Starter Kit”.  We in the River project need to move beyond the starting point.

There’s a server in development - you can check it out at:
   https://git-wip-us.apache.org/repos/asf/river-container.git

Right now it’s not released in source or binary, but it does work to setup a Jini environment including Reggie and a service browser.  Instructions are in the readme file (https://git-wip-us.apache.org/repos/asf?p=river-container.git;a=blob;f=README.md;h=23a59d73fa1c0dc099a27f34beedb7604f8265bb;hb=4b3b01a6182f416c4a1b3e01462d087140f49255).

There is an example service and client at https://github.com/trasukg/river-container-examples.  If you could spare a few minutes to check it out I’d love to hear feedback.

> 2. *River Site*
> The site itself doesn't provide much information about the project except
> that it has been released. When I explore a little deeper I noticed some
> broken links to sites including the links to original Jini documentation,
> and the link to Jan Newmarch Jini tutorial is broken. This directly impacts
> the first impression that people get when they are looking into River. Is
> anyone in charge of the site?

Do I hear a volunteer?

> 
> 3. *Roadmap*
> What is the future of River? What is the overall goal of each point
> release. What about goals for major releases?
> 
> I think if we come to a general consensus on what are goals are we can move
> forward together as a group of programmers since we all know where we are
> heading.
> 

We haven’t done a good job reaching concensus on the roadmap.  This is an area we need to work on.

> 4. *Mission*
> One of the overall thoughts I have had while reading the correspondence in
> the group is that I don't know what the mission is? I know the group is to
> continue the development and advancement of Jini technology but that is a
> very broad and generic statement. Does this group want to help people
> implement the technology, only work on the specifications, what level in
> the tech stack does River start and stop, or is some combination of all of
> these?
> 

What follows is my humble opinion…

I’ve been teaching courses in traditional XML-based Service Oriented Architecture (SOA) to corporate clients for several years now.  I always ask “What languages do you use in production?”  It’s a funny thing - without fail, the vast majority of people say “Java”.  So I wonder why we go through all the convolutions of XML Schema and WSDL, when we end up coding everything in Java?

That’s where I see Jini and River - Java-based SOA.  I’d like to see us promote Jini and River as a pure Java-based infrastructure for building service oriented architectures.  I see it primarily in the data centre and on the LAN.  I’ve used Jini successfully as the back-end for Swing-based desktop applications as well.

> 
> 
> 
> Are any of these things the group as a whole interested in implementing?
> What are your feeling on this?
> 
> 
> As a side question: Could something like the Hadoop YARN be implemented
> using River?
> 

Hadoop is on my list of “things to look into”, so I can’t really answer that.  What I can say, however, is that it’s  almost trivial to implement map-reduce style master-worker patterns using Jini and JavaSpaces.  What I suspect we are missing is the capability of automatically distribute code to the cluster members and schedule jobs.  River would be a good platform to build on, given the dynamic nature of the service architecture.  I believe Dennis Reedy and the Rio project have done a lot of work in this area.  There used to be a “compute-grid” project on the old “jini.org” but I don’t know if it got moved somewhere.

> 
> -- 
> Jeremy R. Easton-Marks
> 
> "être fort pour être utile"