anchor.diff:  
   == Overview
   
  -Many OpenShift applications use external resources (external databases, external SaaS endpoints,
  -etc).  These external resources are simple to model as native OpenShift services so that 
  +Many OpenShift applications use external resources, such as external databases, or an external
  +SaaS endpoint. These external resources can be modeled as native OpenShift services, so that
   applications can work with them as they would any other internal service.
   
   == Example: External SaaS Provider
   
  -One of the most common types of external services is an external SaaS endpoint.  As an example,
  -assume that you want to use a SaaS provider for which an application needs:
  +One of the most common types of external services is an external SaaS endpoint. As an example,
  +assume that you want to use a SaaS provider for an application. This requires:
   
   1. An endpoint to communicate with
  -2. A set of credentials:
  +2. A set of credentials, such as:
      a.  An API key
      b.  A username
      c.  A passphrase
   
  -The formula for integrating with this type of external resource is fairly simple.  The pieces of
  -the solution are:
  +////
  +The formula for integrating with this type of external resource is fairly simple. The pieces of the
  +solution are:
   
   1.  A `Service` object to represent the SaaS provider as an OpenShift service
   2.  One or more `Endpoints` for the service
   3.  Environment variables in the appropriate pods that contain the credentials
  +////
   
  -=== Creating the service
  +The following sections outline a scenario for intergrating with an external SaaS provider:
   
  -The first step in integrating with an external service is to create an OpenShift service to
  -represent it.  This is very similar to creating an internal service; the difference is in the
  -service's `Selector` field.
  +=== Create the service
   
  -Internal OpenShift services use the `Selector` field to associate pods with services
  -via labels.  A system component called `EndpointsController` synchronizes the endpoints for
  -services that specify selectors with the pods that match the selector.  The service proxy and
  -OpenShift router load-balance requests to the service amongst the service's endpoints.
  +The first step in integrating with an external service is to create an OpenShift service to represent
  +it. This is similar to creating an internal service; however the difference is in the service's `Selector` field.
   
  -The only difference between an internal OpenShift service and a service that represents an external
  -resource is that there are no pods to associate an external service with.  To represent external
  -services, we just need to leave the `Selector` field unset.  This will make the `EndpointsController`
  -ignore the service and allow you to specify endpoints manually:
  +Internal OpenShift services use the `Selector` field to associate pods with services using labels. A
  +system component called `EndpointsController` synchronizes the endpoints for services that specify selectors
  +with the pods that match the selector. The service proxy and OpenShift router load-balance requests to the service
  +amongst the service's endpoints.
  +
  +The only difference between an internal OpenShift service and a service that represents an external resource
  +is that there are no pods to associate an external service with. To represent external services, leave the `Selector`
  +field unset. This makes the `EndpointsController` ignore the service and allows you to specify endpoints manually:
  +
  +====
   
   ----
   {
  
positive.code:                 ],
                  env: [
                	  {
                	    "name": "SAAS_API_KEY"
                	    "value": "<SaaS service API key>"
                	  },
                	  {
                	    "name": "SAAS_USERNAME"
                	    "value": "<SaaS service user>"
                	  },
                	  {
                	    "name": "SAAS_PASSPHRASE"
                	    "value": "<SaaS service passphrase>"
                	  },
                  ]
  
negative.code: }
  ----
  
  <1> Other fields on the `DeploymentConfig` are omitted.
  <2> `SAAS_API_KEY`: The API key to use with the service.
  <3> `SAAS_USERNAME`: The username to use with the service.
  <4> `SAAS_PASSPHRASE`: The passphrase to use with the service.
  
  ====
  
  === Using the service in your application
  
  Using an external service in your application is just like using an internal service. Your application is
  injected with environment variables for the service and the additional environment variables with the credentials
  described above. In the following example, the 'helloworld' container receives the following environment variables:
  
  ****
  EXAMPLE_EXTERNAL_SERVICE_SERVICE_HOST=[replaceable]#<IP_Address>#
  
  EXAMPLE_EXTERNAL_SERVICE_SERVICE_PORT=[replaceable]#<Port_Number>#
  
  SAAS_API_KEY=[replaceable]#<value of SaaS api key>#
  
  SAAS_USERNAME=[replaceable]#<value of SaaS username>#
  
  SAAS_PASSPHRASE=[replaceable]#<value of SaaS passphrase>#
  ****
  
  
  The application is responsible for reading the coordinates and credentials for the service from the environment
  and establishing a connection with the service.