Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of z65.juhasz@gmail.com designates
 209.85.215.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=from:to:references:subject:date:message-id:mime-version
         :content-type:content-transfer-encoding:x-mailer:in-reply-to
         :x-mimeole:thread-index;
        b=CR/NKQQ/Y/X5PdXhfRFItCgme3Cue4uBs5KeAZ9hq+fUwEC4hPtZOvIm29fjBd+bs1
         tEDlIrWX4xJMImblvIL9L2TZGFRSWjpnVCXK3sBEN7RYL6ZCW5dta6uG8JLx1t7ZiQyu
         pStPMD+I3hSyF8yJpqf2v231g+N3bhb0UtoP0=
From: "Z Juhasz" <z65.juhasz@gmail.com>
To: <river-dev@incubator.apache.org>
References: 
 <AANLkTi=+GrFS0-EJe+UBtkScU8JFYdpvo1EmoPOK2+6z@mail.gmail.com><4D18BF7D.4010507@acm.org>
 <AANLkTinKCivmm_=ZwamHB+FGaEMNTYAJz4TKYMp4nExF@mail.gmail.com>
Subject: RE: Suggestion for future
Date: Mon, 27 Dec 2010 19:27:45 +0100
Message-ID: <FC1239FEF6B946E1815D14A4D6799F66@irt.vein.hu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <AANLkTinKCivmm_=ZwamHB+FGaEMNTYAJz4TKYMp4nExF@mail.gmail.com>
Thread-Index: Acul6Gxo/NZhL509RTCfSedFT/YP3gACALTQ

Dan,

There's a lot of good things in your comment below. I'd like to add a =
few
extra bits based on my experience and my interest in Jini (and its =
future).=20

- I agree that Jini is unique in the distributed computing arena in its
philosophy. It recognizes that things fail. Full Stop. The largest part =
of
the software developer community still things we can just extand =
(stretch)
serial computing paradigms=20
a bit and all will be good. I liked Jini's philosophy from the first =
moment.
Until people don't start building complex distributed systems, they will
never recognise the power in Jini. This may never happen and this =
community
may as well stay as niche (note that the majority of web service =
technology
based systems are in fact relatively simple client-server environments). =


- The second point is that Jini is heavily relied on objects. I wish =
everone
remembers Jim Waldo's excellent talk entitled "Do you believe in =
objects?"
(or such). I wish I had the link to the audio... Do people want objects =
and
(consequenly) object-based APIs? Current trends favour scripting and =
mesasge
parsing that I personally don=92t like but one has to live with these.

- Thirdly, on top of object-based semantics, Jini is Java based. I =
remember
way back at around the year 2002 I talked to several experts in the grid
computing community about Jini and their major problem with it was that =
'it
is Java'. By and large industry and large communities are worried about
prescribing one particular language, which is mostly understandable -- =
even
when the technology  offered is clearly superior to those available.=20

- Finally, Jini is not just Java but is exploiting the ubiquitous Java
platform (the JVM). To me, this is the key point. To have a virtual =
machine
- and actually it could be any, not just a Java VM - is the most elegant =
way
to solve the heterogeneity problem in distributed systems. Being able to
develop anything on a laptop and run it virtually anywhere, the result =
of
this cannot be underestimated. I always thought industry would be buying =
on
this advantage heavily but I was proved wrong.=20

I deliberately want ot avoid any hints of conclusions as I would like to
community to discuss these things further.

Cheers,

Zoltan


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
Dr Zoltan Juhasz
Dept of Electrical Engineering and Information Systems
University of Pannonia (formerly University of Veszprem)
Veszprem, Hungary

=20

