Resource representations: they capture a snapshot of the state or intended state of a resource.
When you think of REST it's natural to think of resource representations as a stream of binary data sent over a network ready to be consumed by a client. However, except in the degenerate case of serving static data and downloading it to your hard disk, that representation must always be "serialized" by the server and "parsed" by the client. That's obvious you say! Well it is if your client and server are network separated but in a Resource Oriented Computing (ROC) platform most requests are local, running on the same host.
Marshalling resource representations through a binary stream has two negative implications. The most obvious is the overhead of serialization and parsing processes. The second relates to the development and on going maintenance costs of the system. It you are going to have a serialized form that may well incur additional work, agreeing the wire-format and developing the serializing and parsing.
In ROC a resource representation can be any old object model with one proviso; it must be immutable. Without immutability multiple clients could communicate through side-effects either between themselves or with the service.
The first implication of this freedom is that representations gain an additional second dimension of typing. The first, original, dimension is the logical type, i.e. what is it? In an Internet systems this is the MIME type. The second dimension is the physical object model of the representation. In networked resource systems this second dimension was fixed, always being a binary data stream.
Here are some examples:
An open office text document with a MIME type application/vnd.oasis.opendocument.text embodied as a binary data stream.
The RSS feed to the 1060 Forum [http://www.netkernel.org/forum/rss/recent/1] embodied as a DOM object model
The Powered by NetKernel [http://www.1060research.com/netkernel/poweredbynetkernel.png] logo embodied in a java.util.Image object model
The complete works of William Shakespeare as an audio-book embodied as a binary data stream in MP3 format.
Employee "Tony Butterfield" embodied as a application specific POJO representation with the 1060 Research HR application.
The second, more interesting, implication is that these rich representations lead the way for unification of many processes which currently have separate names and are considered separately. Processes such as compilation, parsing, serialization, encoding, indexing etc. can all be considered as changing the representation of resource from one physical form to another; trans-representation, or the contraction transreption. Within ROC transreption is performed by "transreptor" endpoints resolved within address spaces. Transreptors may be invoked implicitly to adapt physical representations between service and client or explicitly requested. Implicit transreption leads to loose coupling by allowing services to be built without functionality to understanding anything other that the object model they work with. It allows two services to communicate even if they work with different object models as long as a transreptor can be resolved to bridge the gap.
Thursday, 22 October 2009
Subscribe to:
Post Comments (Atom)

Been playing with NetKernel off and on for the last 6 months or so... your post reminded me of a few things let me know if you think I'm off base or not:
ReplyDeleteYou said "in an ROC platform most requests are local, running on the same host."
One comment is that I was slow to pick up on this when I started playing with NetKernel. Eventually I got it but not at first. That different accessors in NetKernel within a JVM are playing the role that cgi programs/servlets/etc. are on the web.
The other thing I was slow to pick up on is that even though "most requests are local" the beauty of NetKernel is they don't have to be right. i.e. That a request that is local today can often quite easily be made to be remote tommorrow.
For a time around ten years ago I did CORBA, and they had a catch-phrase "object location transparency" meaning they'd followed a design principle that the code dealing with distributed CORBA objects shouldn't know or care about whether things were local or remote.
It seems to me something similar is going on in NetKernel, i.e. something like "resource location transparency".
With the result that you've softened this hard divide between what is and isn't local, and wound up with systems that are more malleable in how they're distributed on a network. More like clay, less like concrete, with regard to their network architecture.
At least tentatively, from my playing with NetKernel so far, these are the things I feel I'm seeing and that I hope to prove true, as I gain more experience using it.
In sense requests can be remoted. From the client issuing the request that is certainly how it can look. What you would actually do is have a local endpoint that resolves the request and then uses some remoting technology to send that request across the network. Take a look at the infoq article Randy Kahle wrote that shows an example of this with Twitter.
ReplyDelete