Before we delve into Mce let us try to dissect the term UI process. A UI process should have its controller logic, in our case it is going to be Windows Workflow. Since a controller interacts with the views as well, we need to hold a reference to the views participating in the UI-Process. Next is the data (a.k.a Model in MVC). Hang on, the UI process that we are talking here has to be reusable across channels, hence it cannot be holding references to the views it driving.
There are multiple ways of fixing this problem, the most common is using a set of fixed interface that every participating view has to implement and controller (Workflow) communicates to the view(s) through this interface. This looks fine when you are developing a fresh set of user interface elements. What if you would like to re-use some of the views (for e.g. windows user controls, web user controls etc) from your existing application? Re-writing each view to implement the interface is not going to be that easy. Another approach is to write the controller logic against a set of UI abstractions. i.e. your controller logic will be written against a set of user interface abstractions instead of an interface or the views themselves, let us call this abstraction as a Logical View.
A reusable UI process contains the controller logic + a set of logical views (against which controller logic is written) . This concept is abstracted as a WorkUnit in Mce. Hereafter I will not be using the term UI process a lot , instead you will see references to WorkUnit a lot. A WorkUnit in Mce represents a reusable navigation logic written using the Workflow foundation workflow and associated Logical Views. I deliberately omitted the discussion about data here, but we will come back to how data is handled in a WorkUnit in Mce.
As mentioned earlier, LogicalView is a channel independent abstraction of a Physical View (Windows form, Web User control, etc.). Hence a LogicalView contains properties (name and data type), events the view can raise and commands that you can perform on the view (or else functions that you can call on the view, if you have an instance of the view).
In Mce a Navigational Event represents channel independent abstraction of an event that the physical view will raise, for e.g. if the user clicks the next button in the physical view, you may want your controller to react a Navigational Event called "Next". In short you can write your controller logic against logical views and navigational events from those logical views.
Mce Navigational Workflow is the controller logic that you write using Windows Workflow foundation. You can write state machine or sequential workflows, state machines are the ones most commonly used.
We talked about controller and views. How about model/data?. In Mce data that the controller interacts is actually represented as properties in the LogicalView itself. Hence the navigational workflow that you write is actually a controller + data/Model. This is done for the obvious reason of moving the controller logic across channels. When you move the controller logic from one channel to another you get the updated data values as well.
Enough of this diatribe, in my next post we will get our hands dirty with Mce in CCF 2009, and I will be covering more concepts and related terminologies as we proceed