Contract Projection in WCF 4.0

WCF 4.0 introduce a concept “Contract Projection” – exactly ‘the right term’ I have tried to find while expressing the logical diagram of service concept, but called it “payload serialization/deserialization”. This concept of Contract Projection is about dcoupling integration logic from service, about posibility to have stable interface (type based .NET ) decorated with contract attribute (I call it mapping interface to contract) and multiple expression of how the contract will be used for integration with consumers. That is- what message format, encoding, protocol it will use. Contract Projection together with flexibility of binding through endpoints represent great way how to shield service code from interoperability standards details. So whether you want to access service through endpoint A, or endpoint B using JSON, SOAP,GeoRSS,GeoJSON, OGC/WPS,etc.. doesn’t matter. This is “flexibility of integration”.

“The .NET Framework 4.0 introduces the concept of a contract projection to separate the logical contract definition from the representation of the messages that are sent and received. This allows you to define a single-service contract that can be projected differently to support different messaging styles. For example, you can have one contract projection for SOAP-based messaging and another projection for REST/POX messaging, but both are based on the same logical service contract”

http://msdn.microsoft.com/en-us/magazine/2009.01.net40.aspx

 

WCF- Dispatcher graphics

trying to understand WCF extension model, I have reconstructed ServiceModel.Dispatcher namespace with most important information related to ChannelDispatcher, EndpointDispatcher and dispatchRuntime plus operation Runtime. This is first version, the diagram is layout to reflect message passing from up to bottom.

Full picture [400KB]
message dispatcher thumbnail

Follow-up of this model for ServiceDescription can be found here

Following sequence is how it flows in WCF model when executing an operation (not exhaustive):

1. reached EndpointAddress
2. performing EndpointAddressMessageFilter : Match operation returned: True
3. performing TrackContractFilter : Match operation returned: True
4. called OperationSelection: Method to call: MyMethod
5 called AfterReceiveRequestEvent for binding http://tempuri.org/:BasicHttpBindingEndpoints: 1
6. Constructor of Service MyService called : class instantiated
7. called AllocateInputs
8. called ParameterInspectionBeforeEvent
9. called InvokeOperationEvent
10. Method/operation MyOperation is executing…
11. called ParameterInspectionAfterEvent
12. called BeforeSendReplyEvent