MCE in CCF Environment
MCE provides a common computational logic that should be used in all CCF user interfaces. MCE exposes UI processes that share a common logic and metadata, but are on different delivery channels. It also provides an infrastructure to migrate inter-channel UI processes and a software factory that can simplify the development of common parts and can help you to develop a physical layout that the engine can consume.
MCE is a part of the CCF Studio, and is installed when you install CCF. MCE operates as a workflow runtime, but has many additional capabilities. The following figure depicts the MCE architecture.
The following sections describe the components associated with the Multichannel Engine:
Container
The Container hosts the Engine and is part of the UI. It can manage and route commands to the Engine. When the UI starts a new Business Process, the command will be handled by the container and routed to the Engine it hosts. An example of this could be a home loan application in which case the engine will render the UI that presents a loan application Business Process. The user may also ask the container to resume a previously suspended Business Process. A given container may itself, be contained in another one, in which case it is embedded in a physical view. Multiple containers may be active at the same time in a UI in order to allow multiple views to be displayed simultaneously. A container may attach to a logical application, enabling multiple containers to be attached to the same engine although in different processes.
Engine
The Multichannel Engine, or The Engine, is effectively a workflow runtime with additional capabilities. There will be one instance of an engine per AppDomain. The engine will be referenced by one or more Containers. It can also host services such as workflow services attached to the workflow runtime in the workflow foundation. Workflows running inside the engine will ask for these services whenever they need to access specific services. In response to a command request from the container, the engine will load a work unit corresponding to that request. This can require the creation of new work unit or resumption of an existing work unit.
Physical Unit Selector
The physical unit selector is a component that loads physical providers and physical views on demand when a navigational workflow needs a logical view to be represented. The physical unit selector chooses the physical view most suitable to the request.
Work Unit
A work unit is a data structure that is commonly made up of a navigational workflow and one or more logical views. A work unit manages the process-specific, channel-independent navigational workflow and the associated logical views. Work units can be dehydrated and compacted into a binary blob, saving all the current workflow data and state of the UI at that particular moment. When rehydrated, the engine will manage the creation of all the needed views and their resetting to their original state, independent of the technology when the rehydration occurs. Work units can exchange messages with their logical views, their parents, their children, their children’s views, and the external hosting environment.
Navigational Workflow
A navigational workflow is written by the customer and drives the business process. It is technology-independent and can be passive or rehydrated. It communicates to the Logical view(s) which are also technology-independent.
Navigational Workflow Activities
These are a set of Windows Workflow Activities able to interact with the engine. They contain such activities as:
- event handling activities
- activities that interact with the logical views (events and commands)
- activities that spawn child work units
- activities that send and receive events from outside of the work unit
- activities that persist and rehydrate children
Navigational workflow will also be able to interact with the CCF DCS infrastructure using the available proxy activities.
Logical View
A navigational workflow uses the logical view to communicate with the physical UI in a way that is independent of technology. The logical views are composed of field definitions, event definitions, command definitions, and nested containers.
Physical Provider
Physical providers expose a standard interface that interacts with any physical unit the engine handles. Multiple physical units may be handled simultaneously if the container or another physical view provides support for them and a visual region where they can be rendered, such as a screen space. These providers are responsible for the conversion of events from the targeted technology to the Event Broker format and vice versa.
Model View Controller Pattern
If we consider the MCE as an implementation of Model View Controller (MVC), the controller is the navigational workflow and the view is the logical view. The model will be represented as properties of the workflow. These may dehydrated and rehydrated, possibly persisting on a back end system. Contrary to most implementations of the MVC pattern, where a view is mostly a physical view and there can be multiple physical views for the same model, MCE attempts to be channel-independent. It shields the navigational workflow, which defines the navigation for the business process from the rendering technology, and hence uses the concept of a logical view. A logical view is a means of communicating with the model (data) and the actual physical views.
Work unit Passivation and Rehydration
In order to allow the engine to show a display when executing a UI process, a containing space must be provided to it by one or more containers. These containers are controls that expose a particular API to the engine so that it can present physical views in those controls. It is possible to create new containers or to customize existing ones.
Upon execution of a work unit, a navigational workflow is executed in order to run the process logic. A navigational workflow can present a particular logical view as described by the work unit’s internal metadata. When a logical view is presented, the engine invokes the physical unit selector. This selector locates the physical view most suitable for the particular request along with the physical provider able to handle that particular physical view. The view is then presented in the container selected by the workflow and is bound to any data the workflow has and any events the workflow wants to receive via that physical provider. A view can also create new containers by subdividing its space, making them available to the controlling workflow.
Finally, the work unit can also spawn child work units, assigning them some of the space it owns, such as containers, to create reusable units of UI process that can be shared across multiple parents.