In a central topology, most or all major system components and messaging processes are located at one site. Clients at remote sites communicate over a Wide Area Network (WAN) to the centralized messaging servers. Figure 12–1 shows a central topology.
You should consider a central topology for your organization when:
Messaging at remote sites is not mission critical.
Users tend to send and receive small text messages.
Your organization is located in one physical location or distributed across many small user populations.
You do not have remote support personnel.
Good bandwidth exists between remote sites and the central site (at least ISDN or better).
There are advantages to implementing a central topology. In general, a central topology has lower hardware and support costs. Central topologies tend to be easier to manage because you have a simplified messaging architecture and a directory replication structure with fewer replication agreements. With a simplified architecture and no need to coordinate installation among geographically distant sites, a central topology is faster to deploy.
That said, there are an equal number of disadvantages to implementing a central topology. A centralized approach heavily relies on a WAN. If the network does not function properly, users at the same site as well as users in remote locations could not send email to one another. Depending on network bandwidth and traffic, services might be slower during peak usage times. For users who send messages within the same domain, a central topology is inefficient. For example, looking at Figure 12–1, a message sent from one user in the Tokyo site would first travel to the Central site before being sent to another user in the Tokyo site.