Spring Cloud Open Service Broker is a framework for building Spring Boot applications that implement the Open Service Broker API.

Introduction

The Open Service Broker API defines an HTTP interface between the services marketplace of a platform and a service broker.

Service brokers are responsible for:

  • Advertising a catalog of their service offerings and plans

  • Provisioning (creating or updating) service instances

  • Creating bindings between a service instance and a client application

  • Deleting bindings between a service instance and a client application

  • Deprovisioning (deleting) service instances

The Spring Cloud Open Service Broker project provides the scaffolding for an Open Service Broker API-compliant service broker by implementing the required Spring web controllers, domain objects, and configuration. Service broker authors can provide Spring beans that implement the appropriate interfaces.

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 MVC. Spring WebFlux is currently not supported.

Maven dependencies

To use Spring Cloud Open Service Broker in a Spring MVC application, add the webmvc starter:

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

Gradle dependencies

To use Spring Cloud Open Service Broker in a Spring MVC application, add the webmvc starter:

dependencies {
    compile("org.springframework.cloud:spring-cloud-starter-open-service-broker-webmvc:${version}")
}

Configuring the service broker

See the Spring Boot documentation for getting started building a Spring Boot application.

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 will back away from its defaults.

To start, use the @SpringBootApplication annotation on the service broker’s main application class:

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

This will trigger the inclusion of the default configuration.

Advertising Services

The service broker catalog provides a set of metadata that describes the available services along with attributes such as cost and capabilities. The catalog is made available to the platform’s services marketplace through the service broker /v2/catalog endpoint.

The service broker can either provide a Spring bean of type Catalog or implement the service CatalogService.

Providing a Catalog Bean

The service broker catalog can be exposed by creating a Spring bean and contribute it to the Spring application context. This can be done in a Spring @Configuration class as in this example:

package com.example.servicebroker;

import org.springframework.cloud.servicebroker.model.catalog.Catalog;
import org.springframework.cloud.servicebroker.model.catalog.Plan;
import org.springframework.cloud.servicebroker.model.catalog.ServiceDefinition;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class ExampleCatalogConfiguration {

	@Bean
	public Catalog catalog() {
		Plan plan = Plan.builder()
				.id("simple-plan")
				.name("standard")
				.description("A simple plan")
				.free(true)
				.build();

		ServiceDefinition serviceDefinition = ServiceDefinition.builder()
				.id("example-service")
				.name("example")
				.description("A simple example")
				.bindable(true)
				.tags("example", "tags")
				.plans(plan)
				.build();

		return Catalog.builder()
		  .serviceDefinitions(serviceDefinition)
		  .build();
	}
}

Providing a Catalog Using Properties

A catalog may be configured with Spring Boot externalized configuration within a Java properties file or YAML file. The catalog is parsed and made available as a Catalog bean during autoconfiguration.

The following example shows a YAML file that configures a catalog:

# Example Spring Boot YAML configuration
spring:
  cloud:
    openservicebroker:
      catalog:
        services:
        - id: example-service
          name: example
          description: A simple example
          bindable: true
          tags:
          - example
          - tags
          plans:
          - id: simple-plan
            name: standard
            description: A simple plan

The following example shows a properties file that configures a catalog:

# Example Spring Boot properties configuration
spring.cloud.openservicebroker.catalog.services[0].id=example-service
spring.cloud.openservicebroker.catalog.services[0].name=example
spring.cloud.openservicebroker.catalog.services[0].description=A simple example
spring.cloud.openservicebroker.catalog.services[0].bindable=true
spring.cloud.openservicebroker.catalog.services[0].tags[0]=example
spring.cloud.openservicebroker.catalog.services[0].tags[1]=tags
spring.cloud.openservicebroker.catalog.services[0].plans[0].id=simple-plan
spring.cloud.openservicebroker.catalog.services[0].plans[0].name=standard
spring.cloud.openservicebroker.catalog.services[0].plans[0].description=A simple plan

Implementing a Catalog Service

A service broker can take more control over the catalog by implementing the CatalogService interface. This might be required if some details of the catalog metadata need to be read from the environment or from an external data source.

The following example shows an implementation of the CatalogService interface:

package com.example.servicebroker;

import org.springframework.cloud.servicebroker.model.catalog.Catalog;
import org.springframework.cloud.servicebroker.model.catalog.Plan;
import org.springframework.cloud.servicebroker.model.catalog.ServiceDefinition;
import org.springframework.cloud.servicebroker.service.CatalogService;
import org.springframework.stereotype.Service;

