At one time I had two different principle servers. The problem with it was they could not talk to each other. What I did was make a separate database on a complete other system and I would copy the important data I needed to that. I was able to copy the transaction information to the independent database and use it to run reports for the total system. You could make separated principle servers in the different areas and then copy the data to an independent database. Of course, this creates the problem of synchronizing the user information and queue information across the servers. It may not be the solution for you, but it is an option.
Separating the databases also separates the ability to release jobs across print servers in addition to increasing the workload of having to merge the data from the separate servers. The system is technically functional as-is, but in order to eliminate some of the delay that is inherent in distant/global connections, I believe that capabilities that Jorge is asking for would need to be implemented. Technically speaking the delays would still be there, but they would be happening after the user's interaction with the Omega and devices when no one cares if it takes 5 seconds or 15 seconds to sync up to the system.
Apart from the obvious benefit of optimizing user interaction speeds, you would also have the benefit of the system being less likely to trigger into an offline state as the database itself would be less likely to lose connectivity since it would be on the LAN instead of the WAN. In essence, this would be a much more thorough and exhaustive implementation of the things that the proxy service is already doing as it has the ability to cache offline transactions and reconcile them to the server, it caches user credentials, and so forth. The tricky part is ensuring that the user account information is not sent to more than one location and used simultaneously in an effort to cheat the system. In the scenario just described, a user could potentially go into the negative as far as funds in the Pharos database are concerned; use of an external billing system such as BlackBoard or CBORD would offload the responsibility in that the billing system would be responsible for providing multiple access points for account balance queries and debit commands (or if a redundant system is not provided, then there is no need to worry about reconciliation as all billing would happen in real time).
Jorge and Steve,
Sorry for getting to the party late, some how I missed the original post. I have sent this off to the team for a more detailed response. Thanks for pinging me on this.