Re: Server-side execution and JavaSpaces

[Oliver Plohmann <ol...@objectscape.org>]

> 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 <ol...@objectscape.org> 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
>> 
>> 

Re: Server-side execution and JavaSpaces

[Oliver Plohmann <ol...@objectscape.org>]

Hi Jeff,

I like this idea. I actually once had a similar idea. I have already 
thought a bit about what issues one might have to take care about... 
Infinispan does not have user events like JavaSpaces where your listener 
gets notified upon a write. It has internal events for its internal 
organisation. But they cannot be listened to by the user application. At 
least this was true for JBossCache and I guess that Infinispan behaves 
in the same way. So you would have to add your own facade in front of 
Infinispan where upon an add to the cache tree the respective 
user-defined listener is notified.

Then you have to think about how clients exchange messages with the 
server-side Infinispan cache. One idea would be to use JMS. Something 
similar already exists named ActiveSpaces: 
http://www.theserverside.com/discussions/thread.tss?thread_id=27274 One 
issue that strucks my mind is that the JMS transaction boundary ends 
where the Inifinispan transaction boundary starts. Let's say the sending 
client expects a return receipt, the Inifispan transaction finished 
successfully, but sending the receipt back to the client through JMS 
failed. Now the client things that the transmission was unsuccessful, 
although the Infinispan transaction was successful. Maybe I'm not right 
here. I don't know enough about JMS to know for sure. But this makes me 
think.

A JavaSpaces implementation has already been implemented on top of 
Terracotta: http://www.semispace.org Now Terracotta is owned by Software 
AG and you now have to pay for a license if you want to run your 
application on an server array... Something like this could also happen 
with Infinispan.

Developing another JavaSpaces implementation would be a great "research 
vehicle" to learn a lot of things. What makes me think is whether to 
extend the JavaSpaces approach in some way that not only distributed 
systems can be build with clients that work together in a coordinated 
way as with JavaSpaces, but also processing large amounts of data can be 
done (MapReduce, Hadoop, etc.). But I know whether these are different 
things that should be handled by a different kind of systems ...

Just a quick writeup of some things that crossed my mind when I read 
Jeff's proposal...

Cheers, Oliver

On 01.07.2011 20:32, Jeff Ramsdale wrote:
> 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

Re: Server-side execution and JavaSpaces

[Jeff Ramsdale <je...@gmail.com>]

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 <ol...@objectscape.org> 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 <ol...@objectscape.org> 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
>>>
>>>
>