ListenUriBindingElement

The story from yesterday: there is an important setting for composite duplex that is only settable through the binding context. Unfortunately, proxy clients automatically create and use their own binding context so there is no convenient time to poke in a replacement value for the setting. What kind of a workaround can we come up with?

Since there is no convenient way to intercept the binding context at the producer, we'll instead need to intercept the binding context at the consumer. The consumer of the binding context is the channel construction process of the binding. In particular, we need to modify the ListenUri setting before we reach the BuildChannelListener method of the composite duplex binding element. That means our opportunities for interception are going to be in methods such as CanBuildChannelFactory, CanBuildChannelListener, BuildChannelFactory, and BuildChannelListener. The binding context instance gets passed along from binding element to binding element so it is safe to modify the setting at any opportunity along the way. We don't have to worry about finding the correct instance of the binding context. Every instance that we see is one that we want to modify.

The solution that I came up with for this problem was to write a binding element that modified the ListenUri as the binding context went by. Other than this change, the binding element simply delegates every method to the next binding element down. You can position the binding element in the channel stack so that your customization is always reached before the composite duplex binding element. The binding context that composite duplex receives contains your modifications, giving you full control over the ListenUri setting that was otherwise hidden. This solution is generally reusable for other situations where you need to modify the binding context or channel construction process. I won't say that there are many such situations, but it is a tool for you to use.

An interesting coincidence about this problem was that two different people on consecutive days with different scenarios were looking for a solution. Mike Taulty was the second person and he's done a write up of why he was interested in composite duplex and the code I gave him for the ListenUri modifying binding element. Mike added configuration support, which I hadn't bothered with. From configuration, you'll need to build out a complete custom binding. From code, it's simpler because you can start with an existing binding and simply insert the binding element into the binding element collection at the top of the channel stack. However, configuration makes it much easier to just drop this into a working program.

Next time: Unprotected Metadata

Comments

• Anonymous
  December 07, 2006
  The ListenUri is a three-part setting on the BindingContext that gives the server-side address of a connection.

• Anonymous
  December 14, 2006
  I am SO busy with INETA trips and tons to do at work. Here is what I have stored up for the last week

• Anonymous
  October 20, 2007
  I am SO busy with INETA trips and tons to do at work. Here is what I have stored up for the last week

• Anonymous
  December 03, 2008
  I am SO busy with INETA trips and tons to do at work. Here is what I have stored up for the last week or so. WCF/SOA/Workflow/WF Tomas blogs about something I face every day in WCF with WCF ServiceHost Failures and IDisposable with "The "don't