Light freshness - SQL - Service Broker 10

Author: gitName

docs/database-engine/service-broker/creating-service-broker-queues.md

@@ -37,4 +37,4 @@ Using activation stored procedures is a common way to design Service Broker appl
 - [CREATE QUEUE (Transact-SQL)](../../t-sql/statements/create-queue-transact-sql.md)
 - [Conversation architecture](conversation-architecture.md)
 - [Queues](queues.md)
-- [Understanding when activation occurs](understanding-when-activation-occurs.md)
+- [Understand when activation occurs](understanding-when-activation-occurs.md)

docs/database-engine/service-broker/queues.md

@@ -33,6 +33,6 @@ A queue might be associated with a stored procedure. In this case, SQL Server ac
 - [RECEIVE (Transact-SQL)](../../t-sql/statements/receive-transact-sql.md)
 - [Service Broker activation](service-broker-activation.md)
 - [Choose a startup strategy](choosing-a-startup-strategy.md)
-- [Understanding when activation occurs](understanding-when-activation-occurs.md)
+- [Understand when activation occurs](understanding-when-activation-occurs.md)
 - [Create Service Broker queues](creating-service-broker-queues.md)
 - [Benefits of programming with Service Broker](benefits-of-programming-with-service-broker.md)

docs/database-engine/service-broker/removing-poison-messages.md

@@ -1,5 +1,5 @@
 ---
-title: Removing Poison Messages
+title: Remove Poison Messages
 description: "A poison message is a message containing information that an application cannot successfully process."
 author: rwestMSFT
 ms.author: randolphwest
@@ -20,7 +20,7 @@ A poison message isn't a corrupt message, and might not be an invalid request. S
 
 ## Automatic poison message detection
 
-Service Broker provides automatic poison message detection. When a transaction that contains a `RECEIVE` statement rolls back five times, Service Broker disables all queues that the transaction received messages from, by automatically setting the queue status to `OFF`. In addition, Service Broker generates an event of type Broker:Queue Disabled.
+Service Broker provides automatic poison message detection. When a transaction that contains a `RECEIVE` statement rolls back five times, Service Broker disables all queues from which the transaction received messages by automatically setting the queue status to `OFF`. In addition, Service Broker generates an event of type **Broker:Queue Disabled**.
 
 An administrator might use SQL Server Agent alerts to be notified when a queue is disabled. A developer can also create an application that detects when a queue is disabled by Service Broker. That application often inspects the messages in the queue to find the poison message. Once the application determines which message can't be processed, the application sets the queue status to `ON` and ends the conversation for the message with an error. An application that detects poison messages must be careful to clean up any state associated with the conversation when ending the conversation. For more information on creating an application to recover from poison messages, see [Handle poison messages](handling-poison-messages.md).
 
@@ -94,7 +94,7 @@ ROLLBACK TRANSACTION;
 GO
 ```
 
-When you find a poison message, you end the conversation. The following example ends the conversation e29059bb-9922-40f4-a575-66b2e4c70cf9.
+When you find a poison message, you end the conversation. The following example ends the conversation e29059bb-9922-40f4-a575-66b2e4c70cf9:
 
 ```sql
 -- End the conversation. Do this only if the message cannot be

docs/database-engine/service-broker/routes.md

@@ -18,15 +18,15 @@ Service Broker uses routes to determine where to deliver messages. When a servic
 
 There are three basic components of a route:
 
-- Service name
+- **Service name**
 
   The name of the service that this route specifies addressing for. This name must be an exact match for the Service Name in the `BEGIN DIALOG` command.
 
-- Broker instance identifier
+- **Broker instance identifier**
 
   A unique identifier for a specific database to send the messages to. This is the `service_broker_guid` column in the `sys.databases` table row for the database that this route points to.
 
-- Network address
+- **Network address**
 
   An actual machine address, a keyword that restricts the route to the local machine, or a keyword that indicates that the transport layer deduces the address from the service name. A network address can be the address of the broker that hosts the service, or it can be the address of a forwarding broker.
 

docs/database-engine/service-broker/security-overview.md

@@ -16,13 +16,13 @@ ms.topic: conceptual
 
 Service Broker helps you write highly scalable database applications that are also secure and reliable. Service Broker security allows services hosted by different SQL Server instances to communicate securely, even where the instances are on different computers that have no other trust relationship or where the source and destination computers aren't connected to the same network at the same time.
 
