Infinispan ( http://infinispan.org ) is a clustered cache technology, similar to Coherence that scales up and down dynamically and has a Map/Reduce capability. I've thought a JavaSpaces implementation built on top of it would be pretty compelling.
-jeff On Fri, Jul 1, 2011 at 11:15 AM, Oliver Plohmann <[email protected]> wrote: > >> Hi Oliver, >> >> ... >> >> Specifically with Jini, the difficulty is how to manage the lifecycle >> of such code: >> >> (1) Does one install it statically at startup of the JavaSpaces >> service or go more dynamic? >> (2) If one goes with the dynamic option, how does one deal with >> security (it's quite simple for a single-user, more complicated with >> multiple users)? Does one even need security? >> (3) How does one manage the increased memory usage and CPU of such a >> solution? How might that be made to scale? > > Hi Dan, > > it would be nice if a JavaSpaces-like interface could be found, e.g. a future > can be seen as a JavaSpaces-like blocking read. Do a write with an Entry > object that can be executed on the server-side. When you want to execute it, > do a JavaSpace05.read(Entry entry, ...) to execute it and wait till the > result has been returned. Similarly, implement a polymorphic variant of > JavaSpace05.notify(Entry entry, ...) to invoke the executable object on the > server side and notify some listener when the execution has terminated. > > (3) is a real problem, I think. If you just add a feature to execute some > task on the server-side it will not scale. The case I found where I could > justify server-side execution is an exceptional case (developing a stm system > on top of JavaSpaces and not developing an "ordinary distributed > application"). So you could go with a solution that does not scale and the > user is left with the responsibility to handle this feature with care. > Similarly, a programming language that offers a lot of features for meta > programming leaves responsibility with the developers only to make use of > this features when really justifiable. > > If you are looking for a scalable solution, on the other hand, just adding > scalability by its own (which is difficult enough) might be too simply an > approach. Eventually, you have to think about extending the JavaSpaces > programming model with some coherent server-side programming model à la > Coherence, Hadoop, etc. Well, thinking about it, if I understand things right > with Terracotta users define all kind of server-side active objects (objects > that consume cpu power on the server-side) and just don't worry about the > server bogging down. The user is told just to add another machine to the > server array and that's basically it. So, there are many things to think > about. Maybe, just wait for David Gelernter to show up with a simple coherent > immediately convincing solution and we are fine ;-). Actually, coming to > think about it ... If I were GigaSpaces I would think about enhancing > GigaSpaces in a way that it can also be used for things like Google > MapReduce, Hadoop, etc. while remaining consistent with the fundamental > tuple-space approach. You have to play in that league or 90% of todays > distributed applications are implemented with some other technology (the > Internet has changed things here). There is a reason Terracotta acquired > EhCache ... > > (1) I believe most users would prefer to implement some class that implements > Runnable they can invoke at run-time. Just my 5 cents. > > (2) This is again a difficukt issue. As I'm just an ordinary application > developer with some interest in distributed systems I better leave this one > to the big system shots ... > > Regards, > Oliver > >> If we want to take this forward then, I would suggest we need to >> define an over-arching set of needs/policy then we can look at all the >> stuff that's been done historically and >> cherry-pick/mix-and-match/innovate our way to a solution. I would >> imagine we ought to be aiming to come up with a standard interface >> that perhaps extends JavaSpace05. >> >> Cheers, >> >> Dan. >> >> On 18 June 2011 10:39, Oliver Plohmann <[email protected]> wrote: >>> Hello, >>> >>> the idea of Linda tuple spaces is to have a passive central space where >>> clients can add or remove data. The client cannot invoke any server-side >>> execution. This programming model is very well suited for a wide range of >>> applications. But I'm asking myself whether it would make sense to allow for >>> some server-side execution for certain exceptional cases where this makes >>> sense. I guess this is some kind of perennial discussion ... >>> >>> Let's give an example. Lately, I was prototyping a a little stm framework. >>> After a while I asked myself how to implement the commit of a transaction. >>> Well, you change some atomic variable for all affected data in the >>> transaction and then the new values become visible at once. Then I asked >>> myself how you would implement that when developing a distributed stm system >>> using JavaSpaces. The easiest way would be to send the change list of the >>> transaction to the server and execute the code on the server-side to process >>> the changes and change the atomic variable when doing the commit. But this >>> cannot be done, because there is no way to spawn some server-side thread in >>> JavaSpaces. Then, I have to do the commit on the client-side. This will >>> necessarily result in a lot more traffic between the client and the central >>> tuple space. >>> >>> Now someone might say, that GigaSpaces or whatever system supports >>> optimistic locking and therefore to implement a distributed stm system with >>> GigaSpaces or whatever would be no problem. The point is here that a >>> distributed stm system is only an example of why server-side execution might >>> be justified in certain circumstances. You can find other examples for >>> things for which some JavaSpaces implementation has no direct support and >>> you are confronted with the same question whether there should be an option >>> to do some server-side execution in JavaSpaces. >>> >>> So my point is merely "philosophical". If I were the owner of JavaSpaces I >>> would try to make sure that the clean and elegant programming model of Linda >>> tuple spaces won't fall apart and let things remain the way they are. But >>> the question whether some server-side execution makes sense still bothers >>> me. What do you think? >>> >>> Regards, Oliver >>> >>> >>> www.objectscape.org >>> >>> >
