So, let's go back to the first assertion that I made, which is that the object model that you use is tied to the language in which that object model is presented. From this, a lot of you concluded that it was therefore a bad idea to try to pass objects from one place to another while doing distributed computing, because you certainly don't want to tie yourself to a single language. After all, we all know that different languages are good for different things (or, just as important, are preferred by different people). So to keep from being tied to a particular language, we had better confine ourselves to simply passing data from one process to another while doing distributed computing.

To paraphrase a former president, you could do this, but it would be wrong (here is where I turn my cards face up). First of all, it means that you need to have a language-independent mechanism for passing data from one place to another. But there is no more a language-independent way of expressing data than there is a language-independent way of expressing objects. If I tell you that a data type is an int, you don't know its size unless you know if it is an int in Java, of C (well, even then you won't necessarily know) or C++. But you do know that I'm not talking about COBOL; but if you want to talk COBOL you need to know how to translate my int into your PIC 9(x) for some value of x.

Sure, I will admit that the number of data types that need to be translated from language to language is smaller than the number of object types that might need to be so translated. But in both cases you are going to be needing to translate from one language to another. The task is essentially the same, whether you are translating objects or data.

What it really comes down to, at base, is that doing distributed computing of any form requires that you begin with a base set of conventions that you require everyone to buy into to make the communication possible. One set of conventions has to do with the way you will translate the wire representation into a set of data types that can be understood by the two (or more) participants. An alternative convention would be to agree on a language that will be used on the network (as stated earlier by Bill Venners). And if that network language is both object-oriented and a language in which you can implement the client or the server, you get a bunch of nice properties in your system.

For example, if you are sending Java objects over the wire, you can insure that sets of invariants that should govern the data in those objects will be respected on the other side (or at least checked). You can, if necessary, download new code for new objects (the thing that makes Java^tm RMI and the Jini^tm networking system so powerful). This last ability lets you change the system over time in interesting ways, which can't be done if all you are doing is passing data. It even lets you change the way communication happens, since some of the objects that can be passed are the proxy objects that are used to do the communication.

Does this mean that I'm saying you shouldn't program in anything but the Java language? Hardly; I fully agree with those who claim that different languages are useful for different things. There is now a need, and always will be, for mechanisms to translate information expressed in one language into another language. My only claim here is that this shouldn't be confused with the need to transmit the information across the network. You are much better off doing this within an address space (or on a single machine in different address spaces) where you can control all of the mechanisms. Trying to do this on the network is the equivalent of saying that the phone system should translate any language into an intermediate form and then re-construct into the language of the receiver on the other end. A much better approach, I would claim, is to carry a single language on the wire, and then have a translator on the other end when needed.

interface OrderItem {
 
   String getProductCode();
   void setProductCode(String c);
 
   int getQuantity();
   void setQuantity(int q)
}
 
 
class OrderItemImpl implements OrderItem {
 
   private String productCode;
   private int quantity;
   
   public void setProductCode(String c){
      if (c == null)
         throw new OrderException("product code must not be null");
      if (c.length() > 20)
         throw new OrderException("Invalid product code");
         
      productCode = c;
   }
   
   public void setQuantity(int q){
      if (q < 1 || q > 1000)
         throw new OrderException("quantity must be between 1 and 1000");
      
      quantity = q;
   }
   
   //... getters and the rest
}