Not a lot has been talked about UI Processes. You do a live search or google search for UI process and first result you get is Microsoft UI process application block. I tried Wikipedia for a standard definition without any luck. The only definition I could find is again from Microsoft UI Process application block tutorial which is
Microsoft UI Process Application block is the popular framework in .NET which allows you to implement UI Process functionalities in your application. But if you look at the server side counterpart (I mean, Business process orchestration) we have many standards products and frameworks ranging from BizTalk to many ESB frameworks. Lets see why it pays to care about UI Process as well
As the definition implies UI Process defines a navigational logic that you perform to achieve a goal (e.g. pay your Credit card bills online, Set archiving rules in outlook etc.). To abstract away this navigational logic, we can use good old MVC pattern. Hence often when you talk about UI Processes you invariably end up talking about MVC and how you can centralize the controller logic
Windows workflow foundation’s support for creating state machines makes it an excellent framework for creating our controller logic. You can think of the navigational logic in a UI process as a set of state transitions that the views undergo in response to user events. Workflow Foundation’s excellent designer support makes it more compelling to use it to define your controller logic
Why should we ever reuse our controller logic? Enterprises are developing applications that already support multiple channels of interaction and most of them have ambitious plans for supporting more channels in future. A channel here means the medium that user interacts with your application. E.g. Web, Windows, Mobile are all possible channels. There are two compelling reasons for creating reusable controller logic.
1. To support more channels in future without re-writing your controller logic.
2. Modify the controller logic centrally and at once and reflect it on multiple channels simultaneously
Most of the complex processes an enterprise has, do not necessarily start and end in one channel, instead they span across multiple channels. In this case how do you carry forward your navigational logic from one channel to other? Again Windows Workflow Foundation provides excellent support with passivation and rehydration of the state of the workflow. This means that if you write your controller logic (Navigation logic) using Windows Workflow Foundation you may be able to passivate the workflow in one channel and rehydrate in another channel. But again the workflow has to be channel agnostic.
Once you find that the reusability aspect of your controller logic is important, you start thinking how do I write my controller logic (State Machine Navigational Workflow) in a channel agnostic way? For e.g. you write a state machine workflow that drives a set of windows forms and you want the same workflow to drive a set of web forms or WPF forms. The best way to do is to create your workflow against a set of UI abstractions and depending on the channel the workflow is running it can drive either a set of windows forms or web forms or WPF forms.
CCF2009 ships with Multi Channel Engine (Mce) framework which helps you to create channel agnostic workflows for your controller logic. Mce defines a set of UI abstractions and helps you to define your navigational workflow (controller logic) in a channel agnostic manner. In this blog I will be talking about how you can leverage CCF and Mce to create channel independent reusable UI Process for your application