State Machines part one
At the heart of PlanetCAD's SCS Envoy was a workflow engine cast as a finite state machine. It was responsible for managing the automated processing of CAD models through a farm of job servers.
At the time I wrote that engine I started to see workflow and state machines everywhere. I spent some time looking at the Jakarta Commons Workflow in the Commons sandbox. It was structurally similar to Envoy's workflow engine, but it was intended to operate at a completely different level -- managing multi-page forms (aka wizards) in a web application. I was also in on some early discussions with Bob McWhirter as he was starting Werkflow .
Anyway, we were expecting to see Envoy evolve into a system that also structured some of the business workflows. Think of how paper forms in triplicate flow through a traditional business process. Many of the organizations which are working with three dimensional models also have heavily structured processes which might lend themselves to electronic augmentation.
At the time I put workflows into three categories. The automated back-end processing that was happening in Envoy, the wizard interfaces in web applications, and the larger business process itself.
When I was building Envoy's workflow engine I was finally groking design patterns. I was razzed by the other developers on the team for trying to find yet another place to use a pattern. No question, I was intoxicated by patterns and was trying hard to shoehorn them into our system anywhere I could. They were right to push back against my zealotry so only those patterns with solid rationale would actually make it into the system.
Their razzing made me seriously second guess myself about all the places I was seeing "workflows". Was it just youthful enthusiasm? Or were there really all these different applications for workflow?