Slicing the Windows Communication Foundation Technology Stack, Part 4

Yesterday, we looked at an architecture change from a buffered transport strategy to a streamed transport strategy.  Making this change improved the scalability of the service by eliminating the large memory allocation for each concurrent connection.  I mentioned last time that one consequence of making this change is the need to switch from message security to transport security.

A consequence that I didn't mention is that changing the transport transfer mode from buffered to streamed also changes how we expose the TCP/IP transport to your code.  WCF has a number of built-in design patterns for sending and receiving messages, called 'channel shapes'.  I will be going into detail about channel shapes in a few weeks, but what's important to know is that changing the transfer mode causes the TCP transport to use a different channel shape.  To update the application code, you will either need to change the channel shape you expect to get back or use a shim that implements one channel shape in terms of other shapes.

Using a streamed transfer mode is not the only way to avoid the cost of buffering large messages.  Next time, I'll reslice the problem and present an architecture that doesn't require changing the security mechanism or channel shape.

Next time: Slicing the Windows Communication Foundation Technology Stack, Part 5

Comments

• Anonymous
  February 14, 2006
  Continuing with the same seemingly simple web service scenario as before, last time we saw an obvious...
• Anonymous
  February 17, 2006
  In this series, I've gone through one set of problems that we encounter with buffered transfers, and...
• Anonymous
  October 17, 2006
  Continuing with the same seemingly simple web service scenario as before, last time we saw an obvious