I've always been rather impressed with SQL Server Service Broker. It solves a lot of business problems. For distributed database applications, it is wonderful, and it is perfect for ensuring that databases degrade gracefully under pressure of usage. It has no peer for allowing you to create secure areas of a database, and for resilient interfaces. It is the obvious choice for batch processing. If you need complex logic to be executed on data entry, and use triggers, then the triggers can delegate work to a separate service to relieve the load on OLTP systems. It is also very handy for auditing database changes across instances.

Any database that can use parallel processes, and can delegate complex processing to other instances, in the confidence of not losing transactions, is going to be fast and resilient. In short, if Service Broker is so good, why aren't we all using it? Although it caused plenty of excitement when it was first introduced, but I've seen few databases use it in the context of an application.

One reason could be bewilderment. It is certainly daunting to enter the world of parallel processing and asynchronous programming if you are culturally more familiar with the 'musical box' simplicity of procedural programming. This shouldn't frighten the SQL Server developer, though, who inhabits a world that is inherently multi-process and multi-user.

An obvious problem is the lack of educational materials. There is, of course, a lot to learn before you can use Service Broker effectively, and it is easy to get confused by the difference between a DIALOG and a CONVERSATION (there aren't any), and such matters as the significance of endpoint lifetimes. Remus Rusanu suggests some good educational links here, and there are further useful links here. Another common complaint I've heard is the dearth of tools or methods for debugging and monitoring Service Broker.

Are lack of decent tools and education the main blockers? Should sites such as SQLServerCentral and Simple-Talk be providing more and better educational materials on Service Broker? My own view is that MSDN should provide more simple worked examples that show how easy it is to set up the Service Broker-based mechanisms. Is there anything else stopping you? Is there more that can be done to help promote the use of Service Broker?

Phil Factor.