Naming Service Broker Objects
09/11/2025 This article describes considerations for naming service broker objects. The conventions differ slightly for public interface objects,
This article describes considerations for naming service broker objects. The conventions differ
slightly for public interface objects, network and security configuration objects, and queues.
Contracts, services, and message types form the public interface of a Service Broker
application. Because the names of these objects are contained in messages, naming
conventions for these objects often follow Universal Resource Identifier (URI) naming
conventions. This helps to ensure unique names for the objects.
Services names can also use the conventions to specify a network address in a route. In this
case, the name of the service can be used in a transport route. For more information on
routing, see
Service Broker routing.
When sending and receiving messages, Service Broker uses binary matching for the names of
these objects. Therefore, characters that have more than one binary representation require
special care when public interface objects are named.
The names for routes and remote service bindings are never included in a message. For
convenience, these names can use the name of the service that the object configures.
These objects can’t be temporary objects. Therefore, the number sign (#) isn’t considered
significant in names for these objects. An object with a name that begins with # is a permanent
object rather than a temporary object.
Queue names can be used for many of the statements that accept table names. Therefore,
queues names follow standard SQL Server identifier conventions, with one exception. Because
queues can’t be temporary objects, the name of a queue can’t start with the number sign (#).
Queues are schema-owned objects, so queue names can include a schema name and database
name.