The best architecture depends on what your non-functional needs are (for example: is this a tool that will only be used internally or are you going to sell it? How many users? Where and how will users be able to access the system?), there are a lot of quality attributes you need to think about.
The fact that you're dealing with WF4 isn't that relevant - connecting to a back-end server 'service' like this is fairly common. WF4 might have some "special" ways you can integrate with it but I don't know what those specifics are - perhaps they are what you're after?
High Level Architecture
Nothing fancy needed here, 4 main layers:
- UI Tier: (you might have more than one UI, and hopefully they can shared code.
- Business Logic: although the MS WF Server will be doing all the "heavy lifting" as far as the WF's go you'll still want to have a place where you can put common logic.
- Integration Layer: this will be a few things, possibly Dependency Injection (DI) or a Facade to the MS WF server, so that when MS makes changes you're not explicitly tied to them (as much). You'll probably also need your own Data access layer - use this integration layer to abstract and integrate with that too, as well as any other services you want to offer or consume.
- Data Repositories and Custom WF Services: For holding data of your own, and deeply integrating with WF4.
UI - WF Designer
Designing workflows isn't trivial, building a UI / system that allows users to do that is even harder, so my guess is you'll want a UI technology that allows rich interaction - perhaps SilverLight is an option? This would allow you to deliver the app over the internet if need be (might be good for users who are connecting remotely).
Other options include HTML (think HTML5) or a thick client: this is where the environment of your users is important - what level of control do you have over it / what constraints are forced on you?
UI - Workflow Monitoring
Plenty of options here, this is where you need to get into dialog with your users and see what they want. You might want to offer several ways to monitor the execution of workflows:
- A "rich" UI that allows comprehensive monitoring (think admins and power users); SilverLight might be a contender again (assuming you use it for the WF designer).
- Assuming it's "read only" you might be able to use a more open / low-tech approach - such as straight HTML (not that HTML is necessarily low-tech these days). Keep in mind that if you want to show a graphical representation of a workflow you'll basically be building a cut-down version of the WF designer.
- If people just want really basic summary info you might be able to augment the main UI's with smaller widgets that users can use to keep an eye of key WF's - like an add-in for FireFox, a small TaskBar monitor, etc.
Busiess Logic (BL)
This should be straight forward, but think carefully about how you integrate with WF - on the one hand binding yourself to it directly will provide some excellent opportunities to quickly deliver cool functionality - but on the other hand you'll be tightly-coupled to WF: if it changes you're in trouble.
I imagine the BL will need to consume information from a variety of places - some of which you'll invent yourself: these should all be abstracted out behind an interface (DI).
You might also provide some services (for populating AJAX driven UI controls, driving widgets, etc); put as much logic in the BL as possible and provide different channels to it via the UI and Integration layers.
I'm guessing this will need to be wrapped up as a Windows Service; if you keep your core logic cleanly defined you should also be able to re-use it in a Website, WebServices, etc.
Integration Layer
This might be relatively thin, have a look at some DI frameworks before you go rolling your own; WCF is an obvious option too.
Data Repositories and Custom WF Services
This layer will hold the concrete implementations of any data repositories you create. It will also contain any custom WF components you make. Remember that these layers are logical in the first instance, but also translate into physical layers a lot of the time as well. At some point you're going to need to write code that runs directly against WF4 - that's cool but you want to ensure that code is as small and "throw-away-ible" as possible; the architecture described here should allow that. So, when you develop the code components that deeply integrate with WF4 keep them small and modular - easy to replace, consume them via the integration layer; all you have to do is keep loose-coupling in mind: DI, etc.
Final Considerations
- Once you have some idea of the High level architecture, have a look through the WF4 documentnation - what you're looking for are integration options that fit.
- If you're only talking about simple workflows for document management you might take an approach where users didn't design workflows, but merely configured them; in this case you wouldn't need a complex / smart WF designer. In parallel with this you'd design your system so that you could easily deploy new workflows for use / configuration.