Configurable Workflow Pattern

Also Known As

Grammar-based collaboration, reified collaboration, adaptive workflow

Context

 Although the general thread of business logic may be similar, different deployments of an application may require different customizations in terms of the sequence of operations for workflow.  Although the set of objects that collaborate maybe the same, the sequence in which the Objects collaborate maybe dependent upon things such as user access rights, [Pree 99]  (system State). The business domain changes frequently. This results in changes to business objects that usually disrupt the stability of the software architecture. The changes need to be absorbed into a resilient software architecture. The question remains on how to explore the changes in a cost-effective manner without impacting the performance of the software architecture.

Problem

How do you adaptively alter the state, collaboration and self-description of a component that must evolve to meet new business challenges?

Forces

·       Change the internals vs. Change the externals: should we allow intrusive changes to be made into a component or should we externalize those change points using Variation oriented design and make modifications to the use?

·       Using reflection vs. run-time startup: should reinitialize the workflow at system startup or should we reflected the Inquirer about the configuration of a given set of components at run-time?

·       Writing an application for central office vs. configuring it for local offices

·       Heart coding the workflow vs. creating an adaptive collaboration

·       Using aspects or using a reified collaboration: aspect oriented programming, subject oriented programming and alike introduce special constructs at the programming language level.  Should the architect opt for such a decision or should he bases decision on the concept of a reified collaboration which allows the properties of dynamic configuration, collaboration and self-description?

·       Stable vs. changing software architectures: should changes in the business impact the software architecture or should the changes be absorbed in resilient software architecture?

 Solution

Write a domain-specific language (DSL) to model the business domain.  Externalize this language as a configurable workflow based on Variation-oriented Design, so that changes to the component may be done independently of the component's active code base.  The component "reads in" its configurable workflow at startup, and configures itself dynamically for a new set of collaborations based on the new requirements reflected in the updated workflow. This process is called Grammar-oriented Object Design(GOOD): starting from a domain specific language, externalizing it in the grammar, defining it is a configurable workflow for a component who exhibits the properties of dynamic configuration, dynamic collaboration and self-description.  Variation oriented Design separates the changing from the non changing aspects of the domain specific language that allows externalization of hot spots in the domain specific language.

Consequences

You now have a software architecture and an application which is resilient to change.  After a subsequent period of variation oriented Analysis, changes have been identified and the major ones have been externalized as a business domain language.  Now, updates the business logic and the rules governing the collaboration between maintained by updating the domain specific language that has been externalized.

The workflow has been declaratively externalized in a set of production rules in the style of grammar-oriented object design [].