WCF Data Services + Reflection + Custom Data Provider = Configurable OData Service

Part 1 Intro

I really enjoy a good technical challenge, in this day and age of highly evolved frameworks and tool kits it is good to get a set of requirements for which there is not an obvious out of the box solution for. One that requires a little bit more than a few LOC and a bit of configuration tweaking.

Background

The challenge which I was presented with, was in the context of a windows workflow 4 (WF4) project for which I am in the midst of designing and developing a number of components. The project is to integrate WF4 into the main product line. The aim is to enable end user business analysts or customer service consultants to design a set of workflow processes that are unique to each customer.
The main components of this solution are the following:

• Workflow Designer – A WPF application to enable the design, management and deployment of workflow processes
• Workflow Activities – A set of custom activities that encapsulate common business actions
• A Workflow Engine – A host component to manage the execution, lifecycle and versioning of the various running workflows that a end user can design
• A Domain Model Service – A service which exposes a consistent, version invariant view of the applications data model

Future blog entries will cover some of the other components. This is the first post in a series that will cover some of the background behind the Domain Model Service

Requirements

• Enable Users Define Entities
  • The Domain Model Service should allow an end user to define a Domain Model entity via a designer invoking an API
• Support CRUD on Entities
  • The Domain Model Service should support CRUD operations on all Entities that are defined
• Enable Database Abstraction
  • Expose Entities in a manner that allows attribute names and entity names to differ from that of the underlying data store. This prevents implementation leaking out to the upper layers
• Enable Versioning
  • A workflow instance can potentially execute indefinitely. It is therefore a requirement to maintain multiple versions of the Domain Model
• Enable Query Of Entities
  • Allow an Entity to be queried by any combination of its attributes

The Solution

Metadata Store – This component is the store of all Domain Models and the entities that are defined for each of the Domain Models. The data within this store is managed by a different set of components, which are beyond the scope of this post.

WCF Service – This component provides the hosting and lifecycle management for the WCF Data Services (OData), which are defined within the metadata. This component exposes the OData services each of which exposes a version if the Domain Model at a different unique URL. It would have been possible to host each version of the Domain Model in its own process but this is not required for the initial implementation. The Domain Model services could be hosted in an own process if required in the future.

Data Type Generator – This component generates the set of entities for a given Domain Model through the use of reflection.

Domain Model Service – This component is the realisation of a concrete implementation of a Domain Model version. This is a WCF Data Services (OData) service that uses the Custom Data Service Provider as the source and sink of the Domain Model data that it exposes.

Custom Data Service Provider – This component provides the data and the mechanisms for querying an updating Domain Model objects for a given Domain Model Service instance.

In the following posts I will delve into more detail for each of the components.

Part 2 – Data Type Generator
Part 3 – Custom Data Service Provider
Part 4 – WCF Service Host
Part 5 - Put it all together