> -----Original Message-----
> From: Dan Creswell [mailto:dan.creswell@gmail.com]=20
> Sent: 27 December 2010 18:13
> To: river-dev@incubator.apache.org
> Subject: Re: Suggestion for future
>=20
> I don't think that should put you off, here's why....
>=20
> We're not talking about distributed computing so much as what=20
> we want to do with Jini. These are in point of fact two=20
> different things. First a little bit of dist comp theory,=20
> this is the last I'll mention, promise:
>=20
> ConcurrentMap and indeed Map semantics alongside the=20
> constructs for atomicity (e.g. synchronized) as found in Java=20
> are not "distributed computing friendly". This is because the=20
> failure semantics they offer are next to zero (all these=20
> things provide blocking operations with no timeout that are=20
> expected to end successfully in very small finite time). The=20
> only way these work is with a compromise of sufficient=20
> redundant hardware and reliable networking setups that can=20
> protect these constructs from failures.
> Similar tradeoffs can be seen with many message queues,=20
> databases and such.
>=20
> All this is at odds with the philosophy Jini takes in its=20
> design which can be summarised as "all dist comp failure=20
> semantics will be made explicit".
>=20
> That's all the theory one needs to know for this debate.....
>=20
> It follows that Jini and many of the so-called distributed=20
> computing frameworks are fundamentally different beasts. The=20
> majority want Jini to look like these other beasts as that is=20
> what they understand, which is fair enough. Alas Jini cannot=20
> do this without discarding its core philosophy and would=20
> offer no more value than any other framework were it to do so=20
> (because that programming philosophy is already well catered for).
>=20
> Now, the community can choose to support users that want to=20
> build explicit failure handling into their distributed=20
> systems or they can choose to eschew that and support users=20
> that believe in reliable hardware. There is a third way of=20
> course which is to build something atop Jini that supports=20
> this opposite philosophy. The trouble with this for me is, as=20
> I hint above, I personally don't see much in the way of=20
> benefit over what else is already out there. About the only=20
> difference would be "powered by Jini" on the box or whatever=20
> other branding one cares for. Maybe the hardware outlay is=20
> cheaper as well but for the many small systems built by the=20
> majority, the difference is negligible.
>=20
> The "reliable hardware, no failure semantics software" crew=20
> is the majority of developers so if one wants mass appeal,=20
> that is where one must go. If one wishes to be niche, that's=20
> fine too the community just needs to recognise the=20
> consequences of our choices.
>=20
> One thing is for sure though, whichever developer group is=20
> selected as the target audience, a decent starting point will=20
> still need building. Jini has never had that sorted.
>=20
> Before anybody flames me, I care not a jot which approach=20
> people go with, I have my own preference and I believe it=20
> works better for the kinds of systems I need to build is all.=20
> These systems are not the norm, they are big, with lots of=20
> machines, run across a number of datacentres and are heavily=20
> automated to keep ops costs (including mistakes) down. I use=20
> a lot of Jini-style constructs and philosophy but tend to end=20
> up casting my own frameworks to best suit the environment I'm=20
> working in.
>=20
>=20
> On 27 December 2010 16:31, Patricia Shanahan <pats@acm.org> wrote:
>=20
> > I think this is a really valuable conversation, and I hope=20
> it can be=20
> > brought to a conclusion we can work with. I will not be=20
> contributing=20
> > because I don't have sufficient distributed computing background.
> >
> > Patricia
> >
> >
> >
> > Niclas Hedhman wrote:
> >
> >> Gang,
> >>
> >> There is a strong distributed tradition in the group of=20
> people here,=20
> >> yet unable to communicate the 'purpose' of River. Large companies=20
> >> look at Gigaspaces, pays good money for it and asked if=20
> liking Jini,=20
> >> most will go "Huh? Why would we use that?", mostly ignorant to the=20
> >> fact that Jini specs drove Gigaspaces into where it is.
> >>
> >> At my company, we are doing evaluations of distributed=20
> technologies=20
> >> at the moment. Jini/River is not even on the map, because=20
> it "misses=20
> >> the points" that are our starting point. But an open=20
> source contender=20
> >> like Hazelcast is, because it delivers an 'starting point'=20
> which is=20
> >> easy to understand, i.e. a list of features as Distributed=20
> >> Map/Queue/Events/Executor/... expressed in terminology that we (the
> >> users) already know.
> >>
> >> So here is my modest suggestion for the Jini community; If=20
> you are as=20
> >> hot on distributed technology as you think you are, then start=20
> >> thinking in terms (and deliver a clear message) that=20
> matters to the=20
> >> users;
> >>
> > ...
> >
>=20
>=20
>=20
>  _____________ NOD32 5716 (20101219) Inform=E1ci=F3 _____________
>=20
> Az =FCzenetet a NOD32 antivirus system megvizsg=E1lta.
> http://www.nod32.hu
>=20