Routing Architecture

Microsoft Exchange Routing uses a server-side, hub-and-spoke architecture. A Microsoft Exchange Public Folder (or a mailbox) acts as the hub, and the spokes are e-mail messages sent between each recipient and the hub folder. Logically, a route could be designed to move an item from user A to B to C, but each of these steps must go through the central hub in order for the state to be tracked centrally and for errors to be handled.

The following illustration shows the logical view of a simple route on the left. On the right, you see the actual movement of messages.

From an implementation perspective, Microsoft Exchange Routing can be seen as a state-driven scripting agent that uses four components:

• A routing engine, which manages the state and state transitions of the route
• A routing map, or state diagram, which describes the process logic to be used in the route
• A set of objects to assist in manipulation of the map and other items
• Scripts that describe the set of functions to be used in execution of the route

The routing engine has been implemented as a custom agent that runs under the control of the Microsoft Exchange Event Service. It is configured on a per-folder basis and responds to all the events generated by the Event Service on that folder.