Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of pdoubleya@gmail.com
 designates 74.125.78.147 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=STFcVLLmaBRGN9KNYmHPtlp6dKn2Mc37guGADxRElMxgbL/CEcvhztfNV5OA4PLlrV
         oaV/51EVJhsYAqeoWwQeVho3M1+NYBFetKHM4+ujSL0nEkNL0kOE+Z4pJUl6VPcC0B2I
         H6rWpozLVuXhHE094v2dMNrq70d/8EKhKT758=
Message-ID: <64efa1ba0809031318k578771a7n8bea036d276317ca@mail.gmail.com>
Date: Wed, 3 Sep 2008 22:18:18 +0200
From: "Patrick Wright" <pdoubleya@gmail.com>
To: river-dev@incubator.apache.org
Subject: Re: Jini, JavaSpaces, JEE, some questions,
 and some other development issues and ideas.
In-Reply-To: <447369.12432.qm@web33807.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <447369.12432.qm@web33807.mail.mud.yahoo.com>

Hi Wade

On Sat, Aug 30, 2008 at 2:31 AM, Wade Chandler
<hwadechandler-apache@yahoo.com> wrote:
> All,
>
> If one were formulating an argument for the use of Jini and JavaSpaces versus JEE, what exactly would the decision maker be? I know you can use JEE inside Jini services, and thus they are complimenting each other in this regard, and then Jini services can be discoverable, but is that the real beauty of Jini versus EE? I guess I'm having a hard time reconciling why I should want to really dig into Jini more versus just continuing to use EE.

I'll give you our perspective, since we evaluated just this choice
about two years ago after deciding to move our platform more
aggressively towards a services-based approach.

First, we don't use JavaSpaces. We haven't found a use-case in our
situation that would appear to benefit from it, and we use JMS for
asynchronous messaging. We did some performance comparisons of JMS vs.
JS and for straight message-passing performance, JMS was a clear
winner. But that was also because we didn't have a need for posting
and finding entries, for example, so weren't comparing on that basis.
We're not adverse to it, but are waiting to see if we have a need for
it before introducing another technology into our already-complex
technology stack.

As far as Jini, we felt, after some prototyping, that it was a pretty
safe choice. We knew more or less where our service boundaries were
going to be (or were headed), and knew that in most of those cases
we'd be going across the network anyway; so we'd have to update the
clients to handle network issues regardless of what technology we
chose. Since Jini is interface-based, we felt, if we had to back away
from Jini, we'd have a number of other options to choose from to
implement the interfaces and contact remote servers. Being
interface-based also meant rollouts were easier--we could deploy two
versions of the interface and back off to the stable one if
necessary--and testing became simpler as well.

Our experience has been positive thus far. A big upside is that we've
been able to implement not only dynamic discovery but also nice
failover and load-balancing solutions. We also find that with Jini,
we're pretty comfortable creating and hosting services of any size--we
no longer think of our platform as being based around large,
monolithic servers. We have services which are very very small and
very simple (such as propagating some possibly-dynamic configuration
to clients) and services that are made up of many interfaces and where
the service host's JVM has a fair amount of memory and needs a bigger
box to run on. I think Jini gives us flexibility in that regard (even
if it's only in how we imagine what's possible).

I'd add to that that in our experience, we've found no bugs in the
Jini SDK to date. Not that there aren't any waiting, but we've found
it to be very reliable and stable. The Javadocs are excellent and the
specification is actually helpful for solving real problems :).

Downsides--and I think here there's a clear distinction with JEE--most
of the documentation available online is old and in many cases
outdated (there's still quite a bit of Jini pre-2.0 around). There
haven't been any new books written in a while. None of us had any
experience with Jini prior to our switchover, and across the board
developers who we talk to from other companies haven't worked with it
either. The learning curve was fairly steep anyway, and lack of good,
up-to-date materials made it tough going at some points.

That said, the mailing lists are, surprisingly, amazingly good. Not
just for new questions but the archives as well. Many times I've been
able to track down answers just by searching old mail threads. The
community, when issues do come up, is incredibly knowledgeable,
friendly, and experienced.

Another issue is that we've had to write a certain amount of
infrastructure on top of what comes with the JSDK, for example, client
side discovery/selection libraries. My feeling is that the JSDK is
fairly low-level. There are projects out there that take you higher up
the stack, and in the future we may look at something like Rio to
build on.

I'll wrap up by putting in a good word for Jini service hosting: we
use Bantam (http://bantam.dev.java.net) to host a number of our
services, and it's saved a lot of time. With Bantam, we can wrap up
our services into WAR bundles and load them in a standard web
container, e.g. Tomcat. We can configure the services (and ultimately,
all the Jini configuration properties) using Spring, which is also a
big plus since we use Spring anyway. We now have project templates
available and can get new services started with almost no effort at
all. Tom, Bantam's project owner, deserves big kudos for his work (and
his patience in answering my thousands of questions!).

Good luck with your decision.

Cheers,
Patrick