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