WCF, POX and Encoders
Nicholas Allen has been writing about some of the changes in the June CTP of WCF (his blog is an excellent resource, by the way), and in entry #2 he talks a bit about some changes made to better support POX style applications in WCF. I'm very happy the WCF team is doing the right thing and fixing this kind of issues to support other application styles other than SOAP at the right level of abstraction in the platform. That's a very, very good think, particularly this early into the product lifetime (I'm assuming we'll get multiple versions of WCF over a number of years).
That said, one thing did get my attention: that the right abstraction level to fix this in was the normal Text Encoder. There are several good blog entries by several Indigettes on the topic of Message Encoders, but I'm not so sure I fully understand exactly how much (or many) responsabilities a Message Encoder has to fulfill in the WinFX architecture. Is there somewhere an explicit list of what those responsabilities are?
Maybe I'm misunderstanding how this goes, but it seems to me like the Message Encoder combines responsabilities for both message on-the-wire representation (i.e. XML, binary and so on), message encoding (in the case of text messages like XML), message assembling (i.e. introducing headers) and a few other things.
Comparisons are never nice, but they are incredibly useful to understand technology. One thing I would love to see is a comparison of the WCF channel and message encoder architecture to the BizTalk messaging architecture. They are definitely very differen beasts serving different purposes, but what I'd really like to get a hold on is how the functionality and extensibility offered by BizTalk pipelines (multi-stage, with clearly defined responsabilities for each stage) relates and compares to how WCF processes incoming messages and generates outgoing messages. I think this becomes even more interesting (and important) with the appearance of the WinFX adapter framework (here's a good introduction) coming in BizTalk Server 2006 R2.
Fundamentally, the job of a MessageEncoder is fairly simple. It takes in some random bytes (a byte[] or a stream) and surfaces an instance of System.ServiceModel.Channels.Message up to the higher layers of the stack. How that transformation gets accomplished is designed to be opaque to the rest of the system.
We think of encoders as things that freely convert between two equivalent representations of the same fundamental information set. More advanced transformations (e.g. adding/removing headers) are best done above the Encoder as layered channel. Our general rule is that an Encoder changes only the representation of the message, not its information model or contents.