So typically we create schemas, mime-types, etc for our objects when we’re communicating to another system about objects.
The document usually defines data structure of the objects for serialization purposes with no recording of the object’s methods. All I am left with on the client are effectively structs with no methods.
So for example let’s say I have multiple classes and let’s say those included an Account and an Order. Let’s also specify that orders are tied to an account. Now let’s say I have a client who wants to fetch a certain order that’s related to an account from a distributed service that provides this information. I could code all of the searching, scanning and other types of logic into the distributed server and make the client rely on it for everything it could want to do (extreme RPC). I could just write code to scan through object graphs on the client, forcing each client with type of interest to replicate the code. I could create a library that contains common functions. But what I’d really like, is the ability to replicate methods on the object to the client as part of the contract. The client would not only know the data structure of the distributed object, but could also call and execute operations on the object that was distributed with it.
Is there any system out there that serializes operationscode along with data structure for objects? Ideally it shouldn’t just be an RPC client stub that invokes operations on a server.
3
I think the reason this isn’t done more often is because you’re sending code along with your data, and therefore you no longer have total control over the code. Maintaining security over your operations would be a real challenge. This is not true of data, because you can sanitize, validate and authorize data, using code that you can control and secure.
Code is also not homogeneous, in the same way data is. Many different programming languages and techniques are used to create data processing systems, but the data remains in essentially the same form. This is especially true of XML data. XML data is specifically designed to be systems-agnostic; you can process it on any system with and XML reader.
If you want to look for a live example of code as data, you need look no farther than Lisp. Lisp has a deep philosophy of “code as data.” In “The Nature of Lisp,” the author explained this distinction by pointing out that you can translate any programming language to XML, transmit it over the wire, and execute it:
<define-function return-type="int" name="add">
<arguments>
<argument type="int">arg1</argument>
<argument type="int">arg2</argument>
</arguments>
<body>
<return>
<add value1="arg1" value2="arg2" />
</return>
</body>
</define>
So all you have to do is send the source code in your transmitted object, compile it at the target, and execute it against your encapsulated data. 🙂
Your “serialization of code” then boils down to “include the necessary source code to process this object with every packet of data you send.” I think you can see how this can quickly become very unwieldy. If you’re going to transmit programs to a remote system that will operate on data you send it, it makes more sense to transmit those programs to the remote system ahead of time, install them, execute them, and then send your data.
1