3. 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
.
3.1. Providing a Catalog Bean
You can expose the service broker catalog by creating a Spring bean and contributing it to the Spring
application context.
You can do so in a Spring @Configuration
class, as follows:
package com.example.servicebroker;
@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();
}
}
3.2. Providing a Catalog by Using Properties
You can configure a catalog with Spring Boot externalized configuration within a Java properties file or a YAML file.
The catalog is parsed and made available as a Catalog
bean during autoconfiguration.
The following YAML file 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 properties file 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
3.3. 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 implements the CatalogService
interface:
package com.example.servicebroker;
@Service
public class ExampleCatalogService implements CatalogService {
@Override
public Mono<Catalog> getCatalog() {
return getServiceDefinition("example-service")
.map(serviceDefinition -> Catalog.builder()
.serviceDefinitions(serviceDefinition)
.build());
}
@Override
public Mono<ServiceDefinition> getServiceDefinition(String serviceId) {
return Mono.just(ServiceDefinition.builder()
.id(serviceId)
.name("example")
.description("A simple example")
.bindable(true)
.tags("example", "tags")
.plans(getPlan())
.build());
}
@Override
public Mono<ResponseEntity<Catalog>> getResponseEntityCatalog(HttpHeaders httpHeaders) {
// Use this method to handle catalog caching and ETag support.
// The example below is a basic ETag comparison and response.
if ("useful-etag-value".equals(httpHeaders.getIfNoneMatch())) {
return Mono.just(ResponseEntity
.status(304)
.eTag("useful-etag-value")
.build());
}
else {
return getCatalog()
.map(catalog -> ResponseEntity
.status(200)
.eTag("different-etag-value")
.body(catalog));
}
}
private Plan getPlan() {
return Plan.builder()
.id("simple-plan")
.name("standard")
.description("A simple plan")
.free(true)
.build();
}
}