Service station: Build WCF router, part 1th

Hosting and using the Windows®communication Foundation (WCF) service typically goes through several basic steps: Implementing a service, configuring an endpoint that can access a service, hosting a service, generating a Web Service Description Language (WSDL) file, or enabling metadata exchange so that clients can Enough to generate the proxy to invoke the service, write code to instantiate the proxy with its related configuration, and initiate the Invoke service operation. You don't need to study the internals of it, but even in the simplest cases, the client and service channels rely on a compatible configuration to handle addressing semantics and message filtering to ensure that the correct action is invoked.

In some cases, the introduction of mediation services or router services between client and target services is useful for receiving messages that are transmitted between them or performing other activities such as logging, priority routing, online/offline routing, load balancing, and introducing secure boundaries. When such mediation services are introduced, some addressing and message filtering behavior needs to be adjusted accordingly.

So, let's take a closer look at how to use mediation services, and for simplicity, I'll collectively refer to them as routers. In this installment, I'll cover the concepts of WCF addressing and message filtering, and focus on router scenarios, and I'll also cover some options for routing configuration and settings. In part 2nd of this series, I'll show you how to use this rationale to achieve more advanced, more practical routing capabilities.

Default addressing Semantics

In the June 2007 "service Station" column (msdn.microsoft.com/msdnmag/issues/07/06/servicestation), Aaron Skonnard describes how WCF handles logical and physical endpoint addressing, Addressing headers and message filtering. In this section, I'll review some of the basic addressing features and how they affect routing scenarios-but you'll also find that Aaron's column is useful for understanding the other deep details of these WCF features.

Typically, the client uses a proxy generated from the service description to send the message directly to the target service. To make the client compatible with the service, they share equivalent conventions and endpoint configurations. Looking at the service contract and configuration shown in Figure 1, you can derive several important service addressing requirements.

Figure 1 service engagements and endpoint configuration

Service Contract
[ServiceContract (Namespace =
"http://www.thatindigogirl.com/samples/2008/01")]
Public interface Imessagemanagerservice
{
[OperationContract]
string SendMessage (String msg);
[OperationContract]
void Sendonewaymessage (String msg);
Endpoint Configuration
<system.serviceModel>
<services>
<service name= "　　　　Messagemanager.messagemanagerservice "
behaviorconfiguration=" ServiceBehavior ">
<endpoint
address= "Http://localhost:8000/MessageManagerService"
contract= "Messagemanager.imessagemanagerservice"
binding= "BasicHttpBinding"/>
</service>
</services>
</ System.servicemodel>