We do something like this. Just like you, we wanted to have a single URL for a global service, and relieve the end user of the need to know the details of our solution, in particular, the URLs of the different SAs. I'm not entirely happy with our solution, but it does work.
You don't want to do round-robin DNS. You need to ensure that the resolution of the DNS name of the SA does not change during a user's session. Some global load-balancers (like F5's GTMs) allow you to do something called Geo-IP, which resolves a name based on the deduced location of the DNS server which queries the GTM to resolve a name. Something like this could work, but it of course costs money unless your enterprise already runs GTMs (or something like them).
We do something a little different. We run an external web site which takes information about the end-user from an internal directory and then redirects the user to the URL of the "optimal" SA globally (we have SAs in 9 locations - 2 in the Americas, 2 in Europe, and 5 in ASPAC). We make decisions based on the location of the user's mail server, which is in the directory. We assume that the user should connect to the SA "closest" (in network terms) to the user's mailbox. Alternatively, the user can override this logic and specify the destination to which they want to be redirected. We actually use SA's for this function, but you don't need to, and I would like to get rid of them in that function.
If I had it to do again, I would do something like this -
- Build an internal web site with all the logic.
- Use the "authorization only" capability of the SA to give user direct access to the internal web site without authentication.
I could see expanding the logic of this to monitor the loads on our SAs and do some rudimentary load-balancing among destinations, and also implement failover on server outage.
Ken
