hypermedia binding
in 1921
Alfred Korzybski
published
Manhood of Humanity. in this work (and in subsequent editions)
Korzybski lays out his basic premise that what makes humans unique is their
ability to adapt and evolve more effectively than any other animal to date.
he claims this is due to our ability to use "time" as a key abstraction; to
evolve over time. the technique we use to accomplish this (he claims) is the
ability to pass our knowledge down the generations (writing, etc.). we make
"time" an ally in our evolution and adaptation. he called this uniquely
human capability
"time-binding."
effectively evolving over time; time-binding...
hmmm....
"There are two ways to slide easily through life; to believe everything or to doubt everything. Both ways save us from thinking. "
Alfred Korzybski, "Manhood of Humanity", 1921
binding examples for dist-net apps
when we write dist-net apps today, the problem of "binding" the client to the server must be addressed. i've mentioned this stuff before in this blog but i'll give a quick summary again since it's will fill some space here and enforce my selected POV for today[grin].
- RPC-style
- the client and server share the list of remote procedures including the names of the procedures and the calling details (arg list, types, etc.) and the expected return values/objects. clients are bound to the procedure list.
- OO-style
- the client and server share knowledge of the object graph including the hierarchy, member details, methods that can/should be applied to the objects, and the method of serializing and deserializing those objects. clients are bound to the object graph.
- URI-style
- the client and server share knowledge of the URI space (segments, parameters, etc.) and the payloads associated w/ those URIs. usually clients are given a set of rules on how to construct URIs and how to craft payloads to match. clients are bound to the URIs/rules.
these should all look/sound familiar; we deal with this stuff everyday. these are all examples of how developers attempt to animate a problem domain over a distributed network; how we write apps that get things done. basically, how devs work out a way to share understanding of the problem domain between client and server.
the evolvability problem
a key point here is to understand how these well-known models behave over time; how they handle "evolvability." for the most part, the styles identified above do not handle it well. for example, changes in the list of remote procedures, the shared object graphs, and/or the URI patterns all run the risk of (at least) freezing the exisiting client at some "static version" of the dist-net app. at worst, existing clients will "break" or become useless.
the common solution is to simply abandon old clients by asserting a new "version" of the app that handles the problem domain. this can be done by re-writing the client code and shipping that new code to everyone (Javascript anyone?), changing the URI pattern to start a "new" URI space that "old" clients never "see", or just making the changes and instructing all client devs to go back and re-write their code to match the new domain details.
IOW, there is no "evolving" here; each "version" is a "genetic dead end" so to speak. each major "modification" is a "greenfield project" for client coding.
but it does not need to be this way. it is possible to use the lessons from Korzybksi's "time-binding" model to craft dist-net apps that can sucessfully evolve over time. that can adapt to changes in the problem domain w/o needed to be re-coded or "left behind" as the app space moves on.
we need a new binding model
what some readers may have noticed is that, in the previous style examples the target of binding clients and servers is always a "first-class" aspect of the problem domain (the procedures, the objects, the network identifiers). it only stands to reason that changes in the problem domain will alter these collections and that alteration will run the risk of adversely affecting the over-all effectiveness of the participants (clients and servers) thereby reducing it's evolability.
one way to simply avoid this problem is to stop binding to "first-class" problem domain elements. instead, what is needed is a binding model that can support shared understanding between client and server, can effectively "animate" the problem domain over the dist-net, and still support change over time.
hypermedia binding
a solution to the evolving-over-time problem for dist-net apps is to bind clients and servers via a shared understanding of hypermedia controls. IOW, change the binding from first-class domain elements to an abstract expression of those elements; to elements (links and forms) that make "animating" dist-net apps possible.
let's add one more style to the binding list above...
- Hypermedia-style
- the client and server share understanding of the links and forms that may appear within a message. they agree on which hypermedia element represents a "safe" operation, which are "idemponent" or "non-idempotent", which elements support optional arguments (forms), which require payloads, and which support generalized rules about URI construction (URI templates, etc.). clients are bound to the hypermedia controls in a representation
in the above style, changes in the problem domain (new procedures, new objects, new URIs) do not "break" existing clients; they can continue to function and will instantly support the evolved problem domain. why? because the "binding" is orthagonal to the problem domain. the "binding" is to the hypermedia controls themselves; not what they "represent" at any point in time. whenever a form or link appears in a response, the client will be able to recognize, parse, and render it as needed. the system can successfully evolve over time.
the only risk of "breakage" is when the details of the hypmedia controls are changed. for example, new hypermedia elements appear (they will be ignored) or aspects of an existing hypermedia element are changed (this can "break" the client). but these changes are less likely to occur than changes in the problem domain and there are facilities for dealing with these changes, too (i.e. new media types, new transfer protocols, etc.).
bottom-line?
a hypermedia-oriented approach shifts the binding away from the volatile problem domain elements and toward the more stable hypermedia elements. in doing so, the evolvability of the system is increased. hypermedia-binding makes it easier for dist-net apps to evolve and adapt over time without running into a "dead-end"; without the need to declare a "version" for each meaningful modification in the system.