Oracle Advanced Queuing
Oracle Advanced Queuing
When I talk to people about all the advantages that Service Broker has because it is built into the database, I frequently get asked about Oracle Advanced Queuing (OAQ) which after all is built into Oracle. OAQ queues are database objects like Service Broker queues so they share the advantages of transactional messaging in the same database transaction as other database updates. Many of the differences between OAQ and Service Broker are a result of OAQ being an older feature that Service Broker so a lot more features have grown up around OAQ that Service Broker hasn’t gotten to yet. For example, OAQ does message transformation, message data based routing, and interfaces to other message systems that Service Broker doesn’t have yet. Service Broker put a lot more emphasis on being a great reliable, asynchronous application development platform so it has features like dialogs for reliable, ordered, persistent conversations, conversation group locking for improved support of multi-threaded queue readers, and activation for efficient application resource management.
While both OAQ and Service Broker are database features, Service Broker is more tightly integrated into the database. Most of the OAQ logic is implemented as stored procedures while the Service Broker logic was compiled into the SQL Server executable as DML and DDL commands. OAQ uses SqlNet for communications while Service Broker created a new communications channel optimized for reliable message delivery. This enables Service Broker to do things like end to end session based encryption and authentication of persistent sessions so a message that is forwarded through multiple intermediate hops is only encrypted and decrypted once. OAQ supports complex rules for activating internal or external logic to handle a message based on the message contents and headers but Service Broker’s activation is simpler and more efficient primarily because it doesn’t support the complexity that OAQ does. In general Service Broker can handle a large message volume more efficiently because it uses reliable messaging protocols integrated at a very low level in the database kernel.
Because of its ability to transform messages, interface with many messaging systems and do data dependant routing, OAQ is actually much closer to BizTalk in functionality than to Service Broker. Service Broker is a lightweight, simple efficient reliable message transport and asynchronous application platform which can handle large message volumes at the expense of not having some of the more complex features that make OAQ and BizTalk more feature rich but less efficient. It’s difficult to make apples to apples comparisons because they are aimed at different applications. It’s kind of like comparing a Ferrari with a Winnebago. If you need to get to work as fast as possible with a lot of style, a Ferrari is definitely the vehicle of choice but if you have to live in your vehicle for a month, the Ferrari would rapidly lose its charm and the Winnebago would look better every day.