Light freshness - SQL - Service Broker 13

gitName · rwestMSFT · commit d14f69d3d070 · 2025-09-16T11:06:27.000-06:00
diff --git a/docs/database-engine/service-broker/choosing-a-startup-strategy.md b/docs/database-engine/service-broker/choosing-a-startup-strategy.md
@@ -63,5 +63,5 @@ This strategy can be useful for an application that processes a constant stream
 ## Related content
 
 - [Create a Job](../../ssms/agent/create-a-job.md)
-- [Service Broker Activation](service-broker-activation.md)
+- [Service Broker activation](service-broker-activation.md)
 - [Implement internal activation in Service Broker](implementing-internal-activation.md)
diff --git a/docs/database-engine/service-broker/conversation-groups.md b/docs/database-engine/service-broker/conversation-groups.md
@@ -30,7 +30,7 @@ The messages to the payroll service and the messages to the benefits service don
 
 ## Organize application state
 
-One benefit of the conversation group is that the conversation group identifier is a convenient key to identify and retrieve application state. The conversation group identifier makes it easy to maintain application state in the database. If accomplishing a task involves exchanging many messages over time, it's inefficient to keep an instance of the application running just to maintain the application state. An application scales better if, between messages, any data associated with the task is stored in the database and then is retrieved when the next message associated with that task is received. The conversation group identifier can be used as the primary key in a state table provided by an application developer to enable quick retrieval of the state associated with a particular task. For more information about using the conversation group identifier to maintain state, see [State Management](state-management.md).
+One benefit of the conversation group is that the conversation group identifier is a convenient key to identify and retrieve application state. The conversation group identifier makes it easy to maintain application state in the database. If accomplishing a task involves exchanging many messages over time, it's inefficient to keep an instance of the application running just to maintain the application state. An application scales better if, between messages, any data associated with the task is stored in the database and then is retrieved when the next message associated with that task is received. The conversation group identifier can be used as the primary key in a state table provided by an application developer to enable quick retrieval of the state associated with a particular task. For more information about using the conversation group identifier to maintain state, see [State management](state-management.md).
 
 Because SQL Server locks the conversation group each time an application sends or receives a message, an application doesn't need to explicitly prevent another program from updating the same state data at the same time. The application simply locks the conversation group, restores state, processes messages, updates state, and then commits the transaction.
 
diff --git a/docs/database-engine/service-broker/conversation-priorities.md b/docs/database-engine/service-broker/conversation-priorities.md
@@ -212,5 +212,5 @@ While individual messages or message fragments might be sent out of priority ord
 - [sys.conversation_priorities (Transact-SQL)](../../relational-databases/system-catalog-views/sys-conversation-priorities-transact-sql.md)
 - [sys.transmission_queue (Transact-SQL)](../../relational-databases/system-catalog-views/sys-transmission-queue-transact-sql.md)
 - [Conversation architecture](conversation-architecture.md)
-- [Service Architecture](service-architecture.md)
-- [Service Broker Routing and Networking](service-broker-routing-and-networking.md)
+- [Service architecture](service-architecture.md)
+- [Service Broker routing and networking](service-broker-routing-and-networking.md)
diff --git a/docs/database-engine/service-broker/creating-a-remote-service-binding.md b/docs/database-engine/service-broker/creating-a-remote-service-binding.md
@@ -19,7 +19,7 @@ To exchange messages with Service Broker, you must create the appropriate user s
 When a conversation is initiated, Service Broker checks to see whether a remote service binding is available for the target service. If a remote service binding isn't available, Service Broker checks the routing table for the Broker Configuration Notice (BCN) service; the service name is `SQL/ServiceBroker/BrokerConfiguration`. If a BCN route exists, Service Broker creates a new conversation with the BCN and sends a message on that conversation that requests creation of a remote service binding. The application defined for the BCN queue must then respond to the request.
 
 > [!NOTE]  
-> The behavior is comparable to [Service Broker Dynamic Routing](service-broker-dynamic-routing.md).
+> The behavior is comparable to [Service Broker dynamic routing](service-broker-dynamic-routing.md).
 
 ## Request remote service binding
 