@Service
public class ExampleCatalogService implements CatalogService {

	@Override
	public Catalog getCatalog() {
		return Catalog.builder()
		  .serviceDefinitions(getServiceDefinition("example-service"))
		  .build();
	}

	@Override
	public ServiceDefinition getServiceDefinition(String serviceId) {
		return ServiceDefinition.builder()
			.id(serviceId)
			.name("example")
			.description("A simple example")
			.bindable(true)
			.tags("example", "tags")
			.plans(getPlan())
			.build();
	}

	private Plan getPlan() {
		return Plan.builder()
		   .id("simple-plan")
		   .name("standard")
		   .description("A simple plan")
		   .free(true)
		   .build();
	}
}

Service Instances

Service brokers are responsible for provisioning the services advertised in their catalog and managing their lifecycle in the underlying cloud platform. The services created by the broker are referred to as service instances.

Service brokers must implement the ServiceInstanceService interface and provide implementations of the required methods of that interface. Each method receives a single Java object parameter containing all details of the request from the platform and returns a Java object value providing details of the operation to the platform.

The service instance create, update, and delete operations can be performed synchronously or asynchronously.

  • When a service broker creates, updates, or deletes a service instance synchronously, the appropriate interface method should block and only return a response to the platform when the operation completes successfully or when a failure occurs.

  • When performing an operation asynchronously, the service broker can return a response to the platform before the operation is complete and indicate in the response that the operation is in progress. The platform polls the service broker to get the status of the operation when an asynchronous operation is indicated.

Service Instance Creation

The service broker must provide an implementation of the createServiceInstance().

Service brokers typically provision a resource in the platform or in another system when creating a service instance. Service brokers are responsible for keeping track of any resources associated with a service instance for future retrieval, updating, or deletion.

Service Instance Updating

If the plan_updateable field is set to true in the services catalog, the service broker must provide an implementation of the updateServiceInstance(). Otherwise, this method is never called by the platform, and the default implementation in the interface can be used.

Services brokers can modify the configuration of an existing resource when updating a service instance or deploying a new resource.

Service Instance Deletion

An implementation of the deleteServiceInstance() method must be provided by the service broker.

Any resources provisioned in the create operation should be deprovisioned by the delete operation.

Service Instance Operation Status Retrieval

If any create, update, or delete operation can return an asynchronous “operation in progress” response to the platform, the service broker must provide an implementation of the getLastOperation(). Otherwise, this method is never called by the platform, and the default implementation in the interface can be used.

The platform polls this method of the service broker for a service instance that has an asynchronous operation in progress until the service broker indicates that the operation has completed successfully or a failure has occurred.

Service Instance Retrieval

If the instances_retrievable field is set to true in the services catalog, the service broker must provide an implementation of the getServiceInstance(). Otherwise, this method is never called by the platform, and the default implementation in the interface can be used.

Service brokers are responsible for maintaining any service instance state necessary to support the retrieval operation.

Example Implementation

The following example shows a service instance implementation:

package com.example.servicebroker;

import org.springframework.cloud.servicebroker.model.instance.CreateServiceInstanceRequest;
import org.springframework.cloud.servicebroker.model.instance.CreateServiceInstanceResponse;
import org.springframework.cloud.servicebroker.model.instance.DeleteServiceInstanceRequest;
import org.springframework.cloud.servicebroker.model.instance.DeleteServiceInstanceResponse;
import org.springframework.cloud.servicebroker.model.instance.GetLastServiceOperationRequest;
import org.springframework.cloud.servicebroker.model.instance.GetLastServiceOperationResponse;
import org.springframework.cloud.servicebroker.model.instance.GetServiceInstanceRequest;
import org.springframework.cloud.servicebroker.model.instance.GetServiceInstanceResponse;
import org.springframework.cloud.servicebroker.model.instance.OperationState;
import org.springframework.cloud.servicebroker.model.instance.UpdateServiceInstanceRequest;
import org.springframework.cloud.servicebroker.model.instance.UpdateServiceInstanceResponse;
import org.springframework.cloud.servicebroker.service.ServiceInstanceService;
import org.springframework.stereotype.Service;

import java.util.Map;

@Service
public class ExampleServiceInstanceService implements ServiceInstanceService {

