Forum Stats

  • 3,816,517 Users
  • 2,259,199 Discussions


AQ: What is Best Practice ?

3004 Member Posts: 204,171 Green Ribbon
I have a pilot project about to trial messaging to achieve application integration.

We are going with AQ to pilot the message layer and use JMS for the API.

What is the recommended way to architect AQ given we have multiple databases, across a number of machines (Solaris and NT), separated by WAN links, all at different DB levels (7.3.4, 8.1.7).

Ie: should AQ be implemented in a separate DB as a HUB or does AQ need to be implemented in each DB? For performance, does their need to be a HUB at the end of each WAN link?

To minimise impact on applications should we choose to change the messaging layer in the future to say MQ series, does there need to be a layer of abstraction (Message Handler layer) to deal with vendor specific implementations?. Ie: are there vendor specific things that necessitate this?

Any comments would be appreciated.



  • 3004
    3004 Member Posts: 204,171 Green Ribbon
    Hi Mal,

    Both the approaches, you have suggested would work.

    You can create AQ queues in the local database (same as that of application) and then multiple applications on the same database can communicate using the queue in that database and if the applications are on different databases then you can use automatic propagation functionality to propagate the message to the appropriate database.

    In the second approach, you can create a single Oracle database, as a hub. You can perform all the database and messaging operations from the hub. If you want to perform database operations on other databases and messaging operations on the hub in a single transaction, you would have to use dblink.

    As you can see, both the approaches has their advantages. In the first approach, you don't have to deal with dblinks for the database operations. This would be the prefered approach if your application has to do both database operations and messaging operations. And more than one application that needs coordination resides on the same database. In the second approach, all your queues are in a single database. All the messaging operations are done at the messaging hub. This would be the prefered approach if you want to centralize your messaging operations at one place.

This discussion has been closed.