Composite Services Guidance: External Routing Configuration sample

  • Article

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="https://localhost/ServiceComposition.Inventory.Metadata/InventoryMetadataService.svc/mex?url=https://ClientService1OfficialURI&amp;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="https://ClientService2OfficialURI"
  partitionName="routerclients"
  explicitDataServiceAddress="https://localhost/ServiceComposition.Inventory.Metadata/InventoryDataService.svc">
</routingEndpoint>
<routingEndpoint name="WSDualHttpBinding_IService" kind="inventoryEndpoint"
  contract="Contracts.IService1" inventoryAddress="https://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.