Regarding my last post, I sent an email to Nicholas Allen asking for his advice, and his latest blog post confirms my belief that it would be a dumb idea to do encoder level compression if we are doing message level security. What I have tried, and it seems to work pretty well, is to use message inspectors to do the compression/decompression as, from the documentation, it seems these execute just as the message is generated (before they are secured or encoded), and then last on the receiving side (after the decoding and decryption take place). This seems to work well. My only concern, though, is that there doesn’t appear to be any kind of standard as to how to represent compressed data in SOAP. So, if our application requires compression in order to function efficiently over the WAN, we must necessarily decrease the level of interoperability. It would, presumably, not be too difficult to re-implement this compressor/de-compressor on other SOAP stacks, but I’m not too aware of how extensible these are, on a whole. One would presume, that because SOAP is, by its very nature, very extensible, that any SOAP stack would have to also be very extensible, but I’ve been burned by this type of wishful thinking before.
WCF Compression: a solution.