Remembering the Future

The State interface is also very minimal. I'm erring on the side of caution for the time being, and allowing other interfaces to extend the basic State requirements. Implementations of those objects can be recast inside of the different Action and Workflow implementations without cluttering up the method signatures with specific dependencies. A toMap() method will probably be in order eventually. Both of State's methods return java.lang.Object, which likewise must be recast. This flexibility comes with an accompanying degree of complexity, which we'll explore more later.

The Action interface is simple. Actions are given a reference to the State and they don't return anything. Their role is to alter the State in some way, or to trigger an external process as a result of the state. The other components in the framework make no assumptions about what actions actually do. A Workflow component can check the state before and after an action has fired, and use that information to figure out what to do next, but has no other way of knowing what goes on therein.

Workflow implementations accept a reference to the State object but, unlike Action objects, they also return a State reference. This is important, because it might not be the same State as the one they received. Right now, Workflow components examine the application state, decide what to do next, maybe fire off some actions, forward control to another Workflow component, and once they're done doing their thing, they give control back to whatever object called them. All they do is examine the state and decide whether or not to execute actions. By themselves, action objects aren't capable of deciding the order in which they execute. They can set a flag in the state, thereby suggesting the order, but ultimately, the workflow components make that decision.

The best part about Workflow components is that the brunt of their decision-making functionality can be replaced with a JSR-94-compatible rules engine. In the future, the role of Shocks' Workflow components will be to delegate decisions to that JSR-94 rules engine by way of JMX. The entire Workflow engine will therefore be completely modular, extensible, and manageable.