edited spaces and added fixed moer see also sections

Author: markingmyname

docs/database-engine/service-broker/benefits-of-programming-with-service-broker.md

@@ -18,19 +18,19 @@ Queuing and asynchronous messaging are needed for many database applications tod
 
 Some of the benefits of programming with Service Broker are:
 
-  - **Flexible development:** The programs used in a single distributed application can be written in multiple languages. Each program provides the functionality of each distributed application component.
+- **Flexible development:** The programs used in a single distributed application can be written in multiple languages. Each program provides the functionality of each distributed application component.
 
-  - **Improved security:** You can express security requirements via certificates, so application components do not need to share the same security context. Service Broker uses SQL Server security features to help you secure your applications.
+- **Improved security:** You can express security requirements via certificates, so application components do not need to share the same security context. Service Broker uses SQL Server security features to help you secure your applications.
 
-  - **Transactional processing:** Message processing occurs within SQL Server transactions to ensure data integrity. Service Broker supports remote transactional messaging over a standard connection to the database.
+- **Transactional processing:** Message processing occurs within SQL Server transactions to ensure data integrity. Service Broker supports remote transactional messaging over a standard connection to the database.
 
-  - **Guaranteed ordering:** Service Broker provides strong guarantees regarding the delivery and processing of a related set of messages exactly once and in order, so no additional coding is required to provide this functionality.
+- **Guaranteed ordering:** Service Broker provides strong guarantees regarding the delivery and processing of a related set of messages exactly once and in order, so no additional coding is required to provide this functionality.
 
-  - **Reliable delivery:** All of the data needed for a conversation--a set of related communications between two or more services--is persisted in SQL Server. Service Broker supports clustering and database mirroring. A conversation may be maintained through system restarts, server failover, network outages, and so on without failing or losing data.
+- **Reliable delivery:** All of the data needed for a conversation--a set of related communications between two or more services--is persisted in SQL Server. Service Broker supports clustering and database mirroring. A conversation may be maintained through system restarts, server failover, network outages, and so on without failing or losing data.
 
-  - **Improved scalability:** Service Broker routing delivers messages based on the name of the service, rather than on the network address of the computer where the service runs. This allows you to install an application on multiple computers without changing application code.
+- **Improved scalability:** Service Broker routing delivers messages based on the name of the service, rather than on the network address of the computer where the service runs. This allows you to install an application on multiple computers without changing application code.
 
-  - **Ability to leverage existing knowledge:** Service Broker uses Transact-SQL to create objects. Applications that use Service Broker are most often implemented in Transact-SQL or Microsoft .NET Framework-compatible languages. You do not have to learn a new language to create Service Broker applications.
+- **Ability to leverage existing knowledge:** Service Broker uses Transact-SQL to create objects. Applications that use Service Broker are most often implemented in Transact-SQL or Microsoft .NET Framework-compatible languages. You do not have to learn a new language to create Service Broker applications.
 
 ## See also
 

docs/database-engine/service-broker/building-applications-with-service-broker.md

@@ -36,13 +36,13 @@ Service Broker stores messages sent to the **ProcessExpense** service on the que
 
 A conversation between these two services would be structured as follows:
 
-  - A user submits an expense reimbursement request through a user interface. The application runs the **ExpenseSubmission** stored procedure, which creates a **SubmitExpense** message. The **SubmitExpense** service starts a conversation with the **ProcessExpense** service, then sends the **SubmitExpense** message to the **ProcessExpense** service.
+- A user submits an expense reimbursement request through a user interface. The application runs the **ExpenseSubmission** stored procedure, which creates a **SubmitExpense** message. The **SubmitExpense** service starts a conversation with the **ProcessExpense** service, then sends the **SubmitExpense** message to the **ProcessExpense** service.
 
