March, 2007

Can I write a point-to-point router service by setting the Via property for outgoing messages?

Like most things, this is going to depend on the specific behavior of the transport channel you're using, but in general the answer is no. The transport channel owns the Via property and it will stomp over whatever you write into the message headers. You do have one opportunity to set the channel's Via, which is during the creation of the channel from the channel factory. After that, the matter is out of your hands.

This would imply creating a channel per message or keeping a pool of these channels around to farm out messages if you keep using the same destinations over and over. There is a different story if what you want to route to is the ultimate receiver To address instead of the Via address. You can set the To address on a per-message basis, assuming that the transport channel has implemented the ManualAddressing setting.

Next time: Enabling Kerberos in IIS

A few days ago I decided to upgrade my home machine from 1 GB of RAM to 2 GB. I've been running Vista at home since last summer and it occasionally gets cranky when it runs out of memory. After the usual problems of fiddling with hardware, everything seemed to be working. Except, Windows Update couldn't find any updates and Outlook couldn't connect to my mailbox. Of course, there wasn't any explanation of what was wrong; they just seemed to have stopped working. I thought that it might be a network problem but I could go to websites without any problem.

This lasted for about 10 minutes while I was trying to find a solution, until I went to a website that required SSL. That was when I was surprised to see that the website's certificate was expired, and enlightened when I looked at the details and saw that the certificate was expired because it hadn't been issued yet. The problem wasn't with Windows Update, Outlook, or the website at all, of course. At some point during the hardware upgrade, the onboard clock had been reset to the factory default time of several years ago.

This got me thinking about how fragile distributed systems are when clocks are involved. There is an implicit assumption in many systems that network synchronized time will take care of the problem, but clearly synchronization doesn't happen fast enough to cover for certain kinds of failure. These failures make it a bad assumption that the clock time will be reasonably accurate in between the interval of synchronization.

Ten years ago I was reading a lot about clockless and unsynchronized systems that only required a steady flow of local time and not a globally coordinated time. This approach seems to have fallen out of favor with ubiquitous Internet connectivity and network time servers. It would be interesting to get an idea of how vulnerable distributed systems are to inadvertent or malicious clock skew on the client and server. I know that many of the common transfer protocols absolutely cannot deal with more than a few seconds of skew and even local behavior like timeouts can be affected by clock changes. Application behavior is also very dependent on accurate timestamps for processing messages. However, I don't think that people pay a lot of attention to this potential weak point in their operations.

Once you've obtained a channel manager from the binding element, you have the first object that is usable for network communication. Although the two kinds of channel managers, channel factories and channel listeners, share many of the same methods, the use of those methods tends to be quite a bit different. I'm going through just the client-side channel factory in the list, but I'll point out some bits of information that differ between channel factories and channel listeners.

To get a minimally working channel factory for a custom channel, you need to think about what you're going to do in five particular methods.

1. The holdover from binding elements to channel managers is GetProperty. The implementation of GetProperty should at a minimum return a response for every interface that you had support for on the binding element. The return value itself should be exactly the same as well, for the values that would have been returned at the moment you created the channel factory. Future changes to the binding element settings should never change the values returned by the channel factory.
2. Open is a hook to let you perform some work prior to making the first service call. This is your chance to do any preconnection work, like looking up credentials, that you want to have costed during startup rather than taking time during a service call. When programming against a service with a client proxy, opening the proxy is an optional step. However, even if the user doesn't open the proxy, your channel factory and channel will get opened prior to the first call taking place.
3. Close is the hook to let you clean up any state left behind that takes time to get rid of, such as open network connections. There is a different meaning for Close between channel factories and channel listeners. Closing a channel factory is supposed to similarly close all of the channels created from that factory. Closing a channel listener doesn't touch the existing channels. Therefore, you're going to have to structure your state differently between the channel factory and channel listener. For the channel listener, you are essentially forced to push more state into the channels so that they can survive the destruction of their channel listener.
4. Abort is a similar idea to Close, but is a part of the ungraceful shutdown process. Rather than nicely cleaning up the state, you are expected to take care of the state problem by blowing it away with abandon. Abort should never do anything with the network or other blocking operations. Just make the channel manager go away as fast as possible.
5. The workhorse and probably the only interesting method in most channel factories is CreateChannel. CreateChannel is what actually stamps out channel instances for use by clients. Channel listeners have several variants on accepting, which is the rough equivalent for the server. Accepting is generally a more complicated process because it is a combination of the user wanting a channel and some external connection arriving.

