Hi Martin.
This is what I worked on for my master's project - at dpon.sourceforge.org (big mess, will clean one day) and written using Squeak. I never got it working but I'm still trying to get some basic things working.
On 14 May 2004 17:55:37 +0200, Martin Drautzburg martin.drautzburg@web.de wrote:
I've been pondering over the question:
"information is no much easier to transport than material objects, so why is distributed computing so difficult".
Because the context of information is very specific, whereas the context of material objects (i.e. a physical world, 3 dimensions plus time, plus all the rules of physics) is quite big. Material objects can be moved anywhere in 3-D space because its still the same context.
Objects ultimatively reference their worlds. A Canvas object eventually references my graphics card, my monitor and the eyes and the brain of me, the user. None of these objects can be transported easily, so the boundary between a Canvas object and its world is definitely above the graphics card. The graphics card and all other material objects are "immobile". Maybe even the Canvas object itself is immobile.
My solution was to couple each object with a ReplicationAlgorithm object. All messages sent to the object are captured and processed first by its ReplicationAlgorithm. This meant that the distributed "aspect" of that object (i.e. behaviour and state of the replication) is separated from the normal.. er.. behaviour of the object.
I'm not very familier with the Canvas class yet... I haven't done any graphics programming in Squeak. If the Canvas object is the wrapper around the physical device, then yes, you'll need to use remote invocation. If its just another layer of abstraction and it doesn't need any access to plug-ins or hardware, you could use another replication algorithm, such as having replicas placed on any computer that wants to use that object, and using some consistency protocol keep the replicas up to date with each other.
It does get hairy quickly though.
In any case there are mobile and immobile Objects.
Well, there can be replicated objects, where there's usually one replica per machine. Examples of replication algorithms are: - remote invocation / call-by-reference (one central replica, pack the message up, send it off, wait for reply). - migration / call-by-value (fetch the object, send it a message locally) - master/slaves (read from a local replica, write to a central master - for state only). - broadcast (send all messages to all replicas
and then of course your imagination is the limit.
When the world of an object is replaced the object needs to attach itself to a new world. If the object should expose a "similar" behaviour in the new world, then the two worlds must be reasonably alike. The same is true for material objects.
Yea, this is the hairy bit. Essentially, if you migrate an object, then everything it has a relationship with must also be replicated. At the object's destination, every reference the object owns must be converted to some form of remote reference.
Be careful with your 'physical objects' analogy. The word "Object" was perhaps a poor choice of words in Smalltalk. A better name for the entities in Smalltalk would be "Concept". The physical "Object" could be considered a sub-class of a "Concept" which can only exist in a 3-D physical world. Concepts themselves consist only of relationships with other concepts, with exceptions for things like numbers and characters. It is those relationships which form the context of that concept. If you take the concept out of that context, it becomes meaningless because its essence - the relationships - no longer have meaning.
The solution is to ensure that a Concept (/Object)'s relationships remain valid after moving or migrating that Concept/Object.
HIDING INFORMATION
You typically don't want to expose too much information. An object on the sender side may "know more" than is relevant for the receiver. Likewise the object on the receiver side may know more about the receiver than is relevant for the sender.
Good point. This is one of the hard parts of distributed computing - it can be difficult to encapsulate the distributive nature of an object. Lots of bad things happen in distributed systems - networks aren't as reliable as local processes and memory. Simple things like message sends aren't guaranteed to happen, meaning that every invocation could cause a distributed exception. Also, like you say, an object sometimes needs to be aware of its migration, and adjust itself accordingly. It needs to be able to serialize itself and unserialize itself, storing only the relevant information it needs to remake itself, and be able to reconstruct its context at the destination. This gets quite involved. Serialization is hard - what do you do with a 32-bit local reference to another object? My solution was to replicate each object that is referenced, and then ask the coupled replication algorithm for a serialized reference to it.
This means that objects have to "mutate". They can be in one of three states:
- objects attached to the sender's world
- object detached
- object attachted to the receiver's world
This is essentially serializing and deserializing an object.
Michael.