Re: How stateless are service brokers?

Matt McNeeney

Thanks for the feedback all. It sounds like there are a mix of brokers out
- some are totally stateless
- some manage their own state
- some can rely on other components (like BOSH) or things like names and
tags to hold state

Knowing this, I will try to ensure to ensure than the Open Service Broker
API specification continues to support all of these setups and that any new
features that require state will be optional for brokers to support.

Best wishes,

On Fri, 20 Oct 2017 at 11:22, Sascha Matzke <sascha.matzke(a)>


we have several internally used brokers.

While we try to avoid keeping state in the broker (by encoding the state
in backend instances names, tags or everything else that can hold
information and allows to query it), we couldn't avoid in all cases.

So yes, our brokers partially keep state and most of them also support
async operations (but that's not directly coupled to whether or not they
keep state).



On Thu, Oct 19, 2017 at 2:58 PM, Matt McNeeney <mmcneeney(a)>

Hi all,

Members of the Open Service Broker API
<> group are currently asking about *how
stateless service brokers really are*. There are features in the spec (
<> instance
provisioning) and features that we want to get into the spec (allowing
platforms to GET
<> instances
and bindings) that we believe require some degree of statefulness, and so
we want to understand this space better before making these changes.

I'm keen to understand from Service Broker authors whether or not the
service brokers you have created keep any state (either on their own or by
relying on other platform components), and if not, whether or not you
currently support or plan to support asynchronous operations (provisioning
and binding)?

Many thanks,
*CF Services API PM*

Through the darkness of future past
the magician longs to see
One chants out between two worlds
*Fire walk with me*.

Join to automatically receive all group messages.