Summary
If object models are tied to languages, then there are some real implicatons to how we do distributed computing (and how we make objects persistent). If this is indeed the case, then why are we so stuck on language-independent systems?

Returning the the subject of my last (substantive) blog...

If object models really are tied to a particular language, they are also tied to a running process. Objects, taken as a combination of data (at best hidden and abstracted) and code that manipulates the data (generally hidden behind an interface), can only exist in a running process. This is the only place that we can have this connection between code and data and enforce the abstraction boundaries that are important to objects.

If you buy into this, then there are some real implications for those of us doing distributed computing but want to utilize the mechanisms that are the foundation of object-oriented programming. In particular, when we pass information from one process to another, we would like to think of this as passing an object from one process to another. But that means that there is going to be some point at which the object is no longer an object-- it goes out of one process (where it exists as an object), goes across some transmission fabric (where it is not an object), and has to be re-constituted as an object on the other side (when it gets back into a process).

This is, not surprisingly, really hard to do. In the simplest case, where you know that both sides of the transmission are written in the same language (and thus really share an object model), it is really hard. Those of you that have used Java RMI-JRMP (or what I think of as real RMI) know that this is non-trivial. There are some objects that refer to local state that just can't be passed from one place to another sensibly (those are the classes that aren't serializable. Static fields don't make sense to pass. Making sure that you have the right code when you end up in the destination process is pretty complicated (everyone has trouble with codebase).

If you want to do this in a language-independent fashion, it is even harder. Now you have no other alternative than deciding on an object-model for the network, and then a translation function from that object model to the object models of all of the languages you want to support. You then have stubs that translate from the object-model of the sender to the network object model, and skeletons that translate from the object model of the network to the object model of the receiver. Since something is always changed in the translation, this means that there are two stages of change. Two stages where things can go wrong. Two stages where you have to whack the model.

By the way, the network is not the only place where this problem occurs. You get the same problem when you try to persist an object. Bits on a disk are much like bits on the wire, in that neither are objects. Persistence is just transmission over time, rather than space; as Einstein taught us these two are pretty much the same.

So, if all of this makes any sense at all, why is it that everyone wants language-independent systems?

Talk Back!

Have an opinion? Readers have already posted 23 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Jim Waldo adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Jim Waldo is a Distinguished Engineer with Sun Microsystems, where he is the lead architect for Jini, a distributed programming system based on Java. Prior to Jini, Jim worked in JavaSoft and Sun Microsystems Laboratories, where he did research in the areas of object-oriented programming and systems, distributed computing, and user environments. Before joining Sun, Jim spent eight years at Apollo Computer and Hewlett Packard working in the areas of distributed object systems, user interfaces, class libraries, text and internationalization. While at HP, he led the design and development of the first Object Request Broker, and was instrumental in getting that technology incorporated into the first OMG CORBA specification.