Author : Sara Stanford
A Competent Architecture by Microsoft
SQL Server Service Broker – A Competent Architecture by Microsoft
SQL Server Service Broker – A Competent Architecture by Microsoft Introduced with Microsoft SQL Server 2005, SQL Server Service Broker (SSBS) is a popular framework which lets you write queuing / message based applications in the database itself. It gives native support for such applications in the engine and makes life easy for the developers in creation of dependable applications which are utilizing the database engine components to talk within separate databases, without much of complicated communication. It is possible for internal as well as external processes to send and receive seamless messaging with the use of TSQL extensions. Because Service Broker handles the communication paths, in context of a transaction, the development and testing effort reduces to a great extent, leading to increase in performance and assured reliability. The applications that are supported by this architecture are bound to be trustworthy, scalable and decoupled. Because the queuing and messaging frameworks integrate within the database, it provides many benefits to the developers as compared to those which happen outside the database.
Working Methodology of Service Broker
There is an innovatively developed protocol namely Dialog, that looks for two way communication between the two end points. The main function of this protocol is to specify the logical steps that are necessary for an accurate conversation and to ensure that all the messages are in the same order in which they were sent. The above process explains how this Dialog protocol acts as a centre in the entire Service Broker platform.
Key Highlights of SQL Server Service Broker
Since it is a part of the database, it proves to be effective than other queuing operations, giving better performance, efficiency and swifter transaction processing.
Because of the Service Broker queues getting maintained in the database itself, the backup facility and process is very much streamlined ensuring security and faster recovery, whenever needed.
There is optimization in performance since it straight away writes the messages to the receiver queue in case the databases lie on a similar server.
It allows you to define number of simultaneous queue readers and thereby, ensure parallel processing. Developers can process messages of their own group.
In case of restoration after failures, there are fewer risks of the logic and data getting out of sync because they both lie in the same database.
There is support for loosely coupled applications which are made up of many programs sending and receiving messages independently.
It defines a conversation – a communication channel by SSBS, of which a message is a part. Both of them have defined types which assist the developers write sturdy applications.