ORBs

Lex Spoon lex at cc.gatech.edu
Thu Jun 24 14:22:10 UTC 1999


I think that RMI in Smalltalk, as you describe, isn't that hard to do in Smalltalk .  The harder part is doing it well :).  Do you allow any asynchrony?  How do you deal with nodes disappearing and returning?  How about migrating frequently accessed objects around the network?  Well, if you do that, how do you deal with different versions of classes?

And how do you deal with security in all this mess?  You have problems both in connecting to the right node, and in limitting those nodes in what they can do.

Anyway, I did a basic RMI system for Squeak as a class project last quarter.  I hadn't mentioned it because, well, it's just a toy.  But maybe a toy is at least interesting to some people out there.  I've stuck it at:
	
	http://www.cc.gatech.edu/~lex/7431/

The writeup is writeup.*, and the code is in the two .cs files.  It should appear at 6:00am EDT tomorrow morning.


Now, this is not a great system.  But it does work.  A few aspects of it:

	1. The basic mechanism is the one being bantered around: use a RemoteObject proxy, which triggers on doesNotUnderstand: to talk to a "registry" object which in turn sends requests across the ntework.

	2. Only primitive data types actually get passed across the wire (smallIntegers, characters, symbols, floats, maybe one or two others).  All other objects are passed by reference.

	3. The proxying is asynchronous by default, but I put some work in to make a synchronous option on top of it.  That is, if you do "x := remObj foo", then the #foo message goes over the wire, but x becomes immediately useable even without waiting for #foo to come back.  But you can do "x stabilize" to make x wait for its result to finish computing, and you can do "x synhcronize" to accomplish this recursively.  This latter is a good idea when you pass something into code that isn't prepared to deal with asynchronous execution.


Some things are missing:

	1. There is no provision for hooking up the systems or assigning node id numbers.  You have to hook it up by hand.  It shouldn't be tough to stick something on top of the basic system, however.

	2. Crashes and security aren't even remotely considered.  These things probably require fundamental reconsiderations.

	3. I never worked out how to do any kind of garbage collection, not even reference-counting.  Reference counting I think would not be too hard, if one takes advantage of the finalization support, but general garbage collection would take some serious thought.


Anyway, I hope some of you find it interesting.  From reading comp.lang.smalltalk, the older Smalltalkers have probably seen and implemented similar systems a million times.  

For myself, the project convinced me to stick with old fashioned sockets for now--"transparent" message proxying just isn't actually all that transparent unless you have a well developped system.  The system here (and most I've heard of) are reminiscent of installing stuff on MS Windows: anyoud get all these cheezy "isn't everything easy" messages right before everything crashes, and you end up having to reverse engineer and work around the "easy" interfaces.  Wouldn't it just be nicer to admit it's hard up front, and do the work diretly?

I do hope that someone works through all these issues someday, and comes up with something we are all willing to use.  It would be sort of like the global Andrew File System, or the world wide web, except that instead of files, you could actually send messages around and think of the things as objects!

Lex





Stefan Matthias Aust <sma at netsurf.de> wrote:
> Hi!
> 
> Last weekend, I looked into the fly-by-wire ORB code and franky, I was a
> bit disapointed.  It's written in a way I wouldn't do such a thing (a
> questionable design IMHO) and the whole concept is extremly inefficient. 
> 
> Here's a very informal analysis:





More information about the Squeak-dev mailing list