	@Override
	public CreateServiceInstanceResponse createServiceInstance(CreateServiceInstanceRequest request) {
		String serviceInstanceId = request.getServiceInstanceId();
		String planId = request.getPlanId();
		Map<String, Object> parameters = request.getParameters();

		//
		// perform the steps necessary to initiate the asynchronous
		// provisioning of all necessary resources
		//

		String dashboardUrl = new String(/* construct a dashboard URL */);

		return CreateServiceInstanceResponse.builder()
				.dashboardUrl(dashboardUrl)
				.async(true)
				.build();
	}

	@Override
	public UpdateServiceInstanceResponse updateServiceInstance(UpdateServiceInstanceRequest request) {
		String serviceInstanceId = request.getServiceInstanceId();
		String planId = request.getPlanId();
		String previousPlan = request.getPreviousValues().getPlanId();
		Map<String, Object> parameters = request.getParameters();

		//
		// perform the steps necessary to initiate the asynchronous
		// updating of all necessary resources
		//

		return UpdateServiceInstanceResponse.builder()
				.async(true)
				.build();
	}

	@Override
	public DeleteServiceInstanceResponse deleteServiceInstance(DeleteServiceInstanceRequest request) {
		String serviceInstanceId = request.getServiceInstanceId();
		String planId = request.getPlanId();

		//
		// perform the steps necessary to initiate the asynchronous
		// deletion of all provisioned resources
		//

		return DeleteServiceInstanceResponse.builder()
				.async(true)
				.build();
	}

	@Override
	public GetServiceInstanceResponse getServiceInstance(GetServiceInstanceRequest request) {
		String serviceInstanceId = request.getServiceInstanceId();

		//
		// retrieve the details of the specified service instance
		//

		String dashboardUrl = new String(/* retrieve dashboard URL */);

		return GetServiceInstanceResponse.builder()
				.dashboardUrl(dashboardUrl)
				.build();
	}

	@Override
	public GetLastServiceOperationResponse getLastOperation(GetLastServiceOperationRequest request) {
		String serviceInstanceId = request.getServiceInstanceId();

		//
		// determine the status of the operation in progress
		//

		OperationState state = OperationState.SUCCEEDED;

		return GetLastServiceOperationResponse.builder()
				.operationState(state)
				.build();
	}
}

Service Bindings

Service brokers can provide information to a consumer of a service instance through a service binding. Service bindings are often used to expose credentials for service instance resources to an application.

If the bindable field is set to true for any plan in the service catalog, the service broker must provide an implementation of the ServiceInstanceBindingService interface. Otherwise, the binding methods of the service broker are not called by the platform, and a default implementation of this interface can be used. Each method receives a single Java object parameter that contains all details of the request from the platform and returns a Java object value that provides details of the operation to the platform.

Service Binding Creation

The service broker must provide an implementation of the createServiceInstanceBinding().

Two types of bindings are supported:

  • App bindings can be used to provide credentials, log drains, and volume services to applications.

  • Route bindings can be used to provide routes for the platform to use when proxying requests.

The response from this method lets one of two Java object types be returned, reflecting the two types of supported bindings.

Service brokers can generate one set of credentials for all binding requests or provide unique credentials for each binding request.

Service Binding Deletion

The service broker must provide an implementation of the deleteServiceInstanceBinding().

Any credentials provisioned in the create operation should be deprovisioned by the delete operation.

Service Binding Retrieval

If the bindings_retrievable field is set to true in the services catalog, the service catalog must provide an implementation of the getServiceInstanceBinding(). Otherwise, this method is never called by the platform, and the default implementation in the interface can be used.

Service brokers are responsible for maintaining any service binding state necessary to support the retrieval operation.

Example Implementation

The following example shows an implementation of a service binding:

package com.example.servicebroker;

import org.springframework.cloud.servicebroker.model.binding.CreateServiceInstanceAppBindingResponse;
import org.springframework.cloud.servicebroker.model.binding.CreateServiceInstanceBindingRequest;
import org.springframework.cloud.servicebroker.model.binding.CreateServiceInstanceBindingResponse;
import org.springframework.cloud.servicebroker.model.binding.DeleteServiceInstanceBindingRequest;
import org.springframework.cloud.servicebroker.model.binding.DeleteServiceInstanceBindingResponse;
import org.springframework.cloud.servicebroker.model.binding.GetServiceInstanceAppBindingResponse;
import org.springframework.cloud.servicebroker.model.binding.GetServiceInstanceBindingRequest;
import org.springframework.cloud.servicebroker.model.binding.GetServiceInstanceBindingResponse;
import org.springframework.cloud.servicebroker.service.ServiceInstanceBindingService;
import org.springframework.stereotype.Service;

