river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Z Juhasz" <z65.juh...@gmail.com>
Subject RE: Suggestion for future
Date Mon, 27 Dec 2010 18:27:45 GMT

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

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

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

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



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


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

View raw message