Repository navigation
Animation Procedures
This page describes the concept of animation procedures in the core ultrastructure implementation.
Animation procedures are the execution of the Ultrastructure rules engine. Basically, you can think of Ultrastructure as an event driven rules engine. In Ultrastructure, the events are triggers on the ruleforms - i.e. Create Update Delete. As the integration with Agencies is through the Job interface, the entire workflow is driven off changes to the Job protocol.
##Function of Animations
At the 10,000 foot level, you can think of the animation procedures of Ultrastructure as the main loop of a rules engine execution. Everything in Ultrastructure is an instance of a ruleform, and the relationally consistent state of an Ultrastructure instance forms the Facts and the Rules of the rules engine. When the state of the Ultrastructure instance changes - i.e. changes to rules (facts) - the implementation executes code. This is commonly known as a trigger. So when a row of a given table is inserted, updated or deleted, this triggers code execution in the Ultrastructure rules engine. This triggered code is the animation of the rules engine.
##It's All Rules, All the Way Down
Because Ultrastructure represents facts in a rules system simply as instances of another rule, this means everything is on the same footing, and the animation of the rules engine is simply responding appropriately to state changes. This means that the conceptual simplicity of Ultrastructure is that we simply don't have a huge surface API area that someone needs to learn before they can start building animation procedures - it's just Create, Update and Delete. And given that most rules are immutable (just deletable), even that surface area is pitifully small. Granted, coming up with that animation code can be challenging, but that's the challenge.
In addition to the state driven event API the power of inference allows us to provide extremely general animation solutions to what are normally considered disjoint, special case behavioral instances. For example, the animation code (in Java) for driving the workflow engine (i.e. Job, Protocol, MetaProtocol) is embarrassingly tiny - less than 100K of code even with comments and shit methods. And yet the ability of the workflow engine to produce enormously detailed workflows across general domains is amazing. The complexity of the system is compactly and easily represented by protocols. Using the built in deductive facilities of Ultrastructure through meta protocols, we leverage the power of graph inference to eliminate complexity and redundancy.
##Extensible
While the core animation procedures are part of our underlying Ultrastructure implementation, the model provides a powerful way of creating your own animations through the Job facility. Providing Agency implementations (i.e. services, humans, etc) you can provide any action you need executing these jobs. These implementations of Agency actions provides a solid extension point for Ultrastructure animations.
##Implementation
Our implementation of Ultrastructure is developed in Java, using the Java Persistence API (JPA). This OR modeling tool allows us to create a very nice Java model of the underlying SQL data. We used to use Java Stored Procedures to implement this, but that became a bit hard to sustain. Currently, our API is encapsulated and this allows us to interact with the underlying JPA provider (we use Hibernate) and implement the trigger actions we require for the animation behavior. Unfortunately, this means one has to be careful with direct writes - even through JPA! - of the underlying SQL store so that invariants and animations are correctly observed and carried out. We'll soon figure out a transparent way to make that work, be assured.