anchor.diff:  **Advantages:**
   
   - Adding route services requires no manual infrastructure configuration.
  -- Traffic to apps that do not use the service makes fewer network hops because requests for those apps do not pass through the route service.
  +- Traffic to apps that do not use the service makes fewer network hops
  +  because requests for those apps do not pass through the route
  +  service.
   
   **Disadvantages:**
   
  -- Developers must manually provision and configure route services out of the context of <%= vars.app_runtime_abbr %> because no service broker automates these operations.
  -- Traffic to apps that use the route service makes additional network hops, as compared to the static model.
  +- Developers must manually provision and configure route services out
  +  of the context of <%= vars.app_runtime_abbr %> because no service
  +  broker automates these operations.
  +- Traffic to apps that use the route service makes additional network
  +  hops, as compared to the static model.
   
   ### <a name="architecture-comparison"></a> Architecture Comparison
   
  -The models above require the broker and service instance responsibilities summarized in the following table:
  +The models above require the broker and service instance
  +responsibilities summarized in the following table:
   
   <table id='architecture-comparison' border="1" class="nice" >
     <tr>
  
positive.code:     cf logs logger
      ```
  
  1. Send a request to the sample app and view in the route service logs that the request is forwarded to it by running:
  
      ```
      curl spring-music.cf.example.com
  
negative.code:     </ul>
  </div>
  
  This topic provides guidance for offering a service to a <%=
  vars.app_runtime_full %> (<%= vars.app_runtime_abbr %>) services
  marketplace. For information about consuming these services, see
  [Manage App Requests with Route
  Services](../devguide/services/route-binding.html).
  
  <%= vars.route_services %>
  
  
  ## <a name='introduction'></a> Introduction
  
  <%= vars.app_runtime_abbr %> app developers may wish to apply
  transformation or processing to requests before they reach an
  app. Common examples of use cases include authentication, rate
  limiting, and caching services. Route services are a kind of
  Marketplace service that developers can use to apply various
  transformations to app requests by binding an app's route to a service
  instance. Through integrations with service brokers and, optionally,
  with the <%= vars.app_runtime_abbr %> routing tier, providers can
  offer these services to developers with a familiar, automated,
  self-service, and on-demand user experience.
  
  <%= vars.route_services_appsman1 %>
  
  
  ## <a name='architecture'></a> Architecture
  
  <%= vars.app_runtime_abbr %> supports the following three models for
  route services:
  
  * [Fully-brokered services](#fully-brokered)
  * [Static, brokered services](#static-brokered)
  * [User-provided services](#user-provided)
  
  In each model, you configure a route service to process traffic
  addressed to an app.
  
  ### <a name="fully-brokered"></a> Fully-Brokered Service
  
  In the fully-brokered service model, the <%= vars.app_runtime_abbr %>
  router receives all traffic to apps in the deployment before any
  processing by the route service. Developers can bind a route service
  to any app, and if an app is bound to a route service, the <%=
  vars.app_runtime_abbr %> router sends its traffic to the
  service. After the route service processes requests, it sends them
  back to the load balancer in front of the <%= vars.app_runtime_abbr %>
  router. The second time through, the <%= vars.app_runtime_abbr %>
  router recognizes that the route service has already handled them, and
  forwards them directly to app instances.
  
  ![Fully brokered](images/route-services-fully-brokered.png)
  
  The route service can run inside or outside of <%=
  vars.app_runtime_abbr %>, so long as it fulfills the [Service Instance
  Responsibilities](#service-instance-responsibilities) to integrate it
  with the <%= vars.app_runtime_abbr %> router. A service broker
  publishes the route service to the <%= vars.app_runtime_abbr %>
  marketplace, making it available to developers. Developers can then
  create an instance of the service and bind it to their apps with the
  following commands:
  
  `cf create-service BROKER-SERVICE-PLAN SERVICE-INSTANCE`
  `cf bind-route-service YOUR-APP-DOMAIN SERVICE-INSTANCE [--hostname HOSTNAME] [--path PATH]`
  
  Developers configure the service either through the service provider's
  web interface or by passing [arbitrary
  parameters](../devguide/services/managing-services.html#arbitrary-params-create)
  to their `cf create-service` call through the `-c` flag.
  
  **Advantages:**
  
  - Developers can use a Service Broker to dynamically configure how the
    route service processes traffic to specific apps.
  - Adding route services requires no manual infrastructure
    configuration.
  - Traffic to apps that do not use the service makes fewer network hops
    because requests for those apps do not pass through the route
    service.
  
  **Disadvantages:**
  
  - Traffic to apps that use the route service makes additional network
    hops, as compared to the static model.
  
  ### <a name="static-brokered"></a> Static, Brokered Service
  
  In the static, brokered service model, an operator installs a static
  routing service, which might be a piece of hardware, in front of the
  load balancer. The routing service runs outside of <%=
  vars.app_runtime_abbr %> and receives traffic to all apps running in
  the <%= vars.app_runtime_abbr %> deployment. The service provider
  creates a service broker to publish the service to the <%=
  vars.app_runtime_abbr %> marketplace. As with a fully-brokered
  service, a developer can use the service by instantiating it with `cf
  create-service` and binding it to an app with `cf bind-route-service`.
  
  ![Static, brokered](images/route-services-static-brokered.png)
  
  In this model, you configure route services on an app-by-app
  basis. When you bind a service to an app, the service broker directs
  the routing service to process that app's traffic rather than pass the
  requests through unchanged.
  
  **Advantages:**
  
  - Developers can use a service broker to dynamically configure how the
    route service processes traffic to specific apps.
  - Traffic to apps that use the route service takes fewer network hops.
  
  **Disadvantages:**
  
  - Adding route services requires manual infrastructure configuration.
  - Traffic to apps that do not use the route service make unnecessary
    network hops. Requests for all apps hosted by the deployment pass
    through the route service component.
  
  ### <a name="user-provided"></a> User-Provided Service
  
  If a route service is not listed in the <%= vars.app_runtime_abbr %>
  marketplace by a broker, a developer can still bind it to their app as
  a user-provided service. The service can run anywhere, either inside
  or outside of <%= vars.app_runtime_abbr %>, but it must fulfill the
  integration requirements described in [Service Instance
  Responsibilities](#service-instance-responsibilities). The service
  also needs to be reachable by an outbound connection from the <%=
  vars.app_runtime_abbr %> router.
  
  ![User-provided](images/route-services-user-provided.png)
  
  This model is identical to the fully-brokered service model, except
  without the broker. Developers configure the service manually, outside
  of <%= vars.app_runtime_abbr %>. They can then create a user-provided
  service instance and bind it to their app with the following commands,
  supplying the URL of their route service:
  
  `cf create-user-provided-service SERVICE-INSTANCE -r ROUTE-SERVICE-URL`
  `cf bind-route-service DOMAIN SERVICE-INSTANCE [--hostname HOSTNAME]`
  