Welcome back again! It has been a while since my last post. Last time I blogged about creating a locator service with WCF 4 discovery features. That article now resides here http://blogs.infosupport.com/author/chrisb/. It will be shown right below this article. In that post I described how to use WCF 4 discovery to create a locator service that other services will use to announce themselves and a client can use to discover a address and binding based on a given contract.
The only problem with that solution was that discovery doesn’t provide us with Binding information of a service. It will only provide us with an address and the xml qualified name of a contract. To get the binding information I used dynamic meta data resolving, but that meant that all the services that want to be discoverable also needed to provide meta data via http get.
In this article I wan to explore another feature of discovery: Extensions. The discovery mechanism allows us to add extra data from endpoints to the discovery information. You can do this via the EndPointDiscoveryBehavior. This is an endpoint behavior which you can apply in your config file like below:
The endpointDiscovery behavior defines an extensions tag. Within this tag you are free to apply whatever extra information you want! Pretty cool right? What would be even cooler? If we could add this extra information dynamically, via code. This can be done by defining a new behavior. We could define a service behavior that in code applies this EndPointDiscovery behavior and fills the extension collection of this discovery behavior with runtime information. What kind of information you might wonder? Well how about the binding information! We can use this to place the assembly qualified typename of the binding that an endpoint is using, we can then use this information on the client side to dynamically instantiate the correct binding! First let’s define a service behavior that will add this binding information to the EndpointDiscoveryBehavior’s extensions collection. The code:
The interesting part begins on line 8. Here we iterate over all the endpoints in the service this behavior is applied to. We instantiate a new EndPointDiscoveryBehavior and we add a new XElement to its extensions collection. This XElement represent the custom information we saw earlier in our config file, this is the way to fill this information in code. This is all there is to it! to use this behavior we must apply it to a discoverable service. Like our Calculator service, and our Locator service, both will be discoverable, the Calculator via announcements, the Locator service via UDP.
Here is the Calculator Service code:
Now we have the extra binding information exposed via discovery, so we don’t need meta data exchange anymore, here is the updated web.config file without meta data exposure!
Here we can see two endpoints. And we can see that this service announces itself to an endpoint. That endpoint is an endpoint on our locator service. When the locator service receives an announcement, it will store the data that comes with it. This data now included our extra binding information that we added in our extensions!
The locator service now returns two types of info when queried for an contract. It will send back the address of a service that implements that contract, and it will send back the assembly qualified typestring of the binding that that service is using. Here is the code of the locator service:
The cool stuff begins on line 27. Here the service will retrieve its stored announcements information by using the contract name of a service. From this info he will get the address and the binding typestring, it will then wrap this in a response and send it back to the client.
As in my earlier post, the client is still a dll, this dll will pack a class that will handle the queries to the locator service for us. All a client application needs to do, is to reference our dll and use the DynamicChannelFactory class to create a runtime proxy, all the client application needs to pass is a generic type parameter for the contract type. Our dll will discover the locator service, query it for the information it needs, and then use the WCF ChannelFactory class to instantiate a proxy. To the ChannelFactory class it will pass the binding, and the address. Here is the code of the DynamicChannelFactory class.
Line 66 is first up. This method will create a locator proxy for us so that we can ask it for service addresses and bindings. The factory will create a locator proxy as soon as it is initialized. it will try to discover the locator service by using udp. Because we also annotated our locator service with our cool new extension attribute, a response by the locator service will also include our XElement with binding information. This information is used to instantiate a proxy that was earlier generated with svcUtil. No ChannelFactory here.
Later on the GetDiscoData of our DynamicChannelfactory will use the locator proxy to query for service data, You can see this method from line 19. It will try to query, if it fails it will try to generate a new locator proxy and then query again. This method returns a tuple of an adress and a binding. The CreateChannel method is the method that a client should call to dynamically generate a proxy, this will use the WCF ChannelFactory to generate a proxy, by first querying our Locator service for address and binding data.
That’s it! Pretty cool stuff! Now we only need to know contracts and the rest will be searched for by runtime! Ideal for mocking etc. By using the extension mechanism of Discovery we have now one less method call for every query, and the services don’t have to expose metadata anymore!