diff --git a/docs/database-engine/service-broker/creating-service-broker-applications.md b/docs/database-engine/service-broker/creating-service-broker-applications.md
@@ -37,9 +37,9 @@ If Service Broker detects an error or the conversation lifetime expires, Service
 | Article | Description |
 | --- | --- |
 | [Choose a startup strategy](choosing-a-startup-strategy.md) | Discusses some of the most common strategies for starting an application that uses Service Broker. |
-| [Service Broker Application Outline](service-broker-application-outline.md) | Describes the basic steps to receive and process messages. |
+| [Service Broker application outline](service-broker-application-outline.md) | Describes the basic steps to receive and process messages. |
 
 ## Related content
 
-- [Service Broker Activation](service-broker-activation.md)
-- [Transactional Messaging](transactional-messaging.md)
+- [Service Broker activation](service-broker-activation.md)
+- [Transactional messaging](transactional-messaging.md)
diff --git a/docs/database-engine/service-broker/handling-poison-messages.md b/docs/database-engine/service-broker/handling-poison-messages.md
@@ -174,5 +174,5 @@ If you believe that the processing you perform on the message might cause a tran
 
 - [TRY...CATCH (Transact-SQL)](../../t-sql/language-elements/try-catch-transact-sql.md)
 - [sys.conversation_endpoints (Transact-SQL)](../../relational-databases/system-catalog-views/sys-conversation-endpoints-transact-sql.md)
-- [Removing Poison Messages](removing-poison-messages.md)
+- [Remove poison messages](removing-poison-messages.md)
 - [Understanding Database Engine Errors](../../relational-databases/errors-events/understanding-database-engine-errors.md)
