Composite Services Guidance: External Routing Configuration sample
Let me give you a little background on this sample. If you look at the WCF Routing Service, you can quickly and easily configure a router with endpoints and message filters in the web.config. This is a great way to set up context based routing. You can configure a message filter that identifies messages that call specific methods, have certain information in the header. You can then forward messages that match this filter to a specific endpoint.
The External Routing Configuration sample simply illustrates how to use the dynamic configuration features of the WCF Routing Service to read the routing filters and filter tables from an external source. The sample re-reads the routing filters and tables as well as endpoint data at specific time intervals. This allows administrators to update routing configuration externally and have these modifications reflected in the routing service the next time the data is re-read.
In order to run this sample you will need to run the Setup.cmd in the Samples\ExternalRoutingConfig folder. This batch file imports the service metadata into the repository as well as executes the RoutingConfigAssets.sql script which populates the repository with basic routing configuration. If you crack open RoutingConfigAssets.sql, you’ll see that a record is added to the Assets table with XML that configures one filter (MatchAll) and two endpoints. Notice that the first endpoint’s address uses the InventoryMetadataService. This is one way to pull service metadata out of the repository.
<routingEndpoint name="BasicHttpBinding_IService" address="http://localhost/ServiceComposition.Inventory.Metadata/InventoryMetadataService.svc/mex?url=http://ClientService1OfficialURI&partition=routerclients" contract="Contracts.IService1"> </routingEndpoint>
After you run ExternalRoutingConfig\Setup.cmd, run the Client command line app. You should see the following results:
Service1.GetData1 received: 111 Service1.GetData2 received: 222 Service1.GetData1 received: 333 Service1.GetData2 received: 444 Service1.GetData3 received: 555 Service1.GetData4 received: 666 Service1.GetData1 received: 777 Service1.GetData4 received: 888
Now, run ExternalRoutingConfig\UpdateRoutingConfig.cmd. This script executes the RoutingConfigAssetsUpdated.sql script which inserts a new routing configuration record into the Assets table. This new routing configuration is considerably more complex. Along with complex message filters, this new routing configuration uses the Inventory Endpoint pattern for the 2nd and 3rd endpoints. The 2nd endpoint uses an explicit address for the metadata service. The 3rd endpoint relies on discovery.
<routingEndpoint name="WSHttpBinding_IService" kind="inventoryEndpoint" contract="Contracts.IService1" inventoryAddress="http://ClientService2OfficialURI" partitionName="routerclients" explicitDataServiceAddress="http://localhost/ServiceComposition.Inventory.Metadata/InventoryDataService.svc"> </routingEndpoint> <routingEndpoint name="WSDualHttpBinding_IService" kind="inventoryEndpoint" contract="Contracts.IService1" inventoryAddress="http://ClientService3OfficialURI" partitionName="routerclients" discoveryScope="discovery:inventorydataservice"> </routingEndpoint>
Before you run the Client command line app again, reset IIS to force the router service to reload it’s configuration. Reloading is done periodically and is configurable. Below is the output of the Client app with the new routing configuration.
Service1.GetData1 received: 111 Service2.GetData2 received: 222 Service1.GetData1 received: 333 Service2.GetData2 received: 444 Service1.GetData3 received: 555 Service2.GetData4 received: 666 Service1.GetData1 received: 777 Service3.GetData4 received: 888
As you can see, some messages are routed to Service1, others to Service2 and the last message is routed to Service3.