|
|||||
| Chapter 4. Configuration | |||||
|---|---|---|---|---|---|
| Prev | Next | ||||
Table of Contents
An OpenWFE workflow management system is a set of components, usually an engine, a worklist and an apre, plus a client system (most certainly a web client system).
A component is a set of tightly integrated services. A component is usually figured into an OpenWFE application.
Note : OpenWFE may also be embedded in other java applications. This 'configuration' chapter focuses on OpenWFE as a 'standalone' system. See Chapter 11, Embedding OpenWFE.
In OpenWFE terminology, an application is a set of services.
An application finds its configuration in an XML file usually under etc/something. For example, the workflow engine itself is started by the script bin/owfe.sh engine (or bin/owfe.bat engine) and finds its configuration under etc/engine/engine-configuration.xml
This configuration file enumerates a list of services that are started. Working together, these services constitue an application.
To continue with our engine description, the engine application is made of the following services :
An ExpressionPool, recently used expressions are cached here
An ExpressionStore, where expressions are stored on disk. A workflow instance is a set of expressions.
An ExpressionMap, a configuration service that tells what hides behind an expression name in a workflow definition. (the 'what' being a java implementation). For example, with this ExpressionMap, the whole engine knows that an 'If' is implemented as a 'openwfe.org.engine.expression.IfExpression'.
A WorkflowInstanceBuilder, which turns XML workflow definitions into workflow templates and then into workflow instances.
A WorkflowDefinitionServer. If you let Apache or IIS serve your wokrflow definition files, you could comment this service out of your engine. It's just an encapsulation of Jetty (http://mortbay.org/jetty) a small but powerful java web server.
A ParticipantMap, this service is very important : it's a mapping between participant names and what is behind them. Next section is dedicated to this service.
A History service, a small service that logs engine history (what the engine does with the workflow instances) to a file. A future implementation of this service could log this info into a database table.
A WorkItemCoderLoader, this service is used to determine how to encode outgoing workitems.
A socket Listener, the ear of the engine, workitems that come back from participants all come here. (But you could have other listeners, that would, for example, poll directories regularly, for incoming workitems in the form of XML files...)
A Consumer, a listener is a generic service for receiving stuff, what to do with it is determined by the consumer that the listener is linked to. In the case of an engine, the consumer simply hands the workitem back to the participant expression that ordered its dispatch.
A status service, which tells on a given port what is the status of the application (usually on port 7078). So if there is a running engine on your machine, you can point your browser to http://localhost:7078 to look at the engine's status.
Each service has a unique name, known to each other service. They all share an 'ApplicationContext' so that they can retrieve each other per name and call each other methods.
OpenWFE separates flow definitions from who take part to them through the participant map. The engine doesn't care about participant, it just asks the participant map : please give me a dispatcher for this participant.
The participant map concept is at the heart of OpenWFE : the engine dispatches workitem to participant but doesn't know and doesn't care about what they are. It only cares about them replying (maybe timing out). The participant map holds a certain level of details : what is a participant (for certain participants local to the engine) or where is a participant (for human participants whose workitem should be gathered in a worklist, or for automatic participants hosted in an APRE).
Dispatchers are available through the participant map service in order to transmit a workitem to a another set of components. A set of components may be an engine, a worklist, an apre, with a listener, listening for incoming workitems.
The participant map also lists a dispatcher for each engine in the system : workitems have to get back to their engine for the flows to resume. Engines are participants. In the later chapters, this affirmation takes even more sense with examples of snippets of process definitions being pushed to engine participants.
