Remembering the Future

I had been trying to integrate the ideas from some old conversations that I had with Bob Haugen and Bryan Thompson with some new conversation that Bryan and I have been having about the nature of workflow and its relationship to technologies like Topic Maps, RDF, REST and RSS. Bryan has been very interested in thinking of workflow as a conversation, and using RSS as a technology for supporting that kind of interaction. One important insight is the dual nature of messages as both an item and a channel. Bob has a lot of experience with workflow systems and has emphasized workflow as a managed system of business commitments. Key to this approach is an understanding of the role of business documents and business objects and how they are different. At first I was a little resistant to the idea of using RSS to encode workflow. While it allowed a natural way of structuring activities as items, I saw it as an obfuscation of the natural structure of a language for expressing business objects (shared state, contractual commitments etc.). Rereading the old messages and presentations from Bob and Bryan, have helped me sort things out a little. For example: 1. Someone must store the instance of a business object (BO). It may contain links to a highly distributed collection of information, but its identity must be maintained by a coherent source. An RSS item provides a good container for distributing a reference and possibly a historical copy of the BO. 2. An item as a channel is often used to log comments about an item. In a similar way, a BO has a log of business documents that provide a history of its development. Each business document provides a kind of commitment that affects the evolution of a BO. 3. The difference is that while an item is often considered a static statement which is the subject of an appending log of comments, a BO is the current state, or a dynamic aggregation of the effects of a stream of actions/commitment expressed as business documents. A conversation would loose its coherence, if its subject was a moving target, with no record of the actual item for which the conversation comments were responding. The collection of business documents, on the other hand, provides a kind of transaction log that can be replayed to regenerate the state of a business object. 4. This also relates to the subtle issues that surround identity and reification in topic maps and RDF. You need an id for the initial subject of a business conversation, as well as an id for each responding business document. In addition, each business document needs references to: the id of the subject (or stream of subjects) from which it derives is own identity; the id of a snapshot of the conversation to which it is responding, and the id of the current state of the conversation were the aggregation of commitments surrounding the initial business subject can be acquired. The resolution of this sorting process will have to wait till later. See also: Bryan: Workflow Choreography for RestWebServices Bob :Commitment Oriented Orchestration Guy: The New Workflow