@Service
public class ExampleServiceBindingService implements ServiceInstanceBindingService {

	@Override
	public CreateServiceInstanceBindingResponse createServiceInstanceBinding(CreateServiceInstanceBindingRequest request) {
		String serviceInstanceId = request.getServiceInstanceId();
		String bindingId = request.getBindingId();

		//
		// create credentials and store for later retrieval
		//

		String url = new String(/* build a URL to access the service instance */);
		String bindingUsername = new String(/* create a user */);
		String bindingPassword = new String(/* create a password */);

		return CreateServiceInstanceAppBindingResponse.builder()
				.credentials("url", url)
				.credentials("username", bindingUsername)
				.credentials("password", bindingPassword)
				.bindingExisted(false)
				.async(true)
				.build();
	}

	@Override
	public DeleteServiceInstanceBindingResponse deleteServiceInstanceBinding(DeleteServiceInstanceBindingRequest request) {
		String serviceInstanceId = request.getServiceInstanceId();
		String bindingId = request.getBindingId();

		//
		// delete any binding-specific credentials
		//

		return DeleteServiceInstanceBindingResponse.builder()
				.async(true)
				.build();
	}

	@Override
	public GetServiceInstanceBindingResponse getServiceInstanceBinding(GetServiceInstanceBindingRequest request) {
		String serviceInstanceId = request.getServiceInstanceId();
		String bindingId = request.getBindingId();

		//
		// retrieve the details of the specified service binding
		//

		String url = new String(/* retrieved URL */);
		String bindingUsername = new String(/* retrieved user */);
		String bindingPassword = new String(/* retrieved password */);

		return GetServiceInstanceAppBindingResponse.builder()
				.credentials("username", bindingUsername)
				.credentials("password", bindingPassword)
				.credentials("url", url)
				.build();
	}
}

API version verification

Platforms are required to provide an HTTP header in each call to the Open Service Broker API, indicating the version of the API specification that the platform supports. Spring Cloud Open Service Broker can be configured to verify the version provided by the platform on each call to the service broker. This version verification is configured to allow any API version by default.

To customize the version verification, set the apiVersion property that specifies the API version required by the service broker, as follows:

spring.cloud.openservicebroker.apiVersion=2.13

Alternatively, provide a BrokerApiVersion Spring bean, as in this example:

package com.example.servicebroker;

import org.springframework.cloud.servicebroker.model.BrokerApiVersion;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class ExampleApiVersionConfiguration {
	@Bean
	public BrokerApiVersion brokerApiVersion() {
		return new BrokerApiVersion("2.13");
	}
}

In the case of both a Spring Bean and a property being configured, then the Spring Bean will take precedence over the property.

If an API version is specified and the platform provides a different version in the X-Broker-API-Version header, the framework will return a 412 Precondition Failed error to the platform.

Service Broker Security

Authentication and authorization of service broker endpoints is not specified in the Open Service Broker API specification, but some platforms require or let basic authentication or OAuth2 credentials be provided when a service broker is registered to the platform.

The Spring Cloud Open Service Broker project does not implement any security configuration. Service broker application endpoints can be secured with Spring Security and Spring Boot security configuration by applying security to application endpoints with the path-matching pattern: /v2/**.

Example Configuration

The following examps shows a security configuration implementation:

package com.example.servicebroker;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;
import org.springframework.security.core.userdetails.User;
import org.springframework.security.core.userdetails.UserDetails;
import org.springframework.security.provisioning.InMemoryUserDetailsManager;

@Configuration
@EnableWebSecurity
public class ExampleSecurityConfig extends WebSecurityConfigurerAdapter {

	@Override
	protected void configure(HttpSecurity http) throws Exception {
		http
				.authorizeRequests()
				.antMatchers("/v2/**").hasRole("ADMIN")
				.and()
				.httpBasic();
	}

	@Bean
	public InMemoryUserDetailsManager userDetailsService() {
		return new InMemoryUserDetailsManager(adminUser());
	}

	private UserDetails adminUser() {
		return User
				.withUsername("admin")
				.password("supersecret")
				.roles("ADMIN")
				.build();
	}
}

Example Service Broker Application

The Bookstore Service Broker project implements a simple service broker that adheres to the Open Service Broker API by using the Spring Cloud Open Service Broker framework. It can be deployed to either Cloud Foundry or Kubernetes and can be registered as a service broker to either platform. View the project README for more information.