-  - Service Broker receives the **SubmitExpense** message for the **ProcessExpense** service and puts the message on the **ExpenseQueue** queue. The **ExpenseQueue** queue activates the **ProcessExpense** stored procedure, which dequeues and processes the **SubmitExpense** message. The **ProcessExpense** stored procedure then creates an **AcceptDenyExpense** message and sends this message to the **SubmitExpense** service. If the expense is denied, the **ProcessExpense** stored procedure ends the conversation.
+- Service Broker receives the **SubmitExpense** message for the **ProcessExpense** service and puts the message on the **ExpenseQueue** queue. The **ExpenseQueue** queue activates the **ProcessExpense** stored procedure, which dequeues and processes the **SubmitExpense** message. The **ProcessExpense** stored procedure then creates an **AcceptDenyExpense** message and sends this message to the **SubmitExpense** service. If the expense is denied, the **ProcessExpense** stored procedure ends the conversation.
 
-  - Service Broker puts the **AcceptDenyExpense** message for the **SubmitExpense** service on the queue for the service. If the **ProcessExpense** procedure ended the conversation, Service Broker puts an **EndDialog** message on the **Expenses** queue. The queue activates the **ExpenseSubmission** stored procedure, which dequeues and processes the **AcceptDenyExpense** message. If the **ExpenseSubmission** stored procedure finds an **EndDialog** message on the queue, the procedure ends the conversation.
+- Service Broker puts the **AcceptDenyExpense** message for the **SubmitExpense** service on the queue for the service. If the **ProcessExpense** procedure ended the conversation, Service Broker puts an **EndDialog** message on the **Expenses** queue. The queue activates the **ExpenseSubmission** stored procedure, which dequeues and processes the **AcceptDenyExpense** message. If the **ExpenseSubmission** stored procedure finds an **EndDialog** message on the queue, the procedure ends the conversation.
 
-  - If the expense was accepted, the **ProcessExpense** service creates and sends a **ReimbursementIssued** message confirming that the expense payment has been issued, and then ends the conversation. Service Broker puts these messages on the queue for the service. The queue activates the **ExpenseSubmission** procedure, and the procedure processes the **ReimbursementIssued** message. The procedure then processes the **EndDialog** message and ends the conversation.
+- If the expense was accepted, the **ProcessExpense** service creates and sends a **ReimbursementIssued** message confirming that the expense payment has been issued, and then ends the conversation. Service Broker puts these messages on the queue for the service. The queue activates the **ExpenseSubmission** procedure, and the procedure processes the **ReimbursementIssued** message. The procedure then processes the **EndDialog** message and ends the conversation.
 
 ## See also
 

docs/database-engine/service-broker/certificates-and-service-broker.md

@@ -22,7 +22,7 @@ Service Broker remote security maps an operation from outside an instance to a S
 
 SQL Server uses certificates to verify the identity of a remote database, and to identify the local database principal for the operation. Therefore, installing a certificate in SQL Server constitutes a statement of trust in the database that holds the private key for the certificate. Carefully manage the certificates that you install and the remote service bindings that you create.
 
-> [!NOTE]  
+> [!Note]
 > Only install certificates from trusted sources. Do not distribute private keys.
 
 To verify the identity of a remote server, SQL Server must receive information that can be decrypted with the public key in a certificate owned by a local database principal. If SQL Server can successfully decrypt the information, it means that the remote database contains the private key that corresponds to the public key in the local certificate. Once SQL Server verifies the identity of a remote database, the remote database can act with the permissions of the local database principal.
@@ -37,15 +37,15 @@ SQL Server does not provide automated methods for configuration of Service Broke
 
 To be used for Service Broker security, a certificate must meet the following requirements:
 
-  - The key modulus must be less than 2048.
+- The key modulus must be less than 2048.
 
-  - The total certificate length must be less than 32 kilobytes (KB).
+- The total certificate length must be less than 32 kilobytes (KB).
 
-  - A subject name must be specified.
+- A subject name must be specified.
 
-  - Validity dates must be specified.
+- Validity dates must be specified.
 
