WCF ChannelFactory State Property

Question

What does it mean for a ChannelFactory to have a State property? I understand that a created channel can have connection based states. But am confused as to why the ChannelFactory also has such connection states. Does it too connect to the WCF service?

Karlsbad

I think this is a good question, and one I'm also curious about. Surprised no-one's had a stab at it. – Distillate

Answer 1

A ChannelFactory object has a State because it is a CommunicationObject, and all CommunicationObjects in WCF have a State. Of course, that's just begging the question, and not really helpful.

The real question boils down to two parts

1. Why does ChannelFactory derive from CommunicationObject
2. What does its State actually means?

The second one is easier to answer so lets start there. The State of a ChannelFactory determines whether or not it can be used to create new client channels, and whether or not those client channels can still be used.

As with all CommunicationObjects in WCF, the State determines what operations you're permitted to do with the object. A channel factory really only has one operation: CreateChannel. If the factory is Open you can create channels; if it is Closed or Faulted, you cannot. The concrete (internal) channel factory implementations (say, and HttpChannelFactory) clean up any internal resources when they are Close()'d; this includes freeing resources that were created for security purposes, releasing handles to named pipes, etc.

In addition, when you Close() a channel factory, it loops through all of the channels and calls Close() on each of them, before transitioning into a Closed state itself. (There appears to be some common utility code (creating HTTP requests, etc.) that the channel factories implement on behalf of their channels, such that the channels could no longer function once the channel factory was shut down. This is why the channels are forced close at the same time.)

For all the gory details, go download the WCF Reference Source, but be prepared to lose a day or so :)

The bigger question, then, is why a ChannelFactory is a CommunicationObject at all? Here, I'm resorting to guessing, because as far as I can see the factory objects themselves never actually communicate to the remote system. However, they do perform a lot of setup and validation of their binding's parameters before they create a channel, which requires allocating the same kinds of resources that an actual network connection does. The named pipes channel factory, for example, creates and managed a connection pool for its channels; the HTTP and HTTPS channel factories validate identity information and authentication values. My guess is that the channel factories do this setup work once, so the channels can skip it; the CommunicationObject pattern simply provided a convenient way to manage the lifetime of a channel factory, since everything else in WCF is managed that way.

Eveland

I suspect that all channels route through the channel factory. Think of it as a flyweight pattern endpoint and binding configuration, and the connection state. Technically, the ChannelFactory would be the object in charge of the connection. The channel just exposes the contract. – Cristal

Answer 2

I think this is interesting, I don't know the answer but I'd hazard a guess that the ChannelFactory may keep resources available in case other channel instances will use the same resource (either simultaneously or in the near future).

For example, if you use a channel factory with a Channel stack that uses the TcpChannel as the Transport channel, the TCP connection may be managed by the ChannelFactory as multiple Channels could potentially re-use the same TCP connection, this saves on the performance overhead of tearing down/re-initating the connection.

So when you close your channel, the channel notifies the channel factory that the resource is no longer needed, the channel factory is then free to release the resource as and when it sees fit (i.e. after a timeout?).

I can check this if this is the case if no one else provides a good answer.

Blake