-Service Broker security relies on certificates. The general approach is to use certificates to establish the credentials of a remote database, and then to map operations from the remote database to a local user. The permissions for the local user apply to any operation on behalf of the remote service. The certificate is shared between databases. No other information for the user is shared.
+Service Broker security relies on certificates. The general approach is to use certificates to establish the credentials of a remote database, then to map operations from the remote database to a local user. The permissions for the local user apply to any operation on behalf of the remote service. The certificate is shared between databases. No other information for the user is shared.
 
-Service Broker provides two distinct types of security - dialog security and transport security. Understanding these two types of security, and how they work together, helps you to design, deploy, and administer Service Broker applications.
+Service Broker provides two distinct types of security: dialog security and transport security. Understanding these two types of security and how they work together helps you to design, deploy, and administer Service Broker applications.
 
-- **Dialog security** - Encrypts messages in an individual dialog conversation and verifies the identities of participants in the dialog. Dialog security also provides remote authorization and message integrity checking. Dialog security establishes authenticated and encrypted communication between two services.
+- **Dialog security**: Encrypts messages in an individual dialog conversation and verifies the identities of participants in the dialog. Dialog security also provides remote authorization and message integrity checking. Dialog security establishes authenticated and encrypted communication between two services.
 
-- **Transport security** - Prevents unauthorized databases from sending Service Broker messages to databases in the local instance. Transport security establishes an authenticated network connection between two databases.
+- **Transport security**: Prevents unauthorized databases from sending Service Broker messages to databases in the local instance. Transport security establishes an authenticated network connection between two databases.
 
 The dialog protocol and the adjacent broker protocol are designed around passing messages between databases, rather than executing commands on a remote database. This style of communication allows Service Broker to provide services without requiring databases to share SQL Server logins or Windows security credentials.
 
@@ -42,7 +42,7 @@ To satisfy the requirement that messages must be encrypted, Adventure Works and
 
 1. Each vendor installs the certificate from Adventure Works Cycles into the database and creates a user that owns the certificate.
 
-1. The vendor then creates a key pair, and sends information on the service name for the vendor service and a certificate with the public key of that key pair to the AdventureWorks2008R2 administrator.
+1. The vendor then creates a key pair and sends information on the service name for the vendor service and a certificate with the public key of that key pair to the AdventureWorks2008R2 administrator.
 
 1. The AdventureWorks2008R2 administrator creates a user for each vendor and associates the certificate from that vendor with the user.
 

docs/database-engine/service-broker/service-architecture.md

@@ -18,13 +18,13 @@ This section describes the database objects that specify the basic design of an
 
 At design time, Service Broker applications specify the following objects:
 
-- Message types - Define the names of the messages exchanged between applications. Optionally provide validation for the messages.
+- **Message types**: Define the names of the messages exchanged between applications. Optionally provide validation for the messages.
 
-- Contracts- Specify the direction and type of messages in a given conversation.
+- **Contracts**: Specify the direction and type of messages in a given conversation.
 
-- Queues- Store messages. This storage mechanism allows for asynchronous communication between services. Service Broker queues provide additional benefits, such as automatically locking messages in the same conversation group.
+- **Queues**: Store messages. This storage mechanism allows for asynchronous communication between services. Service Broker queues provide additional benefits, such as automatically locking messages in the same conversation group.
 
-- Services- Are addressable endpoints for conversations. Service Broker messages are sent from one service to another service. A service specifies a queue to hold messages, and specifies the contracts for which the service can be the target. A contract provides a service with a well-defined set of message types.
+- **Services**: Are addressable endpoints for conversations. Service Broker messages are sent from one service to another service. A service specifies a queue to hold messages, and specifies the contracts for which the service can be the target. A contract provides a service with a well-defined set of message types.
 
 A Service Broker application uses the SQL Server objects in the preceding list to conduct a conversation. Any program that can run Transact-SQL statements in SQL Server can use Service Broker. Applications can be stored procedures written in Transact-SQL or a CLR-compliant language, or they can be external programs that connect to an instance of SQL Server.
 
@@ -39,7 +39,7 @@ As shown in the illustration, the **ProcessExpenses** contract specifies three m
 | Article | Description |
 | --- | --- |
 | [Message types](message-types.md) | Participants in a conversation must agree on the name and content of each message. Message types define names and content. |
-| [Contracts](contracts.md) | Contracts defines which message types an application uses to accomplish a particular task. |
+| [Contracts](contracts.md) | Contracts define which message types an application uses to accomplish a particular task. |
 | [Queues](queues.md) | Queues store Service Broker messages. |
 | [Services](services.md) | Service Broker services are names for specific business tasks or sets of business tasks. |
 

docs/database-engine/service-broker/service-broker-activation.md

@@ -26,7 +26,7 @@ Not all Service Broker applications use activation. If an application requires s
 
 | Article | Description |
 | --- | --- |
