This chapter is from the book
This chapter is from the book
This chapter is from the book
Service Request Routing
The discussion thus far has talked about both messaging and mediation services as if each were a single monolithic entity. But in reality any physical component has finite capacity limitations, so the implementation of the mediation service may require more than one component to spread the load. The service user may not be at the same location as the service provider, so the mediation service must be present at each location. There may also be more demand than can be satisfied by a single service provider, so the mediation service must be capable of distributing service requests among multiple service providers. For all of these reasons, the mediation service must be considered a logical service whose implementation can involve more than one component.
Load Distribution
Perhaps the simplest routing task is simple load distribution (Figure 4-19). In this situation there are two or more service providers residing in the same location, and all of them are equivalent from a functional perspective. The routing problem is to determine which service provider should get each request. But even this can get complicated. What criteria do you use to select the service provider for the next request? Consider IP-redirectors, proxies that distribute incoming requests. Early redirectors used a round-robin approach, feeding each request to the next service provider in a sequence. Unfortunately, with this approach a "dead" service provider still gets its fair share of requests, which thus go unserved. More recent IP redirectors employ some form of liveness testing to avoid this kind of problem.
)
Figure 4-19 Routing Requests for Load Distribution
With the proxy-based approach, the proxy must make the decision as to which service provider should get each request. Making an assignment to an inoperable service provider runs the risk of the request going unserviced. Message-based mediation services avoid this problem. Message-based services hold the requests in a queue until a service provider retrieves them. Since the service provider takes the initiative in retrieving the request, the service provider must be operational to some extent. Dead service providers will not ask for more requests!
Location-Based Routing
Another routing challenge arises when you have service users and service providers residing at different locations. A request originating at one location may need to be routed to a service provider at a different location (Figure 4-20). While this could be handled with a single mediation service component serving both locations, the result generally leads to some very inefficient communication patterns. Service users and providers at the remote location that need to intercommunicate must do so via the remote mediation service. From a communications perspective, it is far more efficient to have a local component of the mediation service and then let the mediation service take care of routing requests to other locations as required.
)
Figure 4-20 Routed Service Requests
Content-Based Routing
A third routing challenge arises when there are multiple service providers of the same service at different locations. Now the mediation service must determine which provider should get which request (Figure 4-21).
)
Figure 4-21 Routed Requests Requiring Logic
This routing can get complicated because different situations may call for different routing strategies.
The simplest situation is again the one in which the service providers are all identical. While you could leave the requests in a single queue and let both service providers pull from the same queue, this does not necessarily make optimum use of the bandwidth between the two sites. You may want to implement a strategy that weights requests for local servicing as long as the local service provider has the capacity. Only when the demand exceeds the local capacity and the other site has idle capacity would requests be routed to the remote service provider.
Life gets more complicated when the service providers are not all equivalent. You have your North American customer data in one database; your European, Middle Eastern, and African customers in a second database; and your Asian and Pacific-Rim customers in a third. Each database is located in the region it serves. For uniformity, you want to provide a single generic interface at each location through which all customer information can be accessed, regardless of where it is located. In this case, the mediation service must determine which service provider (database) can handle each request.
What makes this type of routing, commonly referred to as content-based routing, complex is that there is rarely enough information in the incoming request to do the routing. Determining the appropriate routing generally requires some form of reference data. When you place a phone call, the country code, area code, and telephone exchange are the keys to routing the call to the correct telephone exchange. However, to do the actual routing you need information that relates each combination of codes to the actual telephone exchange to which the call must be directed. Furthermore, the service needs to know how to extract the relevant data from either the message itself or its destination name.
Content-based routing makes the design of the mediation service dependent upon certain application-specific characteristics. The mediation service needs to know how to extract the key information from the request. It needs to know how to access the reference data and perhaps cache it for efficient access. It needs to know the correspondence between the reference data and the service providers. And it needs to know the rules for deciding which service provider gets which request.
The bottom line is that content-based routing is a service. As such, it needs to be treated with the same rigor as any other service. In particular, the stability of the interfaces to this service is a key concern. There is a tendency to think of content-based routing as being loosely driven by rules—rules that can easily be changed. But if changes to the rules require additional input data or reference data, interfaces change and there is a lot more work to be done. Thus any proposal for content-based routing must be evaluated in terms of its ability to support future as well as current needs.