Implementing SOA Patterns: The Router

The Router Pattern is perhaps the simplistic of all SOA Patterns, with the exception of the Proxy Pattern. The Router Pattern is also the pattern that is most likely to be implemented in a network lke an application delivery controller (ADC). That shouldn't be surprising, given that one of the purposes of an ADC like BIG-IP is to route messages to a specific node/server based on a wide variety of variables.

The Router pattern essentially involves routing requests to specific business services based on defined criteria. It's conditional routing, and it usually requires the extraction of some piece of data from the message upon which routing can be based.

There are just three steps in the pattern:

1. Client sends request to the device acting as the router

2. The router extracts the appropriate input

3. The router directs the response to the appropriate service based on the value of the input extracted in step #2.

The iRule to implement the Router pattern is simple, requiring only that the appropriate data be extracted from the message before determining to which pool the request should be routed.

# iRule Router Pattern Rule

when HTTP_REQUEST {

   HTTP::collect [HTTP::header "Content-Length"]

}

when HTTP_REQUEST_DATA {

 # search for "searchstring" in the message. Replace skip-count and terminator

 # with the values appropriate for your data 

 switch [findstr [HTTP::payload] "searchstring" skip-count "terminator"] {

    "value1" {

        pool service1_pool

    }

    "value2" {

        pool service2_pool

     }

     "value3" {

        pool service3_pool

     }

  }

  HTTP::release

}

This pattern has long been used to route requests based on URI, the earliest form of content-based routing implemented (well before the Enterprise Service Bus entered the picture), and has been implemented in application delivery controllers for many years. It should be no surprise that for those ADCs that are application fluent, like BIG-IP, that the implementation of this particular SOA pattern is a snap. What might also be fairly obvious at this point is that the Federated ESB Pattern is based on the Router pattern, and that the BIG-IP and iRules can handle the implementation of that pattern with equal alacrity.

Stay tuned as we dig into other (and definitely more complex) SOA Patterns like Facade, Command Facade, Asynchronous Query, Data Logger, and Input/Output Validator.

Imbibing: Mountain Dew