CODE RUB: SPAL 1.8 Grammer Check

1. Brokers/1.8 Broker Provider Abstraction.md

@@ -1,17 +1,17 @@
 # 1.8 Standardized Provider Abstraction Libraries (SPAL)
-This special chapter will discuss the providers brokers may rely on to execute a certain operation. Most Brokers rely on external libraries or routines that are not owned by the engineers developing the system. These external libraries may or may not follow best practices in terms of abstraction and testing.
+This particular chapter will discuss the providers brokers may rely on to execute a certain operation. Most Brokers rely on external libraries or routines not owned by the engineers developing the system. These external libraries may or may not follow best practices regarding abstraction and testing.
 
-The Standard mandates relying on standardized providers for systems design and development. These standardized providers must have the following charactristics:
+The Standard mandates relying on standardized providers for systems design and development. These standardized providers must have the following characteristics:
 
 ## 1.8.0 Extensibility
-Standardized provider abstraction libraries must be extensidble to support more external providers. For instnace, a library that supports communicating with a database to SQL Server, must be extensible enough to support communicating with MongoDB or MariaDb or any other providers without any additional costs from the consumer of these libraries.
+Standardized provider abstraction libraries must be extensible to support more external providers. For example, a library that supports communicating with a database to SQL Server must be extensible enough to support communicating with MongoDB, MariaDB, or any other providers without any additional costs from the consumer of these libraries.
 
 <div align=center>
     <img src="https://raw.githubusercontent.com/hassanhabib/The-Standard/master/1.%20Brokers/Resources/Brokers-1.8.0.png" />
 </div>
 
 ### 1.8.0.0 Configurability
-In order for Standardized libraries to be usable with several providers, it must allow engineers to configure them to target a particular provider local or remote. For instance, provider abstraction libraries can be configured in the following fashion:
+For Standardized libraries to be usable with several providers, it must allow engineers to configure them to target a particular provider, local or remote. For instance, provider abstraction libraries can be configured in the following fashion:
 
 ```csharp
 public class StorageBroker
@@ -28,7 +28,7 @@ public class StorageBroker
 }
 ```
 
-Another example for using a different provider would be:
+Another example of using a different provider would be:
 
 ```csharp
 public class StorageBroker
@@ -46,9 +46,9 @@ public class StorageBroker
 ```
 
 ## 1.8.1 Distributability
-Abstraction libraries must allow several engineers to publish their own extensions of the library. The library does not need to have implementations of all providers in one binary. Instead, these libraries must provide an interface or a contract that all other extensions need to implement to support a certain provider.
+Abstraction libraries must allow several engineers to publish their extensions of the library. The library does not need to have implementations of all providers in one binary. Instead, these libraries must provide an interface or a contract that all other extensions must implement to support a specific provider.
 
-For instance, Let's assume we have the core standardized contract `Standard.Storages.Core`. We may publish a library `Standard.Storages.Sql` library. Anyone else can also publish `Standard.Storages.MongoDb` to support the very same interface. An interface would look something like this:
+For instance, Let's assume we have the core standardized contract `Standard.Storages.Core`. We may publish a library called `Standard.Storages.Sql`. Anyone else can also publish `Standard.Storages.MongoDb` to support the same interface. An interface would look something like this:
 
 ```csharp
 public interface IStorageProvider
@@ -60,12 +60,12 @@ public interface IStorageProvider
     void Configure(Options options);
 }
 ```
-This contract capabilities must be the bare minimum any provider must be able to provide. However, the additional options in the provider extension may expose more capabilities that may or may not exist in other libraries.
+This contract's capabilities must be the bare minimum any provider can provide. However, the additional options in the provider extension may expose more capabilities that may or may not exist in other libraries.
 
 ## 1.8.2 External Mockability (Cloud-Foreign)
-Standardized provider libraries must allow communications with mocked local phantom APIs. For instance, if a system requires a communication with a queue or an event bus in the cloud, the provider library abstracting that technology must allow a local connection for Acceptance Testing and Airplane-Mode runs which we talked about earlier as Cloud Foriegn Principle.
+Standardized provider libraries must allow communications with mocked local phantom APIs. For instance, if a system requires communication with a queue or an event bus in the cloud, the provider library abstracts that technology must allow a local connection for Acceptance Testing and Airplane-Mode runs, which we discussed earlier as Cloud Foriegn Principle.
 
-External Mockability may rely on other external library that implements a patterns such as PACT to create phantom or fake external API instance running on the local machine or network. Here's an example:
+External Mockability may rely on other external libraries that implement patterns such as PACT to create phantom or fake external API instances running on the local machine or network. Here's an example:
 
 
 ```csharp
@@ -82,17 +82,17 @@ public class EventBroker
     }
 }
 ```
-In the above snippet, the `TargetServerType` can be either `Remote` or `Local` as mandatory options but the engineers developing the library may add other options if they so choose.
+In the above snippet, the `TargetServerType` can be either `Remote` or `Local` as mandatory options, but the engineers developing the library may add other options if they so choose.
 
-Abstract provider libraries must mimic the exact same behavior of their providers. For instance, in a queue-listening scenario, these libraries must expose an API that supports eventing for incoming messages even if these messages were local not from any external service such as the cloud.
+Abstract provider libraries must mimic the exact behavior of their providers. For instance, in a queue-listening scenario, these libraries must expose an API that supports eventing for incoming messages, even if they are local and not from an external service such as the cloud.
 
-It is also acceptable to have the option to support local intranet networks and governed networks that are not connected to the public internet in certain scenarios using these very same libraries.
+It is also acceptable to have the option to support local intranet networks and governed networks that are not connected to the public internet in specific scenarios using these very same libraries.
 
-Standardized provider abstraction libraries are sub-systems that are also required to have their own Brokers, Services and Exposure layers according to The Standard. These libraries will further simplify the development of customer-facing systems with well-defined exceptions to handle, expectations and also simpler modifications since they are open-source and Standard-Compliant.
+Standardized provider abstraction libraries are subsystems that must have their own Brokers, Services, and Exposure layers according to The Standard. These libraries will further simplify the development of customer-facing systems with well-defined exceptions to handle expectations and simpler modifications since they are open-source and Standard-Compliant.
 
 ## 1.8.3 Local to Global
-Engineers may develop their own local provider abstraction libraries in the same solution assuming that they couldn't find an existing effort to support their needs. By doing so, these engineers are encouraged to open-source and publish that abstraction project to support other engineers in The Standard Community who may have the same needs.
+Engineers may develop their local provider abstraction libraries using the same solution, assuming they need help finding an existing effort to support their needs. By doing so, these engineers are encouraged to open-source and publish that abstraction project to support other engineers in The Standard Community who may have the exact needs.
 
-This practice encourages engineers everywhere to create collective effort and hive-mind pattern to solve a problem once and share it with the rest of The Standard Engineering Community for further enhancement and support.
+This practice encourages engineers everywhere to create a collective effort and hive-mind patterns to solve a problem once and share it with the rest of The Standard Engineering Community for further enhancement and support.
 
-Standard-Compliant edge (customer-facing) systems should no longer add any libraries that are not Standard-Compliant to their APIs, Desktop or Web Applications or any other systems. 
+Standard-compliant edge (customer-facing) systems should no longer add any non-standard libraries to their APIs, Desktop or Web Applications, or any other systems.