Business
Object Workshop IIBusiness
Object Workshop IIComments:
From the Workflow Management Coalition (WfMC), workflow
is defined as;
"The automation of a business process, in whole or part,
during which documents, information or tasks are passed from one participant
to another for action, according to a set of procedural rules."
Workflow tools are typically composed of two parts. The first is process execution, the runtime portion of process management, responsible for controlling and monitoring all the process instances currently active in the system. The other part is process creation; a graphical tool for constructing (defining) processes, and support tools for deploying them.
Business objects automate business processes. They need workflow capabilities by definition, as the OMG has identified with its task management facility (which has since been dissected into other distinct, but related facilities).
The "process creation" portion of workflow tools is an environment
for defining business processes. "Process execution" is the control
and monitoring of the process state of business objects.
Below is a list of some comments on existing workflow concepts, and their
roles in the world of business objects.
Conditional routing is the ability of a workflow tool to make runtime routing decisions based on a set of predefined criteria. Typically, the criteria include tests on data operated on during the lifetime of the process instance. As an example, an order process might skip a credit check if the customer has a 'pre-approved' tag. However, it isn't proper to have each business object provide access to its private data, and therefore break encapsulation. Nor is it desirable when attempting to achieve full interoperability, to have each business object provide a get/set method pair for all private attributes.
What is needed is a way for the process creation environment to inquire, in an ad-hoc format, about key publicly accessible attributes (as determined by the business objects) of other business objects without breaking encapsulation. In other words, the process creation environment needs to be semantically interoperable with business objects, just as the business objects themselves are with each other.
The meta object facility is of course, the tool that the process creation environment could use to achieve this interoperability. Workflow technologies, at process creation time, should also be able to inquire to a business meta object repository to discover the information model presented by the available business objects.
Workflow tools interact with workflow participants via a worklist. A
worklist is defined by the WfMC as;
"A list of work items associated with a given workflow participant
(or in some cases with a group of workflow participants who may share a
common worklist). The worklist forms part of the interface between a workflow
engine and the worklist handler"
A work item is defined as;
"The representation of the work to be processed (by a workflow
participant) in the context of an activity within a process instance."
Work items and lists are outdated. In the world of business objects, the desktop is the interface. As Oliver Sims preaches, OO document centric GUIs are how business objects will present themselves to their users. And they won't be shy. They won't disguise themselves because there is no need to. Users will recognize them as entities in their business domain, and they'll understand (in most cases, intuitively) what it means to do typical OO GUI operations on them. Icons representing the business objects themselves will clutter the screen. Nebulous 'work item' concepts don't fit. They aren't objects. Work is a consequence of what happens when business objects play together on desktop GUIs as directed by users.
The need to represent and construct processes visually is apparent. The workflow tools on the market today do an excellent job at it, providing many constructs (which are best specified visually) that allow for extremely flexible and generic processes to be created.
As previously stated, the process creation environments of workflow tools will need to be able to interface with a business meta object repository to allow the developer access to the publicly exported attributes (or indeed any other meta object information) of the business objects.
It will also obviously be necessary to convert the graphically constructed process into some machine readable form in order for the process to be "executed". Existing workflow tools already have mechanism for doing this, but they need more flexibility. The "Process Execution Environment" discusses the need for agent technology.
Roaming agents, autonomous carriers of process knowledge, should be considered by the workflow vendors as candidates for a flexible, scaleable workflow architecture. "The Essential Distributed Objects Survival Guide" (Orfali, Harkey, Edwards; Wiley, 1996) points out that the combination of roaming agents, a standard object bus, and a distributed document facility (something that almost all vendors, not just workflow vendors, should be aiming to use) can provide for some very powerful constructs.
Control of process instances (such as termination, suspension, resumption) should be considered as an administrative task, perhaps to be managed by the workflow facilities. It would require the locating, and notifying, of agents in the system.
Process execution also involves the monitoring of process states across the system. It will be part of an agent's responsibilities to report on its state (and therefore the process state) as required, presumably to some configurable amount of detail.
Business
Object Workshop II