Welcome to Windows Communication Foundation (WCF)
Top Tasks :

WCF Team Bloggers

Browse by Tags

All Tags » Behaviors   (RSS)

  • Setting the Configuration Name

    What's the difference between the Name and ConfigurationName on service contracts and behaviors? The Name property sets the name of the service in metadata while the ConfigurationName property sets the name of the service in configuration. Metadata is the part of the service description that is transmitted to others when they interrogate your service. Configuration is the purely local settings for controlling the service. Since Name is more commonly used, I'll just run through a quick example focusing on setting ConfigurationName instead. Here I've got a service contract and implementation setting both the Name and ConfigurationName properties. [ServiceContract(Name= "NotIService" , ConfigurationName= "IService" )] public interface IMyService { [OperationContract] void DoNothing(); } [ServiceBehavior(Name = "NotService" , ConfigurationName = "Service" )] public class MyService : IMyService { public void DoNothing() { } } In my app.config file, the way I'd refer to that service and service endpoint is by the ConfigurationName. < service name ="Service" > < endpoint address ="http://localhost:8000/" binding ="basicHttpBinding" bindingConfiguration ="myBindingConfiguration" contract ="IService" /> </ service > On the other hand, everywhere in the metadata, generated proxy, and even the generated proxy configuration file the service will appear as NotIService and NotService. Next time: Disabling the Visual Studio Service Host Read More...
  • Validation Behaviors for Client and Service

    The other day I talked about the built-in service validation behaviors but these behaviors are only a part of the overall validation story. Today I've got more of an end-to-end overview of behavior validation. Although validation is similar whether you're building a client or service (remember that client proxies have behaviors too ) I'll also point out where the differences take place. How a service performs behavior validation: Run built-in service behaviors Run user-defined service behaviors For each endpoint on the service: Run user-defined contract behaviors Run user-defined endpoint behaviors For each operation on the contract: Run user-defined operation behaviors How a client performs behavior validation: Run user-defined contract behaviors Run built-in endpoint behaviors (these are mostly the same as the built-in service behaviors but not all of the checks are performed for the client) Run user-defined endpoint behaviors For each operation on the contract: Run user-defined operation behaviors If more than one endpoint shares a contract, then the contract behaviors will run again and again while the operation behaviors will only run once. That's because an IContractBehavior operates on the contract and endpoint while an IOperationBehavior operates on the operation and contract. Next time: Single Reader for MSMQ Read More...
  • Built In ServiceHost Validation Behaviors

    Yesterday I talked about the validation done on bindings for partial trust. Partial trust validation gets run very early when the service host is opened using a service behavior. There are actually several of these service behaviors that run up front. Afterwards, Validate is called on each of your service behaviors to perform the user-extensible part of validation. Here is what those built in validation behaviors do: Partial trust validation is performed to check that all of the endpoints have bindings that are supported for partial trust . Contract name validation is performed to check that all of the contracts that are used across the service have different names if the contracts are different. Security validation is performed to check a very large number of security-related misconfigurations, such as whether contracts that have a defined protection level are being used with bindings that don't support that protection level . Transaction validation is performed to check a variety of transaction-related misconfigurations, such as whether transaction options are being configured when none of the operations require a transaction scope. Peer-to-peer contract validation is performed to check that endpoints that use a peer-to-peer binding are only used with one-way operations. MSMQ integration validation is performed to check that endpoints that use an MSMQ integration binding are only used with the limited set of message contracts supported by integration mode . Next time: Mystery of the Disappearing Addressing Headers Read More...
  • Using Call Context Initializers for Culture

    Let's build on a few earlier samples to actually demonstrate a working call context initializer. I'll start with yesterday's skeleton for a call context initializer and behavior . To that skeleton I'll add implementations of BeforeInvoke and AfterInvoke that initialize the operation thread with custom culture information and then clean the thread up once the operation return. class CultureInitializer : ICallContextInitializer { CultureInfo newInfo; public CultureInitializer(CultureInfo newInfo) { this .newInfo = newInfo; } public void AfterInvoke( object correlationState) { Thread.CurrentThread.CurrentCulture = correlationState as CultureInfo; } public object BeforeInvoke(InstanceContext instanceContext, IClientChannel channel, Message message) { CultureInfo oldInfo = Thread.CurrentThread.CurrentCulture; Thread.CurrentThread.CurrentCulture = newInfo; return oldInfo; } } Then, I'll fill out ApplyDispatchBehavior to apply my call context initializer to every operation on the given endpoint. class CultureInitializerBehavior : IEndpointBehavior { CultureInfo newInfo; public CultureInitializerBehavior(CultureInfo newInfo) { this .newInfo = newInfo; } public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters) { } public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime) { } public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher) { foreach (DispatchOperation operation in endpointDispatcher.DispatchRuntime.Operations) { operation.CallContextInitializers.Add( new CultureInitializer(newInfo)); } } public void Validate(ServiceEndpoint endpoint) { } } Finally, I'll take last week's custom fault encoding sample and install my behavior. Notice that the only change at the service level is to add the behavior to the endpoint behavior collection. If I had written the code to apply the behavior in an attribute or configuration file, either of those approaches would have worked as well. [ServiceContract] public interface IMyService { [OperationContract] Message Fail(); } public class MyService : IMyService { public Message Fail() { XmlDocument document = new XmlDocument(); document.LoadXml( "<tag attributeName=\"value\"><moretags>blah</moretags></tag>" ); throw new FaultException<XmlElement>(document.FirstChild as XmlElement); } } public class Program { static void Main( string [] args) { string address = "http://localhost:8000/" Read More...
  • Using Call Context Initializers for Cleanup

    I'm using framework features that have thread-local settings. These settings then get leaked to other client calls. How can I stop this from happening? The problem here is that WCF doesn't know about these thread-local setting changes that you've made and so doesn't know that they need to be cleaned up. WCF by default is more frugal than other stacks, such as ASP.NET, when it comes to protecting state. Saving and restoring lots of thread-local settings takes time regardless of whether you actually did something with those settings or not. WCF tries not to do as much on your behalf so that you don't have to pay for cleanup unless you're using those features. It does however give you the hooks necessary to arrange for this cleanup to take place at the appropriate time. The ICallContextInitializer interface lets you hook the beginning and end of operation calls. Hooking the end of the call allows you to cleanup these setting changes. It's easiest to insert an ICallContextInitializer by applying an endpoint behavior to your application endpoints. class MyInitializer : ICallContextInitializer { public void AfterInvoke( object correlationState) { // Clean up thread-local settings here } public object BeforeInvoke(InstanceContext instanceContext, IClientChannel channel, Message message) { return null ; } } class MyInitializerBehavior : IEndpointBehavior { public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters) { } public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime) { } public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher) { // Add instances of your call context initializer to the CallContextInitializers collection // of the appropriate operations located at endpointDispatcher.DispatchRuntime.Operations. } public void Validate(ServiceEndpoint endpoint) { } } Next time we'll look at a more complete example of using ICallContextInitializer to solve a problem with setting up thread-local settings as well. Next time: Using Call Context Initializers for Culture Read More...
  • Channel Factory Behaviors

    How do I attach a custom behavior to a dynamically generated proxy object? This one should be easy if you've read the past two articles about modifying a ChannelFactory after creation. Although behaviors can't be specified while creating the ChannelFactory, the ChannelFactory has a local endpoint object that can have behaviors attached. Changing the endpoint for behaviors works exactly the same as changing the endpoint for contracts. As with all modifications to endpoints though, you need to make all changes prior to calling Open (or the first call with proxies) or you'll find that the endpoint has become immutable. Next time: Reader Quotas with Untyped Messages Read More...

Copyright © 2006 Microsoft Corporation. All Rights Reserved. | Terms of Use | Privacy Statement | Contact Us