2. Getting started

Most service broker applications implement API or web UI endpoints beyond the Open Service Broker API endpoints. These additional endpoints might provide information about the application, provide a dashboard UI, or provide controls over application behavior. Developers may implement these additional endpoints with Spring WebFlux or Spring MVC.spring-doc.cn

While spring-cloud-open-service-broker uses reactive return types in its API, both blocking web stack (such as tomcat/jetty using spring-boot-starter-web) or non blocking web stack (such as netty/undertow using spring-boot-starter-webflux) are supported. See respective acceptance tests in modules spring-cloud-open-service-broker-acceptance-webmvc and spring-cloud-open-service-broker-acceptance-webflux.spring-doc.cn

The Spring Cloud Open Service Broker starter does not include a transitive dependency on Spring WebFlux or Spring MVC. A Spring Boot web starter is required to activate the auto-configuration.

2.1. Maven Dependencies

To use Spring Cloud Open Service Broker in a Spring web application, add the starter, as follows:spring-doc.cn

    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-open-service-broker</artifactId>
            <version>${version}</version>
        </dependency>
    </dependencies>

2.2. Gradle Dependencies

To use Spring Cloud Open Service Broker in a Spring web application, add the starter, as follows:spring-doc.cn

    dependencies {
        api 'org.springframework.cloud:spring-cloud-starter-open-service-broker:${version}'
    }

2.3. Configuring the Service Broker

See the Spring Boot documentation to get started building a Spring Boot application.spring-doc.cn

The framework provides default implementations of most of the components needed to implement a service broker. In Spring Boot fashion, you can override the default behavior by providing your own implementation of Spring beans, and the framework backs away from its defaults.spring-doc.cn

To start, use the @SpringBootApplication annotation on the service broker’s main application class, as follows:spring-doc.cn

    @SpringBootApplication
    public class Application {
        public static void main(String[] args) {
            SpringApplication.run(Application.class, args);
        }
    }

This triggers the inclusion of the default configuration.spring-doc.cn

2.4. Using a Unique Platform ID

Every request to the service broker is able to receive a platformInstanceId through a path variable. This lets a service broker detect the identity of a platform to which it has been registered, as described in the Cloud Foundry documentation.spring-doc.cn

For example, an operator may register a service broker to one CF platform instance, as follows:spring-doc.cn

$ cf create-service-broker mybroker username password https://mybroker.app.local/east

The operator may also register the same service broker to another CF platform instance, as follows:spring-doc.cn

$ cf create-service-broker mybroker username password https://mybroker.app.local/west

The broker could then expect requests to the following paths, where the platformInstanceId field in the request object contains the value "east" or "west":spring-doc.cn

- https://username:[email protected]/east/v2/catalog
- https://username:[email protected]/west/v2/catalog

2.5. Customizing the Service Broker Path

Sometimes, it is useful to customize the prefix for the service broker path. For example, your application might be serving conflicting endpoints for another purpose. You can use the spring.cloud.openservicebroker.base-path property to change the prefix for your broker path, as follows:spring-doc.cn

spring.cloud.openservicebroker.base-path=/broker

The preceding application.properties example changes the endpoint from / to /broker/ (for example, /broker/v2/catalog).spring-doc.cn