SQL Server 2008 Message Forwarding

Message forwarding is another scale-out technology available inside Service Broker. Service Broker message forwarding allows an instance of SQL Server to accept messages from outside the instance and send those messages to a different SQL Server instance. You can use message forwarding for the following scenarios:

• Abstracting your network topology to other messaging applications

• Simplifying administration by creating a single centralized instance that holds the routing information for your domain

• Distributing work among several instances

When you enable message forwarding, the routing table in msdb.sys.routes determines whether a message that arrives from another instance is forwarded. If the address for the matching route is not LOCAL, SQL Server will forward the message to the address specified. Otherwise, the received message will be delivered locally.

Reliable Delivery
An instance that forwards a message doesn’t acknowledge the message to the sender. Only the final destination acknowledges the message. If the sender doesn’t receive an acknowledgment from the destination after a period of time, the sender will try to resend the message. An instance that performs message forwarding doesn’t need to store forwarded messages. Instead, SQL Server holds messages to be forwarded in the memory of the SQL Server instance. The amount of memory available for message forwarding is specified when message forwarding is configured. This strategy allows efficient, stateless message forwarding. In the event that an instance that performs message forwarding fails, no messages are lost. Each message is always maintained at the sender until the final destination acknowledges the sent message.

Service Broker message forwarding doesn’t require a forwarding instance to decrypt the forwarded message. Therefore, only the database that participates in the conversation must have dialog security configured. However, because transport security applies to the connections between SQL Server instances, each SQL Server instance must have transport security correctly configured for the instance that it communicates with. For example, if instance A and instance B communicate through a forwarding instance, then both instance A and instance B must have transport security configured correctly for the forwarding instance. Because the instances don’t exchange messages directly, the instances don’t have transport security configured to communicate with each other. Let’s take a look at the different scenarios where you can use message forwarding.

Network Topology Abstraction
Service Broker message forwarding allows you to abstract your network topology to other clients who call your Service Broker service. Let’s assume a scenario where you want to deploy OrderService into your production system, so that other clients can communicate with OrderService.

OrderService is deployed on the computer sql.csharp.at. If the administrator of ClientService wants to create a connection to OrderService, he has to create a route for OrderService that specifies tcp://sql.csharp.at:4741 as the target address. This approach will work without any problems. But what if the administrator of the OrderService must move the Service Broker to another machine, such as sql2008.csharp.at? In this case, the administrator of the locally deployed ClientService has to change the route to OrderService. Now imagine that several thousand clients are accessing the OrderService.

As you can see, it’s not always practical to reference a target service directly, because in this case, the address is directly associated with the client. Another more suitable approach would be for the administrator of OrderService to deploy a forwarding service. The forwarding service just routes the incoming requests from the clients of the OrderService, which you can deploy everywhere inside the corporate network. If the administrator has to move OrderService from sql.csharp.at to sql2008.csharp.at, he only has to change one route—the route that is configured at the forwarding service.

If you deploy this Service Broker scenario in your production system, all your clients will need to know is the address of the Service Broker forwarding service, forwarder.csharp.at. If you change something in your internal network topology, you just have to change the sys.routes catalog view from the forwarding services. None of your clients will have to do anything, because they’re just sending messages to the forwarding service, and they have no information about where the real Service Broker services are deployed. As you can see, message forwarding can help you to decouple your clients from your internal network topology and configuration.

Centralized Routing Instance
You can also use this scenario to implement a centralized routing instance. When you implement a centralized routing instance, all clients are sending messages to one Service Broker forwarding service. This forwarding service has all available routes to the different deployed target services. This centralized routing service can also implement things such as load balancing. It would be completely transparent to your clients whether or not one target service is load-balanced. The clients just know the address of the forwarding service, nothing more. It’s completely up to the administrator how the target services are deployed in the internal network.

Work Distribution
Another scenario where a Service Broker forwarding service provides a huge benefit is when you want to distribute the workload among several Service Broker instances. Think of a scenario where you have a hundred thousand concurrent users. (I know that this is a very rare scenario, but I want to show you that Service Broker also supports these scenarios.) If a hundred thousand concurrent users are trying to access a single target service, then the SQL Server instance hosting the target service can’t possibly accept all client connections because of the maximum available TCP socket connections. The underlying operating system can’t handle that number of users. However, you can spread out all the client connections to several forwarding services and have each forwarding service forward requests to a dedicated deployed target service. Which target service the incoming request is forwarded to is configured through the sys.routes catalog view.

Source of Information : Apress Pro SQL Server 2008 Service Broker


Subscribe to Developer Techno ?
Enter your email address:

Delivered by FeedBurner