Partilhar via


App Paritioning: Data Dependent Routing using Redirection

Following up on my previous post regarding how to talk to partitioned services with data dependent routing, here is another mechanism -- redirection. One of the main drawbacks of having the routing service forward messages to the final target service was that you need to delegate trust to the routing service. The target cannot authenticate the initiators directly and so you lose out on the built-in security model.

The other major drawback is if the system is under sufficient load, the routing service could become a bottleneck since all conversations are routed through it and each message in the system must pass through this service.

Using redirection instead of forwarding solves both these problems. I have uploaded a sample to the CodeGallery to show how to build a routing service that redirects inbound conversations, rather than forwarding incoming messages.

The above diagram illustrates how the redirecting routing service works. The initiator S1 begins a dialog and sends a message to the routing service. The routing service receives the message (1) and applies the classifier function to obtain the service name and broker instance of the service where this conversation must be redirected to (2). It replies on the same conversation D1 with a redirect message containing the service name and broker instance found (3) and ends the dialog on its end. When the initiator S1 receives the reply, it will end the dialog and begin a new dialog D2 targetting the service name, broker instance specified by the redirect message (4). Finally it will resend the original message to the final destination S2.

It is obvious that since S1 is directly talking to S2, S2 can authenticate S1 and apply the right level of access control. Also once the conversation has been bound to final destination, all subsequent messages will be sent directly, thus freeing the routing service from processing them.

The only limitations of this approach are that the initiators must have routes to the targets and vice versa. Also the contracts need to be extended to include the special 'Redirect' message type and the services should be able to handle them appropriately.

Comments