Yesterday, I watched an MSDN webcast on the new Service Broker in SQL Server 2005. Sounds like an interesting feature which could possibly take some business away from Tibco for small to medium sized apps. Here is how Microsoft describes it:
With Service Broker, a feature in Microsoft SQL Server 2005, internal or external processes can send and receive guaranteed, asynchronous messages by using extensions to Transact-SQL Data Manipulation Language (DML). Messages can be sent to a queue in the same database as the sender, to another database in the same SQL Server instance, or to another SQL Server instance either on the same server or on a remote server.
Previously, in order to get notifications from SQL Server, you had to rely on something like SQL Notification Services. I am glad to see that async messaging has been promoted to a first class citizen within SQL Server.
Where can you use something like the Service Broker?
Assume that, in an organization, your Windows Smart Client app needs to be informed when certain reference data has changed in a legacy database. For example, let's say that your desktop app needs to be informed when PeopleSoft adds a new employee to the HR database. If the backend database is SQL Server 2005, then you can use the Service Broker to push async messages out to a message broker on the server. The server can then transform the message and broadcast it to interested clients.
This kind of architecture is ideal for applications that rely on server-push technology and smart caching on each client. With this kind of system, each client maintains its own cache of reference data and only gets notified of deltas to the reference data.