Yes mazen, deploy an Exchange server in each location. use the routing group
topology
Check this:
http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3TransnRouting/5
4165310-f98c-4757-b5ca-1f0ea35d2252.mspx?mfr=true
and this:
http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3TechRef/1b43ddb
f-e140-4b51-ac8b-d1a3ce0bd7bc.mspx?mfr=true

No, you could still have instances where the user would have to communicate
across the WAN to access data.  For example, public folder data would have
to traverse the WAN at some point (whether to replicate or to be accessed -
decision is which is going to be more).  If you share mailbox folders,
you'll have to access that mailbox regardless of where it lives (which
site).

I think your management misunderstands how Exchange works on the wire. It is
FAR better with respect to the network to follow Andrew's topology
suggestions vs. decentralizing Exchange.  In addition to the network traffic
for mail, you also have to traverse the WAN for authentication/directory
usage. If you instead use the cached mode and possibly use RPC/HTTP you
don't ever have to use the WAN if you have internet connections from each
site and you can contain your Exchange server in the same site, provide
better backup/recovery services and likely reduce the network bandwidth used
on the WAN.

It's a tradeoff between user traffic and replication, routing, Active
Directory, etc traffic, and the client accessing the servers for service.
There's some consideration to user perception of service in there, but that
comes later in this conversation I think.

Al

Another  point to consider in centralizing Exchange is mail will need to be
delivered to relevant servers at each site, there will be Public Folder and
AD replication.

If management is aware of the advantages and disadvantages of each approach
there's not much else to do.