title: Limiting client knowledge of workflow
body: <p>Scenario:</p>
  
  <ul>
  <li>Windows Workflow Foundation (WF) under .NET 4</li>
  <li>Workflow deployed as a WCF service</li>
  <li>Multiple Receive operations, all with the same parameters</li>
  <li>Operation name matches activity name</li>
  <li>Using SQL Server workflow persistence</li>
  <li>(No SharePoint)</li>
  </ul>
  
  <p>By default, knowledge of the workflow is embedded in the clients when you add a service reference and generate the proxy. The client knows what WCF methods are available.</p>
  
  <p>I want to decouple the workflow from the clients, essentially creating a "generic" client that can work with any workflow matching certain conventions. The client would query the SQL instance store to determine what activity/operation/bookmark(s) a given instance was waiting for (this is already a standard column - ActiveBookmarks), then present that choice to the user.</p>
  
  <p>This way the workflow can be changed without having to recompile/redeploy the clients. Several commercial BPM systems work this way; you can add new human client activities and they show up automatically in the client's work queue. Everything is dynamically discoverable.</p>
  
  <p>How can this be done? Does it require using Reflection.Emit to generate a proxy on the fly? Would it be easier if each operation used a different service contract?</p>