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.
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.
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.