Next time: Setting the Message Via

We're back to the channel development series for another pair of days. When I left off, I promised to talk a bit about writing binding elements and channel managers. Today's article is about writing binding elements and tomorrow's article is about writing channel managers. These articles expand on the checklist items for the steps you have to take while writing a custom channel. To keep things simple, I'm only going to talk about the client-side part of the equation. Where needed, I'll point out that there is an equivalent server-side piece that you need to implement as well.

To get a minimally working binding element for a client channel, you need to think about what you're going to do in four particular methods.

1. CanBuildChannelFactory is how you plug into the evaluate step of the channel construction process. This method allows consumers of your channel to validate whether construction is going to succeed without actually performing the build process. You should put your validation in a common place rather than duplicating it between the evaluate and build stages. It will save you a lot of trouble whenever you update your channel. There's a corresponding method for the evaluate stage on the server.
2. BuildChannelFactory is how you plug into the build step of the channel construction process. This method produces the channel manager object used by the next layer of the build process. Primarily what you're doing here is copying settings from the binding element to the channel manager so that future changes to the binding element don't affect existing channels. There's a corresponding method for the build stage on the server.
3. GetProperty is a query interface for dynamically discovering information about the channel. Any properties you don't recognize should be passed to the inner binding element so that channels further down in the stack have a chance to respond. I'll have more details about the interfaces you should implement with GetProperty later.
4. Clone produces an exact copy of the binding element. You should implement Clone by creating a copy constructor and doing all of the work in the constructor. Clone will be called many times during the evaluate and build processes. It is essential that modifying the cloned binding element does not affect the original binding element.

Next time: Writing Channel Manager Essentials

I know that 80% of you read this blog using RSS and just about 70% of what's left are coming here because some cold, calculating search engine algorithm has told you that this just HAS to be the information that you're looking for. However, every once in a while, someone comes and reads an article here because an actual person said that that would be a good idea. It boggles the mind.

At one point in time, MSDN used to provide me with piles of data to see exactly how people were getting here. Now, I get a much murkier picture even with search engines and analytics ostensibly for making that job much simpler. Still though, over time you can see the trends in discussion and spot those that are regular readers and referrers versus those who have just wandered by. This list is from the last three months of data, but just about any month in the near future I'd expect a majority of those here to show up again.

1. wcf.netfx3.com
2. forums.microsoft.com
3. theserverside.net
4. weblogs.asp.net
5. netfxguide.com
6. codebetter.com
7. ddj.com
8. winterdom.com
9. pluralsight.com
10. skyscrapr.net

If you've wondered where else you should go looking for WCF content, this is probably a good place to start.

How do I prevent clients from accessing my service anonymously? I've changed the settings in IIS from Anonymous Access to Integrated Windows Authentication. However, now I'm getting the error message: "Security settings for this service require 'Anonymous' Authentication but it is not enabled for the IIS application that hosts this service."

Disabling anonymous access requires coordinating the settings in IIS and in your service configuration. Those two sources must be in agreement about whether anonymous access is expected. IIS is already using Windows authentication in this case, so let's look at what needs to happen to the service configuration file. I'm assuming that this is IIS6 so the only network transport we're talking about here is HTTP.

There are two cases depending on whether you want the protocol that gets exposed to be HTTP or HTTPS. The simplest is to keep using HTTP since that's probably what you were using if anonymous access was allowed in the past. To switch off anonymous access with HTTP, you need to set the security mode to TransportCredentialOnly.

<basicHttpBinding>
  <binding>
    <security mode="TransportCredentialOnly">
      <transport clientCredentialType="Windows" />
    </security>
  </binding>
</basicHttpBinding>

