Поделиться через

Meet the WCF Channel Model - Part 1

  • Статья

For the past 5 months or so, I’ve been working on the WCF Core Communications team (with Kenny, Matt, and Steve) where we focus on WCF transports and hosting features. In this period, I’ve learned a lot about the WCF channel model and I’m still learning a lot. I want to share some of what I’ve learned with you on this blog. So here’s a first of what I hope to be many posts on this topic. Kenny also has several posts about this subject on his blog.

The WCF runtime consists of two layers: The channel stack and the dispatcher/proxy. The channel stack is responsible for sending/receiving messages between the sender and receiver while the dispatcher/proxy layer is responsible for translating those messages to/from service method calls.

The channel stack is where WCF gets a lot of its power and versatility. It’s similar to the traditional OSI model in that there are cleanly separated layers with each layer using the services of, and only calling on, the next layer down. It’s also very different from the OSI model in that there aren’t n well defined layers each with their specific role. Instead, there are two types of channels with implementations of these types allowed to compose in different ways depending on the application’s needs.

At the bottom of the stack is a transport adapter channel (aka a transport) whose role is to adapt an underlying transport to WCF’s channel model. For example, WCF ships with HTTP, TCP, Named Pipes, Peer to Peer, and MSMQ transport adapters allowing you to use any of these technologies as a means of transporting messages between sender and receiver. Each transport adapter can use an encoder that transforms WCF messages to the appropriate format for the transport. WCF ships with three encoders: text XML, binary XML, and MTOM. You can mix and match transport adapters and encoders unless the transport adapter has some restriction on the type of encoder it needs.

Above the transport adapter is zero or more protocol channels. These are channels that perform some kind of message transformation as a means of communicating with the equivalent protocol channel on the other side. For example, WCF ships with security, reliable messaging, and transaction flow channels. Each of these channels add/read headers to/from the message and some of them modify message content and even send their own messages (reliable messaging sends ACK messages).

One of the key differences between WCF and existing distributed app technologies like ASMX or ES, is this ability to use any transport (through transport adapters) and compose any number of protocol implementations within the communications stack. .NET Remoting has similar features (extensibility allowing you to plug in custom transport channels and chains of message sinks that could act as protocols) but WCF takes this further by providing a richer channel model that captures the fundamental communication patterns (input, output, duplex, request/reply).

So why is all this flexibility and extensibility good? Those of you who know me will know I’m a pragmatic guy so I would not say something is good just because it’s cool technology. WCF is the next generation distributed applications framework. It will be used for a long time and for many diverse scenarios many of which we don’t even know yet. Product extensibility is essential in this case to satisfy such diverse scenarios. For example WCF/WSE 3.0 interop over HTTP is supported by WCF out of the box but there are some scenarios where customers may want to interoperate over TCP. In our PDC talk, Kenny showed a custom TCP transport adapter that allows Indigo to talk to WSE 3.0 over TCP. The fact that it was possible, and relatively easy (OK, Kenny owns our TCP transport adapter so he knows this stuff inside out) to enable such a scenario speaks volumes for WCF’s channel extensibility. Another powerful scenario is when a customer wants to use WCF to communicate with a existing system that exposes its functions only through a proprietary network API. The customer can write a custom transport adapter that adapts the proprietary network API to WCF’s channel model allowing WCF developers to access the existing system without having to learn a new API.

These rich scenarios are what excite me the most about WCF’s channel extensibility. As more customers start playing with WCF, I think we’ll see a proliferation of custom channels both from ISV’s as well as within the enterprise.

Comments