Programming WCF Services, 3rd Edition

More on Behavior Configuration

The service metadata behavior demonstrated in the previous section is just one of many such ready-to-use behaviors, and you will see many examples in the subsequent chapters. You can configure behaviors at the service level (as with the metadata behavior) or at the endpoint level:

<services>
   <service name = "MyService" behaviorConfiguration = "MyServiceBehavior">
      <endpoint behaviorConfiguration = "MyEndpointBehavior"
         ...
      />
   </service>
</services>
<behaviors>
   <endpointBehaviors>
      <behavior name = "MyEndpointBehavior">
         ...
      </behavior>
   </endpointBehaviors>
   <serviceBehaviors>
      <behavior name = "MyServiceBehavior">
         ...
      </behavior>
   </serviceBehaviors>
</behaviors>

Similar to default bindings, WCF allows for the notion of a default behavior. A default behavior is a nameless behavior (either a service or an endpoint level) that implicitly affects all services or endpoints that do not explicitly reference a behavior configuration. For example, consider the services MyService1, MyService2, and MyService3. To add the service metadata exchange on all services in the application, you can use this config file:

<services>
   <service name = "MyService1">
      ...
   </service>
   <service name = "MyService2">
      ...
   </service>
</services>
<behaviors>
   <serviceBehaviors>
      <behavior>
         <serviceMetadata/>
      </behavior>
   </serviceBehaviors>
</behaviors>

Along with this hosting code:

ServiceHost host1 = new ServiceHost(typeof(MyService1));
ServiceHost host2 = new ServiceHost(typeof(MyService2));

ServiceHost host3 = new ServiceHost(typeof(MyService3));
host3.AddServiceEndpoint(...);

host1.Open();
host2.Open();
host3.Open();

Note that the default behavior affects all services in the application that do not reference a behavior, even those (like MyService3) that do not rely at all on the config file.

You can have at most one default service behavior and one default endpoint behavior.

As with default bindings, the problem with the default behaviors is that a config file may get difficult for humans to parse and understand once you combine default behaviors with named behaviors, as shown in Figure 1-13.

Figure 1-13. Named and default behavior configuration

Because of this difficulty, coupled with the side effect of implicitly affecting even services that do not rely on the config file at all, I recommend exercising caution when utilizing a default behavior. Only use it when you want to affect all services in the application. Never mix and match them with named behaviors, since any service using a named behavior will be exempt from the default behavior. In the interest of readability, most if not all of the behaviors in this book are explicitly named, except in the rare cases in which a default behavior is required.