Note that TransportCredentialOnly is not supported for every binding (in this case we're using BasicHttp). For WSHttp, the only choice is going to be to use HTTPS. To switch off anonymous access with HTTPS, you need to set the security mode to Transport.

<wsHttpBinding>
  <binding>
    <security mode="Transport">
      <transport clientCredentialType="Windows" />
    </security>
  </binding>
</wsHttpBinding>

Other bindings can be made to work in this situation as well, including custom bindings. I'm just showing you the most common examples. The key in both cases though is that we're getting transport security with the right kind of credentials associated.

Next time: Writing Binding Element Essentials

I've created a custom implementation of GetProperty for my binding but now I'm getting errors when I go to use the channels. Why is the validation for these channels failing?

This is an implementation problem that I've talked about in the past. There is a requirement that the values queried from design time objects, such as bindings and binding elements, match the values queried from runtime objects, such as a channels. If the two don't agree on a property value, then you can experience problems ranging from an error creating the channel to mysterious failures sending and receiving messages.

This problem most commonly happens when you override an existing property value on the binding but forget to override the property in the same way on the channels. Use this picture illustrating GetProperty to follow the chain of property values.

However, this problem can also happen even when you're not overriding an existing value. If you write a GetProperty implementation but forget to delegate to the inner channel or binding element, then the chain of GetProperty calls terminates right there. Any further channels or binding elements do not get to contribute to GetProperty evaluations. This can easily cause a discrepancy between the design time and runtime values of a property despite the fact that you didn't explicitly modify that property. In most cases, this is a severe enough problem to fail very quickly. If you've written a GetProperty method and are suddenly seeing property value mismatches for properties that you didn't touch though, then make sure that your GetProperty method is delegating any unhandled properties to the right place.

Next time: Preventing Anonymous Access

Last time, we left off the channel construction process at the end of the design stage. During the design stage, everything is still in an unmolded and configurable state. At the end of the design stage, the construction process flips from a configuration mode to a runtime mode. The runtime stage has fixed all of the design settings and is in an operational state. Here were the products so far in the construction process starting from the service.

1. Service
2. Service endpoint
3. Service endpoint contract
4. Service endpoint transfer contract (binding)
5. Binding design settings
6. Realization of binding design settings (binding elements)

From the binding elements we can produce two objects called channel managers. A channel manager is something that can produce communication channels on demand. One type of channel manager is the channel factory. Channel factories create communication channels that initiate a connection or message send. The other type of channel manager is the channel listener. Channel listeners create communication channels in response to a message or connection attempt. Channel factories generally live in client applications and channel listeners generally live in service applications.

The channel manager is the first product in the construction process that performs network operations and can represent a network object. For example, channel managers may contact security servers in preparation for creating communication channels or allocate resources such as a TCP listener socket. The creation of communication channels is controlled by the user for channel factories and essentially controlled by the system for channel listeners. You have to initially start the channel listener but further action is taken in response to messages or connections arriving from other machines.

Communication channels are the conduits for sending and receiving messages. The final product of the construction process is one of these channels. For those of your following along, that means to produce a custom channel you will need to write the binding, the binding element, the channel managers, and the channel. All of these were included in the channel writing checklists (the binding was the only one on the optional checklist).

When we get to the next two articles in the tour series, the coverage will be on writing the binding element and channel managers.

Next time: Responding to GetProperty

Today's post seems to have gone missing from the posting system. I'll see if I can locate what happened to it and reinsert it back into the post queue for tomorrow. At some point I should probably invest in creating a more reliable auto-poster.

We're back to the channel development tour for another pair of articles. Today's article is the first of four in this segment on channel construction. The first half of the segment is background and the second half of the segment talks about code. In each half, there is an article on bindings and an article on channel managers. After we're done with this segment, everything else in the series deals directly with implementing the channel interfaces.

Channels go through a somewhat complicated construction process. This construction process essentially has three stages: design, evaluate, and build. Bindings are the typical user-accessible part of the construction process and correspond to the design stage. We have to take a few steps back before it becomes clear how bindings fit into the model.

1. You have a service.
2. Your service has endpoints that enforce a particular contract for exchanging data.
3. One part of your endpoint's contract is the protocol for how the client and server can send each other a message.
4. The implementation of a protocol contract is called a binding. There are many ways to build this implementation, including through configuration files or writing code.
5. Bindings expose design settings that allow the user to configure various aspects of the network protocols. The binding is a rough equivalent to the channel stack, a composition of all of the chosen protocols.
6. Given a specific set of design settings, the binding can produce a set of binding elements that correspond to those settings. Each binding element is a rough equivalent to one channel in the channel stack. We'll see some examples latter where that isn't true, but it's generally the case.

We'll stop here in the process for now because at the next step we'll be producing the channel managers that are the subject of tomorrow's article. The binding and binding element expose methods that allow us to perform the evaluate and build stages. The evaluate stage allows the user to query whether the chosen design settings of the binding make sense for building a channel manager. This is a cheap way of verifying the build process without having to actually initiate a build. The build stage locks the design settings of the binding in place and produces the corresponding channel manager. From the channel manager, the build process is going to continue a little bit farther until we have actual channels.

Next time: Channel Managers

When I run my non-HTTP service in IIS, I get an error message that the protocol is not supported. How do I add non-HTTP support to my VDir?

This is a two step process because the web site controls the list of available protocols while the application controls which of those protocols are enabled. You can change these settings either from the IIS control panel or from the command line. I'll demonstrate setting this up with the command line. This assumes that you've installed the IIS scripting tools and have started an elevated command prompt.

The first step is to create a web site that has the protocol in its list. I'll be using net.msmq in this example. If you've already got a web site, then you'll be using set instead of add and change the command accordingly.

appcmd add site /name:"My Site" /physicalPath:"c:\mysite" /bindings:http/*:80:,net.msmq/*

The second step is to create an application that has the protocol enabled. Again, if you've already got an application, then you'll be using set instead of add.

appcmd add app /site.name:"My Site" /path:/myapp /physicalPath:"c:\mysite\myapp" /enabledProtocols:http,net.msmq

Next time: Channel Bindings

Are you someone that's interested in using Service Broker together with WCF? If so, would you like to answer a few questions? I went surveying for SSB users at a Microsoft MVP event last night, but now is your chance to participate as well. I got to talk to five or six casual and not-so-casual SSB users, including SSB champion enthusiast Harry Pierson (second place: Jesus Rodriguez). Here are some points that I picked out where I'd like some more data.

1. Are you interested in SSB because you'd like to have your service closer to the database? How close is close enough to the database?
2. Are you interested in SSB because you need durable, duplex messaging between two services? Do you need exactly-once-in-order message delivery?
3. Are you interested in using SSB from WCF because you want a better asynchronous messaging experience than MSMQ? What makes you prefer SSB to other queuing products?
4. Are you interested in having your data contracts defined in WCF, SQL, or both?

How does my service know the identity of one of the connecting clients?

I'm going to focus this answer on obtaining a Windows identity since it's easier to write if I've just picked a single kind of identity. You can use whatever identity mechanism you want and the same technique will work. The only difference is that Windows identities get their own specially named property. A Windows identity is available on the service at least when Windows based message security has been enabled on the binding. I picked Windows identities because that's typically what is enabled by default. The WSHttp and NetTcp bindings have Windows security on by default. Other bindings, or custom bindings using an appropriate binding element, can enable Windows security if available.

If you are familiar with .NET security programming, then you may have first started by trying to use Thread.CurrentPrincipal to get the identity. CurrentPrincipal sometimes works (it requires enabling some specific settings) but there's a different standard mechanism for obtaining the calling client identity in WCF that is more expressive. The ServiceSecurityContext contains the Windows identity of the calling party when it is known in the obviously named WindowsIdentity property. The ServiceSecurityContext exists on both the client and server. The identity in this context always represents the remote identity. Like other contexts in WCF and CurrentPrincipal, the ServiceSecurityContext is bound to a thread, so you can access the relevant instance for this processing thread through ServiceSecurityContext.Current.

The ServiceSecurityContext has a wealth of other information that you can use. In addition to the remote identity, the most useful bit of information to make note of is the AuthorizationContext. The AuthorizationContext has the claim sets that WCF created for the current caller from the tokens in the message, an instance of the current IPrincipal in Properties["Principal"], and a list of all of the identities from the various security layers being used in Properties["Identities"].

Next time: Mapping to a VDir

Let's fill in some of the spaces around yesterday's checklist with a list of additional features for a custom channel. Nothing that's been added to this list is required to actually send or receive messages. By doing the things listed here, you can enable some additional scenarios and make your channel easier to use. However, if you're looking to write a channel as cheaply as possible, then these are the features that you might consider cutting. I'll summarize the previous list using italics and interlace the descriptions of the new checklist items.

1. Understand why you're writing a channel.
2. Identify whether the channel you need is a protocol channel or a transport channel.
3. Identify the channel shapes that your channel needs to be able to surface.
4. Write a binding element so that your channel can plug into the build process.
5. Add configuration support to your binding element. Configuration allows the settings of your binding element to be specified through XML files rather than through imperative code. You implement this configuration support by writing a binding element extension that duplicates the property settings of your binding element in a format that can be picked up by the configuration system. You will quickly grow tired of performing this duplication by hand and start thinking about how this process can be done automatically instead.
6. Write a standard binding that demonstrates the proper usage of your binding element. A standard binding represents the stacks of binding elements for your core scenarios along with the most commonly used configuration settings for those binding elements. Creating a standard binding allows people to frequently make use of your channel without having to write a custom binding of their own.
7. Support generating and consuming policy assertions that describe the capabilities of your binding element. Policy assertions allow you to advertise particular features of your channel so that the two sides can coordinate ahead of time about how the channel stack should be constructed. Policy support is implemented through a pair of interfaces for policy import extensions and policy export extensions.
8. Write a client channel factory that can produce instances of your channel for use by client applications.
9. Write a service channel listener that can produce instances of your channel for use by service applications.
10. Write channel instances to cover each of the supported channel shapes.
11. For transport channels, add a description of your supported addressing modes through WSDL extensions. Although addressing is most frequently handled by the message encoder, the transport is the one that is responsible for performing the advertisement. WSDL has a similar pair of interfaces to policy for creating import and export extensions.
12. For transport channels, write a protocol listener and listener adapter to make services using your channel activatable through WAS. The protocol listener for your channel sits on the machine waiting to accept messages on the behalf of activatable applications. The listener adapter for your channel plugs in to WAS and triggers the creation of processes in response to a message arriving for a service that isn't currently running.

Next time: Getting the Client Identity

This pair of articles marks the checkpoint between the "big picture" introductory segments and the segments where we actually start getting down into the code. The transition is going to be gradual so there's still some philosophy left, particular around the construction of bindings and binding elements. However, the objective of the articles is going to be less about how to think about the system and more about how to think about the code.

Here, we get into a checklist of the bare minimum necessary to write a channel. The first few items come from past topics, and you can use the rest as a roadmap of where we're going to go next.

1. Understand why you're writing a channel. Forever more in this series, I'm assuming that you've looked at the other extensibility points and decided that writing a channel is the best way to solve your problem.
2. Identify whether the channel you need is a protocol channel or a transport channel.
3. Identify the channel shapes, one or more, that your channel needs to be able to surface.
4. Write a binding element so that your channel can plug into the build process. The binding element is going to take one of the supported channel shapes and return the factory object that produces channels. Writing a binding is not required as you can always use your binding element in a custom binding. The binding element is also going to hold all of the configurable settings for your channel.
5. Write a client channel factory that can produce instances of your channel for use by client applications. If you have an integration scenario where you're only writing channels for use in a web service, then you can skip this step. For example, if the client is going to be a web browser that doesn't use WCF, then you might not ever have a need to create client channels.
6. Write a service channel listener that can produce instances of your channel for use by service applications. If you have an integration scenario where you're only writing channels for use in a client, then you can skip this step. For example, if you are trying to communicate with an existing mainframe service, then you're only going to produce channels to bridge the connection between WCF and the other system.
7. Write channel instances to cover each of the supported channel shapes. I think it's easier to have separate classes for each channel shape that all use a central communication library. However, you may find it easier to implement multiple channel shapes in a single class.

I've put the channel writing steps in a particular order, although some people prefer to go in the opposite direction. It doesn't really matter in structuring the code whether you write the classes from binding element to channel or from channel to binding element. I find that everything but the actual communication is so simple, that it's better to have all the pieces in place so that you can test sending and receiving in a real application.

Tomorrow, we'll look beyond the bare minimum to get a sense of the bells and whistles you can add.

Next time: Channel Writing Checklist (Optional)

What is the content type of the message returned by a service?

The idea of a content MIME type is very popular in HTTP programming, both for communicating the format of the data and the text encoding inside that format. However, content types are not generally used for SOAP processing. If you look at the SOAP specifications, you'll notice that there are fixed content types for describing the message. The message format is SOAP after all. SOAP messaging also generally has a limited choice for text encodings. The application message format inside the SOAP format is more likely what you care about. That information is transmitted out-of-band as part of the service metadata.

What this means is that there's no standard object model in WCF for accessing the content type of a message, even when you're not really doing SOAP programming. That's a legacy of being primarily designed for SOAP. There's not a promise here, but there is one spot where the content type can be optionally offered up when supported. If you take your message, one of the message properties is the message encoder. Stamping messages with the message encoder is optional, but if that has been done in the pipeline, then you can query the message encoder for its content type. Note that this isn't the same as the message content type. There's only one message encoder for many messages, so what you're seeing is the default content type for the message rather than the specific content type of the message that was received.

Next time: Channel Writing Checklist (Required)

I was looking through the archives the other day and found that the original article on channel shapes is actually still accurate despite having come out a year ago. It's interesting to step forward in time and watch as things become more and more like what actually was released. I've done similar walks through a longer history of the product, although you have to patiently track through whole concepts appearing and disappearing.

In celebration of this bit of history, I decided to let last year's article stand. I did have a new picture in the channel dev tour drawing style that I wanted to include though.

Update: I'm not sure when the count got off track, but this article turned out to be a day later than one year. Fortunately, now that the product is out, the things that I'm writing about are unlikely to change on a daily basis.

Next time: Extracting Content Types

We've been looking at the flow of messages (Part 1 and Part 2), but have never stopped along the way to look at the extensibility points where you can plug in your own code. Being a highly-extensible framework, WCF has piles and piles of these extensibility points. Some of the extensibility points are more likely than others to be confused with the proper use of channels. I'm just going to list out a sequence of points, not intended to be exhaustive, where you can execute custom code in the message flow. We'll go in chronological order from the client to the server to match the earlier articles.

1. Client code- Obviously, you have total control here over when service methods get called.
2. Generated client proxy- If your proxy object is generated ahead of time instead of dynamically, then you can extend the proxy to run code whenever a particular service method is invoked.
3. Message serializer- The message serializer sits below the proxy and converts CLR objects into an XML message.
4. Client message inspector- The client-side message inspector lives above the channel stack and is the first one to see the newly-generated XML message. You could alternatively have added a new channel to the top of the channel stack.
5. Client channel stack- The channel stack has all of the protocol and transport channels that were specified in your binding.
6. Network intermediaries- Once on the wire, anything can happen to the byte stream during transmission.
7. Service activation- Service activation is an optional layer that automatically controls the lifetime of service processes.
8. Service host- The host of the service actually has many extensibility points inside. You can replace the factory that is used to stamp out host instances or you can modify the behavior of the host itself.
9. Service channel stack- The service channel stack is the receive-side collection of protocol and transport channels.
10. Dispatch message inspector- A server-side message inspector lives above the service channel stack and functions similarly to its client-side equivalent.
11. Dispatch operation selector- Once we've gotten the message into a particular service, we need to figure out which one of the service operations is being called.
12. Message deserializer- Message deserialization reverses the serialization process by converting an XML message back into CLR objects.
13. Dispatch parameter inspector- Parameter inspection is the equivalent of a message inspector for the CLR objects that get produced during deserialization.
14. Dispatch operation invoker- We know which call to make and what information to give it. Now, we just need to make that call.
15. Service code- Again, you have total control over what happens inside the service method.

Next time: Channel Shapes

What does the trace message "The pool of the native MSMQ messages is full. This may affect performance." mean? Is this a problem?

I've seen some people on the WCF forums ask if this message is related to their MSMQ problems. It almost certainly is something that you can ignore. Let me explain what is happening here.

MSMQ messages are heavyweight objects compared to normal XML messages. The MSMQ transports maintain pools of these native MSMQ messages as an optimization. There are separate pools for input and output messages and one pool per sender or receiver. Each pool has a maximum size to control the amount of memory used for pooling messages. There is no functional problem when the pool is either empty or full. The message pools are just a cache. When you try to get a message from an empty pool, a new message is allocated on the spot. When you try to return a message to a full pool, the message is disposed rather than being put into the cache.

You should be able to tell what the trace message means now based on this description. However, there are some problems.

Pooling looks like it will work fine when receiving on a NetMsmq channel. Pooling also looks like it will work fine when receiving on an MsmqIntegration channel. There's no setting for the pool size on an MsmqIntegrationBindingElement, but there is a hard-coded value of 8 in the code. This is the same as the default size for the NetMsmq message pools. When sending on a NetMsmq channel, the pool full message is actually traced when the pool is empty rather than when the pool is full. As far as I can tell, sending on an MsmqIntegration channel doesn't bother with pooling at all and simply creates a message every time through.

Next time: Message Flow Interception Points

Continuing from last time, we were looking at the flow of a message during a service call. We left off at the point where the service client had just dropped a message off to the network. Today, we're going to follow that message up through the completion of the service call. This is essentially going through the process of a one-way call.

Right from the start, we hit a fork in the road. Either the service is running (because it's always-on or something has previously told it to turn on) or we need to start the service in response to the message arriving. Let's assume that we need to activate the service because everything afterwards is the same for the two paths. For each protocol that we want to activate on, the transport has a corresponding component that serves as the activation listener. The job of the activation listener is to listen for the first message destined for a service, start that service up, and then get out of the way. The details of activation aren't going to be used in this series, which is fortunate because it takes a long time to explain the process. Instead, we're going to jump ahead to the point where the service has come up. The activation listener does not actually process any messages. Once the service has been started, the first message goes to the transport just like any other message.

The message then passes through the transport and protocol channels, undoing any of the processing that was performed on the client side. At the bottom of the channel stack, the transport channel takes the stream of bytes used for network transmission and converts that stream back into an XML message. The message passes up through the stack of protocol channels, which again apply any number of transformations along the way.

At the top of the channel stack, we need something to reverse the process that the proxy performed to translate our method call into an XML message. This component is called the dispatcher because it needs to pull messages out of the pipeline and route each message to the appropriate service call. Back on the client side, the proxy took information about the service method being invoked and encoded that information into the message as addressing headers. The dispatcher looks at those addressing headers, finds the appropriate method to invoke, converts the payload of the message back into method parameters, and finally calls the method on the service instance.

We have a quick break coming up, but when this series next continues, we'll take a look at some of the extensibility points we passed through during the service call.

Next time: The Pool is Full

In the channel development series so far, we've just been looking at channels. I've already mentioned that you should consider using other extensibility points instead of channels when that's cost-effective. However, it has so far been left a mystery what those other extensibility points are. This series is not about documenting extensibility points other than channels. I will give a brief outline though just so you have some keywords to go off researching on your own.

For illustration, I'm going to demonstrate the basic pattern of messaging that takes place during a service call. Today's part of the illustration covers the client side of that messaging. We will end today with a message being put on the network. The next part of the illustration covers the server side of messaging. Even though most service calls are two-way, I'm only going to examine this single direction. I'll let you imagine the exact same process happening in the opposite direction. After we go through the message flow, I'll list off some of the extensibility points that the message passed along the way.

Here is the client side portion of the message flow. I have a single web service off running somewhere else in the world. The exact details of how we connect to that web service are unimportant. I have previously gotten a contract that describes some service operations and directions for contacting the service. Using this contract, I have designed a client application that wants to invoke some of the service operations.

I don't want to have to worry about messaging when invoking a web service operation. Method calls are easy to understand for someone that has any programming background. Networking is something that is much harder to understand. I would like for the message exchange between the client application and the web service to look like a method call. The proxy is a combination of dynamically-generated and framework code that gives service methods the illusion of being ordinary methods. We have taken the service contract and instantiated a type that has all of the service operations exposed as type members. Invoking one of the generated type members using a method call triggers the framework to send a message to the web service.

The remaining processing on the client side is to push out that message. The message will pass down through the stack of protocol channels, having any number of transformations applied to it. At the bottom of the channel stack, the transport channel takes the message and converts it for network transmission. Typically, this means running an encoding process to turn the message into a stream of bytes. The transport channel then sends the network transmission off to the network. If everything has gone well, the network transmission will be picked up by the web service and somehow turned back into a method call. That is the process that we'll look at next time.

Next time: Flow of Messages, Part 2

The latest CTP is available for the Visual Studio "Orcas" release. There are a lot of new features in this CTP across the .NET Framework, but I don't recommend that WCF developers make the jump quite yet. There are some issues with CLR generics and a few other changes that break WCF pretty annoyingly from what I've seen. You may want to wait for something more solid in the next beta release.