-  - The key length must be a multiple of 64 bits.
+- The key length must be a multiple of 64 bits.
 
 A self-signed certificate created with the Transact-SQL statement CREATE CERTIFICATE meets the requirements in the preceding list. Certificates that are loaded from a file may not meet these requirements.
 
@@ -54,6 +54,7 @@ When the certificate is stored in SQL Server, the certificate must be encrypted
 In order for SQL Server to use a certificate to begin a conversation, the certificate must be marked ACTIVE FOR BEGIN_DIALOG. Certificates are marked as active for begin dialog by default. However, you can choose to temporarily deactivate a certificate while updating the security configuration for a service. For more information, see [CREATE CERTIFICATE (Transact-SQL)](../../t-sql/statements/create-certificate-transact-sql.md) and [ALTER CERTIFICATE (Transact-SQL)](../../t-sql/statements/alter-certificate-transact-sql.md).
 
 ## See also
+
 - [CREATE CERTIFICATE (Transact-SQL)](../../t-sql/statements/create-certificate-transact-sql.md)
 - [Encryption Hierarchy](../../relational-databases/security/encryption/encryption-hierarchy.md)
 - [Service Broker Communication Protocols](service-broker-communication-protocols.md)

docs/database-engine/service-broker/certificates-for-dialog-security.md

@@ -45,15 +45,16 @@ Messages must be exchanged both ways before the local database considers the ide
 
 For the first message sent by each side of the conversation, Service Broker includes the following headers:
 
-  - A service pair security header containing information on the certificates used for the message. The service pair security header is signed with the private key for the user who owns the service.
+- A service pair security header containing information on the certificates used for the message. The service pair security header is signed with the private key for the user who owns the service.
 
-  - A key exchange key that encrypts the 128-bit session key used to encrypt the body of the message. The key exchange key is encrypted with the public key for the remote user.
+- A key exchange key that encrypts the 128-bit session key used to encrypt the body of the message. The key exchange key is encrypted with the public key for the remote user.
 
 For dialogs that use anonymous security, the service pair security header remains unencrypted. The message itself is still encrypted, and the key exchange key is encrypted with the public key for the security principal in the target database. In this case, the first return message does not contain a key exchange key, service pair security header, or an encrypted session key.
 
 When Service Broker itself generates a message in response to an incoming message (for example, an error or an acknowledgment), that message uses the session key of the incoming message, regardless of whether the dialog uses full security or anonymous security.
 
 ## See also
+
 - [CREATE REMOTE SERVICE BINDING (Transact-SQL)](../../t-sql/statements/create-remote-service-binding-transact-sql.md)
 - [ALTER REMOTE SERVICE BINDING (Transact-SQL)](../../t-sql/statements/alter-remote-service-binding-transact-sql.md)
 - [ALTER REMOTE SERVICE BINDING (Transact-SQL)](../../t-sql/statements/alter-remote-service-binding-transact-sql.md)

docs/database-engine/service-broker/choosing-a-startup-strategy.md

@@ -22,13 +22,13 @@ Service Broker supports asynchronous, queued messaging. Because conversations ca
 
 The strategies for starting an application fall into four broad categories:
 
-  - Internal activation
+- Internal activation
 
-  - Event-based activation
+- Event-based activation
 
-  - Scheduled task
+- Scheduled task
 
-  - Startup task
+- Startup task
 
 Each activation strategy has different advantages. An application can combine these strategies. For example, an application can use internal activation with a small number of queue readers most of the time. But, at certain times of the day, it can start more queue readers.
 
@@ -61,6 +61,7 @@ Some applications start one time, typically when the computer starts or when SQL
 This strategy can be useful for an application that processes a constant stream of messages and that is relatively resource-intensive during startup.
 
 ## See also
+
 - [Create a Job](../../ssms/agent/create-a-job.md)
 - [Service Broker Activation](service-broker-activation.md)
 - [Implementing Internal Activation](implementing-internal-activation.md)

