The Rolonic World View

There was a time when we thought of everything as objects. The emphasis was on thingness, and the colocation of data and methods. But learning how to program with objects took some doing. That was back in the early '80s. Then Microsoft brought us the Common Object Model and Sun Microsystems gave us JavaBeans. Now we have components, factories and better decoupling. And then nothing, except for a lot of ad hoc systems with short-term goals, like Portlets and SOA. EJBs have taken a back seat to POJA, and AJAX is the latest fad. Software has become driven by fashion.

Now I often talk about Rolonic Theory, and AgileWiki uses terms like classifiers, descriptors, journals and ledgers. Time again for a quick review of the basics of Rolonics.

Fundamental systems with tremendous richness are based on dualisms. Look at wave-particle theory. A simple dualism: photons are both particles and waves. A very rich conceptual ground. Rolonic theory is based on two dualisms, wholeness/partness and structure/stream. Lets start with the first, its probably easier.

Everything is a whole, with associated behavior. At the same time, everything is a part of a larger whole. A whole with parts is a system, so we're always dealing with systems of systems, how a system deals with its parts and how a system interacts with other parts within a larger system. Descriptors then describe a system's behavior; classifiers identify a part within a whole and relations between parts. "Ha!" you say. That's just meta data. And that's missing the point. Classifiers and descriptors are quite different and a good model of any system of systems implements classifiers and descriptors differently.

Now lets introduce a Rolon. This is the term we use for a part of a system and for a system with parts. (Everything is always both, so there's no confusion here.) The catch of course is that when you implement a model of a system of systems (which is to say, any interesting model of anything), the descriptors and classifiers are also Rolons. But never mind that now. Lets move on to the other dualism, structure/stream.

Everything is a structure. When you think of a system of systems, you envision lots of structure. But everything is also a stream. Say what? Yes, everything can be modeled as a collection of events which occur over time between Rolons. We are our history, hmm?

Lets look at something very simple--XML. You have the DOM representation, which is a structure, and you have documents, which are streams of characters. You also have SAX events, which can be used to create a wide range of structures when parsing an XML document. Conversely, you can walk an object graph in various ways to produce different event streams that can be used to create a wide range of XML (or any other kind of) document. This is what my earlier project, jxQuick, was all about.

So when you are modeling something, you sometimes need to take time into account. And this is rarely done systematicly. And that's probably the root cause of why we don't have a general way to model applications. So here's the skinny--a Rolon's state is represented as a structure, which we call a ledger, and its history is a journal of events. Or transactions if you will. Of course, you can recreate the ledger of a Rolon by replaying its journal. Or you can change the way the journal is interpreted and when you replay it you get a different ledger. (Norm calls this retrodiction, reinterpreting historical data in the light of present knowledge.)

Now there are some applications where the journal is of absolute importance, like a bank account. But I dare say, there are a lot of applications which would be far richer and natural to use with a systematic implementation of changes over time. Like the difference between a calculator, which gives you an answer that is only correct if you entered the right numbers, and an adding machine, which gives you a journal of the numbers (a printed tape) that you can verify are correct. I contend that software needs more adding machines and fewer calculators. :-)

And that's the basics of Rolonics. Breath deep. Remember how hard it was for us old Fortran and Cobol programmers to learn C++. The ideas are really simple. Wholeness (behavior, descriptors), Partness (names/relationships, classifiers), Structure (state, ledger) and Streams (transactions, journal). This is a way of looking at (modeling) the natural world, both mechanical and organic systems. But it is a twin dualism, so it is terribly simple and immensely rich in implications. It took me more than 5 years to get comfortable with Rolonics. Hopefully it will not take you as long.

The AgileWiki(3) then is being built using Rolonic concepts to model/implement applications. There were 5 generations of prototypes before this, each taking about a year to do, and each teaching me new lessons about implementing Rolonic models. And each with somewhat different capabilities. But this time 'round, its not a prototype. Should prove interesting!

Bill

P.S. Norm, I've used a lot of your phrases and concepts here, of course. As the author of Rolonics, you've left a deep imprint on me and how I think. --B