-| [Understanding when activation occurs](understanding-when-activation-occurs.md) | Describes the two steps of the Service Broker activation process. |
+| [Understand when activation occurs](understanding-when-activation-occurs.md) | Describes the two steps of the Service Broker activation process. |
 | [Internal activation context](internal-activation-context.md) | Describes the execution context for a stored procedure that is started by internal activation. |
 | [Event-based activation](event-based-activation.md) | Describes the event and strategies for receiving and responding to the event. |
 

docs/database-engine/service-broker/service-broker-application-outline.md

@@ -34,7 +34,7 @@ Most Service Broker applications follow the same basic steps to receive and proc
 
 The precise structure of the application depends on the requirements of the application, the communication style of the application, whether the application is a target service or an initiating service, and whether Service Broker activates the application or not.
 
-For example, an initiating application sends a message before it starts the processing loop outlined in the preceding steps. The initiating service might send a message from another program or stored procedure, and then use an activation stored procedure for the initiating service queue. For example, an order entry application can include an external application that initiates the conversation to enter the order. After the order is entered, the external application need not remain running. An activation stored procedure for the initiating service sends the order confirmation when a response returns from the order service. The activation stored procedure also processes any Service Broker error messages that are returned by the target service and sends notifications that the order couldn't be confirmed.
+For example, an initiating application sends a message before it starts the processing loop outlined in the preceding steps. The initiating service might send a message from another program or stored procedure, then use an activation stored procedure for the initiating service queue. For example, an order-entry application can include an external application that initiates the conversation to enter the order. After the order is entered, the external application need not remain running. An activation stored procedure for the initiating service sends the order confirmation when a response returns from the order service. The activation stored procedure also processes any Service Broker error messages that are returned by the target service and sends notifications that the order couldn't be confirmed.
 
 Alternatively, rather than sending a message from a different program, the initiating application might send a message and then start the processing loop as part of the same program. Regardless of these variations, the basic outline remains the same.
 

docs/database-engine/service-broker/service-broker-communication-protocols.md

@@ -60,7 +60,7 @@ Fragmenting messages has several advantages. Sending a large message in small fr
 
 While a message is being reassembled, the partial message is stored in the destination queue. If the destination queue isn't available, it's stored in the transmission queue. A partial message can't be received by an application. The `status` column for a partial message is set to `2` (Disabled). This value is also used for messages received out of order.
 
-### Message acknowledgement
+### Message acknowledgment
 
 Service Broker acknowledges each message received. An acknowledgment can acknowledge one or several message fragments. If possible, an acknowledgment is included in the header of a message returned on the same conversation. If no other messages are ready to be sent, Service Broker returns a dedicated acknowledgment message. Message acknowledgment is handled entirely by Service Broker; an application that uses Service Broker doesn't receive these messages.
 

docs/database-engine/service-broker/service-broker-configuration-notice-service.md

@@ -14,14 +14,14 @@ ms.topic: conceptual
 
 [!INCLUDE [sql-asdbmi](../../includes/applies-to-version/sql-asdbmi.md)]
 
-You can create a Broker Configuration Notice (BCN) service on an initiating server which will automatically bind conversations to a specific user on a target server.
+You can create a Broker Configuration Notice (BCN) service on an initiating server which automatically binds conversations to a specific user on a target server.
 
 ## Initiate conversations
 
-When a BCN service is created, the initiating service will send a **MissingRemoteServiceBinding** message to the BCN service to ask if a user context is available for the conversation on the target server. When the BCN service responds that a user context is available, the user context is bound to the conversation, and all messages are added to the queue under the context of the user. If `ENCRYPTION = ON`, the dialog will not proceed until the BCN service confirms that a user context is available. If `ENCRYPTION = OFF`, the dialog will proceed after the BCN ends the **MissingRemoteServiceBinding** conversation.
+When a BCN service is created, the initiating service sends a **MissingRemoteServiceBinding** message to the BCN service to ask if a user context is available for the conversation on the target server. When the BCN service responds that a user context is available, the user context is bound to the conversation, and all messages are added to the queue under the context of the user. If `ENCRYPTION = ON`, the dialog won't proceed until the BCN service confirms that a user context is available. If `ENCRYPTION = OFF`, the dialog proceeds after the BCN ends the **MissingRemoteServiceBinding** conversation.
 
 > [!NOTE]  
-> If a BCN service is created, the initiating service will request the user context regardless of the encryption status.
+> If a BCN service is created, the initiating service requests the user context regardless of the encryption status.
 
 ## Service Broker Configuration Notice service and dynamic routing