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”