diff --git a/docs/database-engine/service-broker/internal-activation-context.md b/docs/database-engine/service-broker/internal-activation-context.md
@@ -32,7 +32,7 @@ Within a session started by Service Broker, SQL Server writes the output of `PRI
 
 ## Transaction context
 
-An activated stored procedure is responsible for managing transactions. SQL Server doesn't start a transaction before activating the stored procedure, and the stored procedure runs in a different transaction context than the internal operation that activates the procedure. For a discussion of managing transactions in activated stored procedures, see [Transactional Messaging](transactional-messaging.md).
+An activated stored procedure is responsible for managing transactions. SQL Server doesn't start a transaction before activating the stored procedure, and the stored procedure runs in a different transaction context than the internal operation that activates the procedure. For a discussion of managing transactions in activated stored procedures, see [Transactional messaging](transactional-messaging.md).
 
 ## Failure detection
 
diff --git a/docs/database-engine/service-broker/lesson-1-creating-the-conversation-objects.md b/docs/database-engine/service-broker/lesson-1-creating-the-conversation-objects.md
@@ -93,7 +93,7 @@ In this lesson, you learn to build all the objects that enable a database to sup
 - [CREATE QUEUE (Transact-SQL)](../../t-sql/statements/create-queue-transact-sql.md)
 - [CREATE SERVICE (Transact-SQL)](../../t-sql/statements/create-service-transact-sql.md)
 - [Conversation architecture](conversation-architecture.md)
-- [Service Architecture](service-architecture.md)
+- [Service architecture](service-architecture.md)
 
 ## Next step
 
diff --git a/docs/database-engine/service-broker/lesson-1-creating-the-target-database.md b/docs/database-engine/service-broker/lesson-1-creating-the-target-database.md
@@ -135,7 +135,7 @@ In this lesson, you learn to create the target database and all the Service Brok
 - [CREATE USER (Transact-SQL)](../../t-sql/statements/create-user-transact-sql.md)
 - [Service Broker dialog security](service-broker-dialog-security.md)
 - [Conversation architecture](conversation-architecture.md)
-- [Service Architecture](service-architecture.md)
+- [Service architecture](service-architecture.md)
 
 ## Next step
 
diff --git a/docs/database-engine/service-broker/lesson-2-creating-the-initiator-database.md b/docs/database-engine/service-broker/lesson-2-creating-the-initiator-database.md
@@ -189,7 +189,7 @@ In this lesson, you learn to create the initiator database and all the initiator
 - [sp_addlinkedserver (Transact-SQL)](../../relational-databases/system-stored-procedures/sp-addlinkedserver-transact-sql.md)
 - [Service Broker dialog security](service-broker-dialog-security.md)
 - [Conversation architecture](conversation-architecture.md)
-- [Service Architecture](service-architecture.md)
+- [Service architecture](service-architecture.md)
 
 ## Next step
 
diff --git a/docs/database-engine/service-broker/lesson-2-creating-the-target-conversation-objects.md b/docs/database-engine/service-broker/lesson-2-creating-the-target-conversation-objects.md
@@ -71,7 +71,7 @@ In this lesson, you learn to build all the objects that enable a database to be
 - [CREATE QUEUE (Transact-SQL)](../../t-sql/statements/create-queue-transact-sql.md)
 - [CREATE SERVICE (Transact-SQL)](../../t-sql/statements/create-service-transact-sql.md)
 - [Conversation architecture](conversation-architecture.md)
-- [Service Architecture](service-architecture.md)
+- [Service architecture](service-architecture.md)
 
 ## Next step
 
diff --git a/docs/database-engine/service-broker/typical-uses-of-service-broker.md b/docs/database-engine/service-broker/typical-uses-of-service-broker.md
@@ -31,15 +31,15 @@ When the original transaction commits, Service Broker delivers the message to th
 
 ## Reliable query processing
 
-Some applications must reliably process queries, without regard to computer failures, power outages, or similar problems. An application that needs reliable query processing can submit queries by sending messages to a Service Broker service. The application that implements the service reads the message, runs the query, and returns the results. All three of these operations take place in the same transaction. If a failure occurs before the transaction commits, the entire transaction rolls back and the message returns to the queue. When the computer recovers, the application restarts and processes the message again.
+Some applications must reliably process queries without regard to computer failures, power outages, or similar problems. An application that needs reliable query processing can submit queries by sending messages to a Service Broker service. The application that implements the service reads the message, runs the query, and returns the results. All three of these operations take place in the same transaction. If a failure occurs before the transaction commits, the entire transaction rolls back and the message returns to the queue. When the computer recovers, the application restarts and processes the message again.
 
 ## Reliable data collection
 
 Applications that collect data from a large set of sources can take advantage of Service Broker to reliably collect data. For instance, a retail application with multiple sites can use Service Broker to send transaction information to a central data store. Because Service Broker provides reliable, asynchronous message delivery, each site can continue to process transactions even if the site temporarily loses connectivity to the central data store. Service Broker security helps to ensure that messages aren't misdirected, and helps to protect the data in transit.
 
 ## Distributed server-side processing for client applications
 
-Large applications that access multiple SQL Server databases can benefit from Service Broker. For example, a Web application for ordering books could use Service Broker on the server side to exchange information between the different databases that contain data on ordering, customer, inventory, and credit. Because Service Broker provides message queuing and reliable message delivery, the application can continue to accept orders even when one of the databases is unavailable or heavily loaded. In this scenario, Service Broker functions as a framework for a distributed OLTP system.
+Large applications that access multiple SQL Server databases can benefit from Service Broker. For example, a Web application for ordering books could use Service Broker on the server side to exchange information among the different databases that contain data on ordering, customer, inventory, and credit. Because Service Broker provides message queuing and reliable message delivery, the application can continue to accept orders even when one of the databases is unavailable or heavily loaded. In this scenario, Service Broker functions as a framework for a distributed OLTP system.
 
 ## Data consolidation for client applications
 
diff --git a/docs/database-engine/service-broker/understanding-collation-and-service-broker.md b/docs/database-engine/service-broker/understanding-collation-and-service-broker.md
@@ -1,5 +1,5 @@
 ---
-title: Understanding Collation and Service Broker
+title: Understand Collation and Service Broker
 description: "Service Broker is designed to let services and applications in instances with different collation configurations communicate easily and efficiently."
 author: rwestMSFT
 ms.author: randolphwest
@@ -10,19 +10,19 @@ ms.subservice: configuration
 ms.topic: concept-article
 ---
 
-# Understanding collation and Service Broker
+# Understand collation and Service Broker
 
 [!INCLUDE [sql-asdbmi](../../includes/applies-to-version/sql-asdbmi.md)]
 
-Service Broker is designed to let services and applications in instances with different collation configurations communicate easily and efficiently. The database that hosts a service that sends a message might not use the same collation as the database that hosts the service that receives the message. Therefore, Service Broker uses a consistent collation for names, regardless of the collation of the database that hosts the service. To remove collation information from the communication process, Service Broker uses a byte-by-byte comparison to match service names, contract names, and message type names. By matching names as sequences of bytes, Service Broker makes it simple for services to exchange messages correctly without the extra overhead of exchanging collation information.
+Service Broker is designed to let services and applications communicate easily and efficiently in instances with different collation configurations. The database that hosts a service that sends a message might not use the same collation as the database that hosts the service that receives the message. Therefore, Service Broker uses a consistent collation for names, regardless of the collation of the database that hosts the service. To remove collation information from the communication process, Service Broker uses a byte-by-byte comparison to match service names, contract names, and message type names. By matching names as sequences of bytes, Service Broker makes it simple for services to exchange messages correctly without the extra overhead of exchanging collation information.
 
 The byte-by-byte match is effectively a binary comparison that doesn't consider the current collation. For this reason, many broker services find it convenient to follow the recommendations in [Name Service Broker objects](naming-service-broker-objects.md). An application that follows these guidelines and treats all names as case-sensitive should function correctly regardless of differences in collation between the database that hosts the target service and the database that hosts the initiating service.
 
 ## Queue collation considerations
 
 Queues use a consistent collation regardless of the default collation of the SQL Server instance or the default collation of the database that hosts the queue. If a queue is the target of a `SELECT` statement that includes a `JOIN` statement with another table in the database, such as a table used to maintain state, you might be required to explicitly specify the collation for the comparison.
 
-For example, an application that uses message retention might need to preserve some messages for a conversation before the application ends the conversation. The following Transact-SQL code sample saves all messages, for a given conversation, that have a message type name in the table **AuditedMessageTypes**.
+For example, an application that uses message retention might need to preserve some messages for a conversation before the application ends the conversation. The following Transact-SQL code sample saves all messages for a given conversation that have a message type name in the table `AuditedMessageTypes`:
 
 ```sql
 IF @messageTypeName = 'https://schemas.microsoft.com/SQL/ServiceBroker/EndDialog'
