MSDN Magazine - June 2008 - (Page 97)

MiChele leRoux BustAMAnte service station Building A WCF Router, Part 2 In the April 2008 installment of Service Station, I showed you how to create a simple router that allows messages to flow transparently between the calling client and the target service. In the process, I reviewed important Windows® Communication Foundation (WCF) addressing and message filtering semantics, you learned how to design a router contract to work with untyped messages, and you learned how to configure the bindings and behaviors to allow messages to pass through untouched by the router. In this issue I’ll continue the discussion by looking at further implementation details that arise when more practical scenarios for routers are employed. Regardless of the distribution model, a loadbalancing router certainly requires a few core features. Pass-Through Router Scenarios As I mentioned in Part 1, when a pass-through router is inserted between a client and a service, the client’s relationship is with the target service, not the router. Although certainly messages must be sent with a transport protocol and message encoder that the router can understand, the entire contents of the message—including security headers and reliable sessions, for example—are not processed by the router. A few examples where a pass-through router might apply are load balancing, content-based routing, or message transformation. Load balancing and distribution of work across server resources is best suited to Network Load Balancing (NLB) or, better yet, hardware load-balancing devices. Still, a WCF router can be useful for load balancing if services are hosted in environments without these luxuries, when services are installed to physical infrastructures out of your direct control, when you need routing based on domainspecific logic, or when the application simply calls for a lightweight routing solution that is simple to configure. Such a WCF router can be used to distribute messages to services hosted in multiple processes on the same machine or distributed across machines. Regardless of the distribution model, a load-balancing router certainly requires a few core features. Services must somehow register with the router in order to be included in load distribution. The router must be able to determine the service type and associated endpoint so that it can correctly forward messages. And the router must have an algorithm for distributing load such as a classic roundrobin approach or some form or priority-based routing. Sometimes distribution of messages among services is handled based on the content of the message, as opposed to load balancing. A content-based router will typically inspect either the message headers or the message body for routing information. For example, messages from clients with a valid license key may be forwarded as high priority to a large pool of server machines with more processing power, while those with a trial license are forwarded to a smaller pool of less powerful servers. In this scenario the router must not only know where to forward messages, but it must also be able to inspect each message, its headers or body content, before making the decision on where to forward. The following sections will discuss relevant routing features that support these scenarios. Forwarding by Action Header Messages received at the router have two addressing headers that can be useful in forwarding messages to the correct service: To This header indicates the name of the endpoint. If the header matches the target service and not the router, it will indicate a URL for the service endpoint that the message was intended for. Action This header indicates the service operation that the message was intended for, but it may not represent a valid URL per se. In many cases, however, the To header will match the router address and not the service, leaving the Action header as the more reliable source of information as to the correct destination for the message. Recall that the Action header is derived from the service contract namespace, the service contract name, and the operation name. This is sufficient information for a router to uniquely identify the target service, assuming that contracts are not shared across different service types. Consider the following service contracts, each implemented on different service types: [ServiceContract(Namespace = "http://www.thatindigogirl.com/samples/2008/01")] public interface IServiceA { [OperationContract] string SendMessage(string msg); Send your questions and comments to sstation@microsoft.com. Code download available at msdn2.microsoft.com/magazine/cc135911. June 2008 97 http://msdn2.microsoft.com/magazine/cc135911

Table of Contents Feed for the Digital Edition of MSDN Magazine - June 2008

MSDN Magazine - June 2008 Contents Toolbox CLR Inside Out Cutting Edge Patterns In Practice SAAS Concurrency Robotics Form Filler GUI Library Service Station Foundations Windows With C++ Concurrent Affairs Going Places { End Bracket }

MSDN Magazine - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.