docs/database-engine/service-broker/completing-a-conversation-between-databases.md

@@ -20,15 +20,15 @@ This tutorial is intended for users who are new to Service Broker, but are famil
 
 This tutorial builds on the tasks that you learned in the tutorial [Completing a Conversation in a Single Database](completing-a-conversation-in-a-single-database.md). In this tutorial you will learn how to configure the conversation so that it runs between two databases on the same instance of the Database Engine.
 
-The steps that you will follow in Lesson 2 are the same as those you followed in Lesson 1, with these exceptions:
+The steps that you follow in Lesson 2 are the same as those you followed in Lesson 1, with these exceptions:
 
-- You will create two databases: **InitiatorDB** and **TargetDB**. You will create all the initiator service and queue in the **InitiatorDB** and the target service and queue in the **TargetDB**.
+- Create two databases: **InitiatorDB** and **TargetDB**. You need to create all the initiator service and queue in the **InitiatorDB** and the target service and queue in the **TargetDB**.
 
-- You will create two copies of the message types and contacts, one in the **InitiatorDB** and the other in **TargetDB**. Both sides of the conversation must have access to message type and contract definitions that are identical.
+- Create two copies of the message types and contacts, one in the **InitiatorDB** and the other in **TargetDB**. Both sides of the conversation must have access to message type and contract definitions that are identical.
 
-- You will set the TRUSTWORTHY database property to ON in the **InitiatorDB**. This is the simplest mechanism for enabling conversations between two databases when they are on the same instance of the Database Engine.
+- Set the TRUSTWORTHY database property to ON in the **InitiatorDB**. This is the simplest mechanism for enabling conversations between two databases when they are on the same instance of the Database Engine.
 
-- You will learn which statements must be run in each database to complete a conversation, and the sequence in which they must be run.
+- Learn which statements must be run in each database to complete a conversation, and the sequence in which they must be run.
 
 Messages are not transmitted across a network for conversations that have both ends in the same instance of the Database Engine. Database Engine security and permissions restricts access to authorized principles. Network encryption is not needed for this scenario.
 
@@ -59,4 +59,5 @@ Your system must have the following installed:
 - A supported internet browser.
 
 ## See also
+
 - [Completing a Conversation Between Instances](completing-a-conversation-between-instances.md)

docs/database-engine/service-broker/completing-a-conversation-between-instances.md

@@ -20,11 +20,11 @@ This tutorial is intended for users who are new to Service Broker, but are famil
 
 This tutorial builds on the tasks that you learned in [Completing a Conversation Between Databases](completing-a-conversation-between-databases.md). In this tutorial, you will learn how to configure a conversation so that it runs between two instances of the Database Engine.
 
-The steps that you will follow in this tutorial are the same as those you followed in the Completing a Conversation Between Databases tutorial, with these exceptions:
+The steps that you follow in this tutorial are the same as those you followed in the Completing a Conversation Between Databases tutorial, with these exceptions:
 
-- The two databases will be on separate instances of the Database Engine.
+- The two databases are on separate instances of the Database Engine.
 
-- You will learn how to create Service Broker endpoints and routes to establish network connections between two instances.
+- You can learn how to create Service Broker endpoints and routes to establish network connections between two instances.
 
 - The previous tutorials did not transmit messages on the network. Therefore, they used Database Engine permissions to help protect against unauthorized access to messages. In Lesson 3, you will learn how to create certificates and remote service bindings to encrypt messages on the network.
 
@@ -77,5 +77,6 @@ Both systems must have the following installed:
 The firewalls for both systems must be configured to enable connections to UDP port 1434 and TCP ports 1433 and 4022. Use the Configuration Manager tool to ensure that both instances allow TCP/IP connections, and that the SQL Server Browser service is running on both computers.
 
 ## See also
+
 - [Completing a Conversation in a Single Database](completing-a-conversation-in-a-single-database.md)
 - [Completing a Conversation Between Databases](completing-a-conversation-between-databases.md)