Developer Responsibilities for Service Broker

The application developer is responsible for designing the Service Broker application and creating elements that require programming. The system administrator is responsible for configuring and managing Service Broker. Developers and administrators must work together when they plan the system, to ensure that it is developed and managed optimally for their particular environment and business purposes.

The tasks involved in creating an individual application depend on the needs of the application. The following is a common sequence of tasks for developing a Service Broker application:

1. Plan the application. Create an outline of the tasks that the application must accomplish. Describe the conversations that occur during each task. Which endpoint has to provide what information, in what order? What processing must occur? All subsequent information depends on this outline.
2. Determine the format and structure of each message in each conversation. Plan the expected sequence of exchange for the messages, and how each participant in the conversation should respond to errors and messages that are sent in an unexpected order.
3. If the conversation uses XML messages, create a schema for each XML message. You use schemas during development, testing, and troubleshooting. When your service is in production, you might decide to remove schema validation from your message types, to improve performance.
4. Create a message type for each message in each conversation.
5. Create a contract for each conversation. The contract identifies the message types that can be used by each endpoint in the conversation.
6. Create a queue to store the messages that will be received by the application.
7. Create a service to expose the functionality defined by the contract, and implemented by the stored procedure, that you created. When creating a service, you associate it with the queue you created in the previous step. By doing this, you tell Service Broker that all messages that arrive addressed to that service are to be put in the identified queue.
8. Create an application that implements the expected message exchange pattern and processing requirements identified in step 1. If your application uses internal activation, the application is a stored procedure.
9. If your application uses internal activation, alter the queue to enable activation. Specify the stored procedure created in step 8 as the activation stored procedure.
10. Identify the services that use the service that you have just created. If one or more of these services exist outside the local SQL Server instance, create routes for them.
11. Review the remote services that you identified in the previous step, and determine the security requirements for communications with them. If necessary, create certificates to enforce these requirements, and then create database users for the certificates. Associate the certificates with these logins. The administrators or developers of the other services must create remote service bindings to enable dialog security on traffic to this service.
12. During development and testing, it is often convenient for an application to work with the user names that the application will use in production. Ensure that you associate those user names with certificates that are used only in the development and test environment. When the application moves into production, use certificates created for the production environment. By using different certificates, you can reduce the effort involved in deploying the application while still maintaining security between the development environment and the production environment.

See Also

Other Resources

Installing Service Broker Applications
Managing Service Broker Applications
Service Broker Tutorials

Help and Information

Getting SQL Server 2005 Assistance