@@ -38,11 +38,11 @@ IF @messageTypeName = 'https://schemas.microsoft.com/SQL/ServiceBroker/EndDialog
     END
 ```
 
-The `SELECT` statement explicitly specifies a binary comparison for matching the message type names. Because a queue doesn't use the database default collation, the `COLLATE` clause is required for the comparison am.message_type_name = q.message_type_name to succeed. The statement specifies a binary collation, `Latin1_General_BIN`, to match the behavior of the internal comparison that Service Broker uses to match service names.
+The `SELECT` statement explicitly specifies a binary comparison for matching the message type names. Because a queue doesn't use the database default collation, the `COLLATE` clause is required for the comparison `am.message_type_name = q.message_type_name` to succeed. The statement specifies a binary collation, `Latin1_General_BIN`, to match the behavior of the internal comparison that Service Broker uses to match service names.
 
 ## Application collation considerations
 
-Service Broker transmits the message body as binary data and doesn't modify the content of the message. If applications exchange data that is collation-sensitive, the applications must handle any collation differences. Applications that exchange text generally use Unicode types to help minimize collation problems.
+Service Broker transmits the message body as binary data and doesn't modify the content of the message. If applications exchange data that's collation-sensitive, the applications must handle any collation differences. Applications that exchange text generally use Unicode types to help minimize collation problems.
 
 ## Related content
 
diff --git a/docs/database-engine/service-broker/understanding-when-activation-occurs.md b/docs/database-engine/service-broker/understanding-when-activation-occurs.md
diff --git a/docs/database-engine/service-broker/uninstalling-service-broker-applications.md b/docs/database-engine/service-broker/uninstalling-service-broker-applications.md
diff --git a/docs/database-engine/service-broker/upgrade.md b/docs/database-engine/service-broker/upgrade.md
diff --git a/docs/database-engine/service-broker/what-does-service-broker-do.md b/docs/database-engine/service-broker/what-does-service-broker-do.md
