Queue Topology Guidance

Question

I would like guidance/feedback/references on AQ queue topologies for integration of systems residing on a dozen or so discrete servers across 2 capital cities linked by a WAN.
Although most references I have seen to date seem to imply centralised database servers (and hence queues), I am uncomfortable with tight dependency and coupling via synchronous Net8 from application server to centralised hub. This forces the each of the application adaptors to have to code around unreachability of the remote central queuing hub - code which I would much rather not write and allow the middleware to handle.
My experience is with MQSeries where for application server connectivity (as opposed to PC clients), you most likely deploy MQM's on each application server platform. Unreachability of the local MQM is a fatal condition that would require immmediate restoration of the server, and hence not require an elegant coding solution. MQSeries is then responsible for the integrity of communications between servers and across networks.
I am wrong in advising a distributed queue topology where each application adaptor talks to a local AQ queue (no unreachability coding), and allow AQ to manage reliable propagation across networks to hubs or other servers?
Any feedback would be very much appreciated.

Answer 1

Hi Darryl,
If you have two databases in the two cities, you can create queues in the two Oracle databases and use propagation feature to propagate messages between queues in the two databases. The propagation is tunable and is adaptable to network failure.
You would have single database across WAN if you have a fairly good network connectivity. The applications typically would connect to the central database and can communicate asynchronously via queues.
Both these solutions are good solutions.
cheers,
Brajesh.