This section describes the architecture of WebSphere MQ Workflow and its hierarchical system structure. It also describes the components that belong to a system and the communication between components, which is based on WebSphere MQ message queuing. There is also a section describing the relational database support and the APIs that are available.

Depending on the size of your organization, you can set up your installation using more than one WebSphere MQ Workflow system. WebSphere MQ Workflow is a client/server system with a hierarchical structure.

The figure below shows an example of the system hierarchy of WebSphere MQ Workflow, with the domain name Your company, system group name California Division, and system names San Jose Branch, San Francisco Branch, and Los Angeles Branch.

The top level in the hierarchy is called domain, representing all or parts of your organization. The next lower level in a domain is the system group. For example, this can be a geographical area. Within a system group, there can be several systems accessing the same database. A system contains the client/server components that you need to run your processes. You define the names with a maximum length of eight characters for each of the components in Buildtime.

Depending on the size of your installation and the operating system you want to use, the server components can reside on one or more physical machines.  The system components that are installed on one physical machine are called a node.
The flexibility to distribute system components on more than one processor is a major advantage of the system structure of WebSphere MQ Workflow. Using message queuing for communication between the various components and distributing the components on clients and servers provides a reliable environment for your workflow.

The workflow model that you define or import into WebSphere MQ Workflow is valid for all the systems in the domain. This includes all definitions for staff, data structures, programs, IT resources, and process templates. You can define properties that specify the behavior of your WebSphere MQ Workflow installation at this highest hierarchical level. Whatever you define at the highest level is inherited by all lower levels. If you want to have different definitions at a lower level, you can define them explicitly and the settings are then valid for that level.

For example, if you specify for a system group that you do not want to keep audit trail information, this is valid for all the systems and the system group of the domain. However, if you want to change this setting for a particular system and want to keep audit trail information, you can then define it for this system.

Within a system group, all the systems share the same database. If you decide to install more than one system for the system group, you can distribute the workload for process execution and still have the advantage of sharing the same data and the same workflow model.  Because any mission-critical system, such as a database management system or a workflow management system, must be highly available, the WebSphere MQ Workflow architecture provides the appropriate mechanisms. On z/OS, the systems in a system group can reside on different z/OS images, however, with the same database using DB2 data sharing. For distributed platforms, the three-tier configuration, is an important factor for implementing a highly available system.

Similar to the system structure, there is also a hierarchy for the communication that is needed between components to support fast and efficient message transfer. Communication between systems within a system group is optimized for the message traffic within the system group and is driven by the message queuing facility of WebSphere MQ. By using the WebSphere MQ support for clusters, a system group can also be addressed as a single logical system.

The advantages of using clusters are:

• Increased availability of your queues
• Faster throughput of messages
• More even distribution of workload in your network