Planning for Service Broker Development
It is important to consider the metrics concerning the type and volume of input and output expected from your application before you begin the implementation of your Service Broker application. Careful review of these metrics and a thorough analysis of requirements for your proposed application allow you to develop a system that successfully meets your business goals.
Planning Checklist
Consider the following questions as you plan your application:
- What role does Service Broker play in your application?
The answer to this question helps you plan the message types your application uses, the structure of your application, and the storage and processing needs of your application.
For example, if your application is designed to shift away from peak processing periods the time at which messages are processed, the message types your application uses should closely match the input and output of the existing application. You can estimate storage and processing needs for your application based on the existing workload.
In contrast, if you design a new application, carefully consider which operations can benefit most from the Service Broker. Using Service Broker often trades off predictable processing times in the best case in return for reliability in cases where a conventional application would fail altogether.
For example, an online order entry application may not need to completely process the order and provide final confirmation at the time the order is submitted. Instead, the application may submit the order to a service that processes the order and provides final confirmation through e-mail. With this design, the order application can continue to accept orders even in cases where networking problems prevent the application from confirming the order. When the networking problems are resolved, the application processes the orders successfully. In this case, the storage and processing needs for the application depend on the number of orders expected, the size of each order message, and the amount of time each order requires to be processed. - What information will be required at each at each step in a conversation in order to complete the desired task? What are the schemas of the messages that the endpoints will exchange in order to provide this information to each other?
Consider the type of information that your services will exchange. Most services exchange semi-structured information, which makes XML encoding a good choice. A binary encoding, by contrast, is useful for exchanging binary files such as images. When the only information conveyed by a message is the fact that the message arrived, use an empty message.
Getting the message types right can prevent you from having to make updates to your application later. Depending on the message type encoding selected, updates can mean anything from having to update an XML schema file to having to make significant coding changes in your application. If there are data items that you don’t currently need but you anticipate needing in the future, it may make sense to include them. Missing elements don’t take up space in an XML document but having them defined in the schema means you won’t have to change you schema when you get around to supporting them - Where will your message processing logic run?
You can design your application as a stored procedure that is activated by Service Broker, as a background service, as a scheduled event, or as an external application. The final decision depends on the role that the Service Broker plays in your application. For example, if your application processes a continuous stream of messages that arrive at a predictable rate, you may use a background service. If your application needs to scale dynamically based on the number of messages arriving, you can use a stored procedure activated by a queue. If your application holds messages in a queue and processes all the messages at a set time, you can use a scheduled event to start the application.
You can use an external application if your program requires access to resources outside the database such as web pages or files. Using an external application can improve the scalability of your application, because processing takes place on the mid-tier servers rather than on the database server. Service Broker provides remote transactional access to queues, so it is easy to scale out an application that uses Service Broker. Any application that can send Transact-SQL commands to the database and process the results can use Service Broker.
Each external program is isolated from other programs using the queue, so the external programs need no special precautions to manage access to the queue. Further, if the connection fails while the application is processing a message, the transaction rolls back and Service Broker returns the message to the queue. Network problems cannot cause the application to lose a message. - What technology do you plan to use to implement your application?
You can implement an external application with any technology that can connect to the database and run Transact-SQL statements in SQL Server, although applications are typically developed in a .NET framework-compatible language and ADO.Net. You can implement a stored procedure in either Transact-SQL or one of the .NET Framework-compatible languages. Transact-SQL can provide better performance against the Database Engine, while the CLR-compliant languages can provide greater flexibility, tighter control of program flow, better performance for processor-intensive applications, and direct access to the .NET Framework. - What server components will your application use most heavily?
Work with your system administrator and ensure that you have adequate resources to achieve optimum application performance. Know which components you will use most frequently. For example, if your application uses queues to even out the processing workload, or turns on message retention, you should ensure that there is adequate disk space for the queue to grow. Conversely, an application with high messaging volumes but lower queue wait times may use more network bandwidth, but consume less disk space.
See Also
Other Resources
Installing Service Broker Applications
Managing Service Broker Applications