WCF Compression: a solution.

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.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: