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 <p...@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; >> > ... >
