With WCF the service consumer sends a message to the
service using a generated proxy. Both the service consumer and service
rely on a compatible configuration that is shared between them.
Decoupling services
from service consumers has several benefits, including the ability to
independently leverage non-functional features, such as message-logging,
security logic, fault tolerance, and various forms of routing
processing.
Although building a router service was possible with .NET 3.5, version 4.0 of the .NET framework provides the WCF Router,
an intermediary that can be configured as a service or service agent to
receive and forward messages to target services based on various
factors.
The
WCF Router can be configured as an active or passive intermediary. An
active WCF routing service can provide a range of runtime processing,
such as security, message encoding, reliable sessions, and protocol
compatibility. As a passive intermediary (meaning the router logic can
alter policies and protocols, but not message structure or content), it
can perform various forms of runtime routing logic, such as
content-based routing, rules-based routing, and load-balancing.
The RoutingService Class
The WCF Router is
equipped with a built-in filtering mechanism that allows you to specify
the criteria used to dynamically determine message paths. For example, a
message may need to be routed based on action, an XPath query, or its
actual content.
WCF provides the System.ServiceModel.RoutingService
class, and as with any other WCF service, the routing service can be
hosted in IIS/WAS or it can be self-hosted in a Windows application or a
Windows service.
The following example shows the contents of a .svc file with directives for hosting RoutingService in IIS:
Example 1.
<%
@ServiceHost
Service="System.ServiceModel.Routing.RoutingService,
System.ServiceModel.Routing,
version=4.0.0.0,
Culture=neutral,
PublicKeyToken=31bf3856ad364e35"
%>
|
This next example shows RoutingService in a self-hosted environment:
Example 2.
using (ServiceHost serviceHost =
new ServiceHost(typeof(RoutingService)))
{
try
{
serviceHost.Open();
Console.WriteLine
("Routing service running. Press <Enter> to exit");
Console.ReadLine();
serviceHost.Close();
}
catch(CommunicationException)
{
serviceHost.Abort();
}
}
|
Routing Contracts
The RoutingService
class supports the routing of messages that are part of synchronous
(request-response) data exchanges as well as asynchronous and
request-response exchanges over duplex protocols. The router can also
multicast these two message exchange types.
The generic routing contracts available in the System.ServiceModel.Routing namespace to configure the router are listed in Table 1.
Table 1. Interface routing contracts used for different routing options.
| Routing Contract | Supports |
|---|
| IRequestReplyRouter | WCF Sessions: if present
Transactions: if present
Asynchronous Messages: no
Multicast: no |
| ISimplexDatagramRouter | WCF Sessions: if present
Transactions: no
Asynchronous Messages: yes
Multicast: yes |
| ISimplexSessionRouter | WCF Sessions: required
Transactions: no
Asynchronous Messages: yes
Multicast: yes |
| IDuplexSessionRouter | WCF Sessions: required
Transactions: if present
Asynchronous Messages: yes
Multicast: yes |
Each
of these routing contracts supports a different set of message exchange
patterns and channel properties. Consequently, you may have to set up
different routing endpoints for a service contract if your contract’s
operations are designed with different message exchange or transaction
requirements.
Note
The RoutingService class supports the numerous SOAP-based WCF bindings (BasicHttpBinding, WSHttpBinding, NetTcpBinding, etc.); however, it does not support the WebHttpBinding for REST services. Routing logic for REST services can be implemented with IIS Modules for Application Request Routing and UrlRewrite.
