ObjectSpace Voyager

[Alberto G. Corona]

This gem of distributed computing was made using Java around the year 2000 when J2EE was not even in the drawing board.

It supported runtime object migration, synchronous and asynchronous messages, automatic redirection of messages to moved objects etc.  I was fit for a cloud platform 14 years ago,  before the big hardware companies started to promote J2EE in order to sell their unix mainframes.

Automatic load rebalancing by moving processes, automatic failover, etc were in the plans of the company.

http://www.cis.upenn.edu/~bcpierce/courses/629/papers/unfiled/AgentPlatformsW97.PDF

Question: Can we have it in haskell?

--
Alberto.

[Alberto G. Corona]

Tim,

Thank for your assertive and supportive answers 

For me, Objectspace Voyager is the blueprint to have in mind for cloud haskell. the rate applicability*generality/simplicity is the highest I can imagine for a cloud platform. I think mobility is absolutely needed for many problems.

I follow the CH development from time time. Some time ago we discussed in the list how to implement mobility and message forwarding. 

I have written something about this. I will forward it to yo

2014-05-09 16:02 GMT+02:00 Tim Watson <watson....@gmail.com>:

Yes, with caveats. Some of the components are already in place (or under development) in distributed-process-platform. Hopefully this month will see the proper release and we'll be able to talk about specifics of what's needed. But in short, you could make a start with that already using what's available today in the development branches (or even just the released base layers on hackage).

Do you want to jump onto irc and talk about how to get started? #haskell-distributed

Cheers,

Tim

--
You received this message because you are subscribed to the Google Groups "cloud-haskell-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cloud-haskell-deve...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Alberto.

[Bob Hutchison]

On May 9, 2014, at 12:29 PM, Alberto G. Corona <agoc...@gmail.com> wrote:

Tim,

Thank for your assertive and supportive answers 

For me, Objectspace Voyager is the blueprint to have in mind for cloud haskell. the rate applicability*generality/simplicity is the highest I can imagine for a cloud platform. I think mobility is absolutely needed for many problems.

And since Voyager was marketed as an Object Request Broker so possibly easily written-off like most other ORBs (like I just did :-), it’s important to note that Voyager actually worked very nicely, and pretty much exactly as described. 

[Alberto G. Corona]

Yes, forget the term ORB. that is a buzzword of that time. and OV had to use it a lot for marketing purposes But fortunately it was not a fatty ORB but cloud computing..

2014-05-13 11:12 GMT+02:00 Tim Watson <watson....@gmail.com>:

On 12 May 2014, at 18:06, Bob Hutchison wrote:

On May 9, 2014, at 12:29 PM, Alberto G. Corona <agoc...@gmail.com> wrote:

Tim,

Thank for your assertive and supportive answers 

For me, Objectspace Voyager is the blueprint to have in mind for cloud haskell. the rate applicability*generality/simplicity is the highest I can imagine for a cloud platform. I think mobility is absolutely needed for many problems.

And since Voyager was marketed as an Object Request Broker so possibly easily written-off like most other ORBs (like I just did :-), it’s important to note that Voyager actually worked very nicely, and pretty much exactly as described. 

Yes, it does look nice, but I'm not sure that ORB is the right blueprint for a distributed Haskell. After all, what is an "object" in our case? And ORBs have not been wildly successful in Java afaics, not least because whilst location transparency is useful, it comes with caveats.

Anyway, Cloud Haskell is explicitly built to mimic Erlang. We could certainly built something that looks like an ORB using CH for infrastructure and it's easy to see that many of the features and concepts ObjectSpace offers are worth implementing, but the underlying structure of CH is at a much lower level of abstraction and rightly so IMHO.

I'd suggest taking a look at the various utility and service level constructs that are starting to seep their way into distributed-process-platform. I think this is the right kind of level to introduce the sort of concepts that ObjectSpace offers for CH users, possibly as a separate library, possibly by incorporating some of those ideas into d-p-platform.

Cheers,
Tim

--
You received this message because you are subscribed to the Google Groups "cloud-haskell-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cloud-haskell-deve...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Alberto.