Routing

Also known as message routing or content-based routing. A VERY interesting class of problems applicable to rule engines, having become increasingly popular within the current trend of SOA (service-oriented architectures). I describe it completely SOA-neutral here...

The Problem

A typical (commercial) problem: You have many different instances of a typical business service available. Those instances are specialized in some areas - they can either handle some kind of requests better than others or they cannot handle some requests altogether...

Figure showing the routing problem

Ok - some examples will clarify this range of problem:

  • Clearing insurance claims: An insurance company let their employees handle claims. The company is organized in service centers around the country. One of those centers is specialized in car accidents, another in household accidents, a third in medical issues. Every new claim enters its processing through a central dispatching mechanism - which has to route the claim to the service center best suited for this specific request.
  • Content-based-Routing: In a distributed application messages from a sender have to be routed to one or many potential receivers, depending on message content. Some messages arrive with encrypted parameters, they have to be routed to an decryption facility before the actual processing can start. Others arrive compressed, which have to be uncompressed prior to anything else.
  • Telephone-Call-Center: Phone calls arriving at a call center have to distributed to actual (human) call agents. Those lads can be specialized in treating special kinds of calls. It can be useful to re-route calls if a certain agent is currently overloaded or not available. Calls from priority-customers should be routed to a different species of agents.

The following table summarizes these examples with the appropriate requests and the conditions under which these are routed to their proper receivers.

Request Condition determining "route"
Insurance Claim kind of claim, persons involved, expected magnitude of claim
Messaging System next required processing step, current load of processors or services
Call Center Agent type of customer, type of request, current load/schedule of agents

A broad range of problems, and you'll surely be able to think of a few more...

Why is routing difficult?

You may wonder what's so difficult about routing? Sure, a few pretty simple cases exist - for example if the receiver is directly encoded into the request, as depicted below. The requests contain their receiving address:

Figure showing a trivial routing problem

One could easily code that into a few lines But reality proves to be more inventive than this trivial situation... have another look: Now the requests contain contradicting information - plus: Some receivers are overloaded or offline...

Figure showing a complex routing problem

In addition, corporations tend to change their specific routing rules often. By often I mean "with high frequency" - so nobody in her right mind would hardcode routing rules in a (compiled) programming language. Again, rule-based systems to the rescue.

The Solution

Let us start with a very simple scenario again: Handling technical support requests at a typical Internet-service provider (ISP).

  • Premium customers receive 7*24h support by the incident-response-team.
  • Questions concerning E-Mail are answered by the external partner "no-idea".
  • Issues with ftp are are too complex, they are not answered at all.
  • The first two times any customer wants to quit, those request are deleted. The third request is scheduled for processing in 21 days.