Question: is there doc howto provision and bind resources via web api (e.g java client)

[cforce]

The application which need to (de)provision/(un)bind runs in same aks as the installed OSB

[zhongyi-zhang]

This question should go to service catalog. AFAIK, it doesn't have a java client maintained by the community but only a go client which the svcat CLI uses.

[krancour]

is there doc howto provision and bind resources via web api

The Open Service Broker API on which this broker is based is exhaustively documented by the OSB API project.

This question should go to service catalog.

It sounds like the question is about how to talk to the broker directly without Service Catalog or CF as a middle man.

[cforce]

The use case is a application which needs to setup event broker instances dynamically, based on subscription requests of at runtime registering consumer.
The application is written in spring boot. Currently we use activemq which supports virtual queue's and now want to replace it with event hub when moving to Azure but lack the feature for support of at runtime addable queue's with dedicated topic. Using the osb api to deploy an evhub instance on subscription registration from within the application dynamically was an idea.

[krancour]

I'm not sure I followed all of that. It sounds a touch complicated. I will say this... brokers aren't generally meant for applications to speak to directly to dynamically provision resources on-demand at runtime. The intended use was statically satisfying an application's known/discrete set of service dependencies at the time the application itself is also provisioned.

If your application needs to dynamically create (and presumably also delete) resources in Azure at runtime, it would be much simpler to not involve the broker in that. The Azure APIs are excellent and so are the language bindings such as those for Java. I think you would find this much simpler.

[cforce]

"The Azure APIs are excellent and so are the language bindings such as those for Java."
Which API exactly does allow me that. Can't find that for now.

And if this API at the end is the same as OSB itself is using, why not do it via the cloud native OSB API abstraction brokering inside my cluster ? If i call the APi via svcat or directly from another app, where is the difference? Why shall we not generally use Azure APIS directly and even OSB for anything .

[zhongyi-zhang]

Please refer to https://docs.microsoft.com/en-us/rest/api/azure/. It bases on swagger.

[krancour]

If i call the APi via svcat or directly from another app, where is the difference? Why shall we not generally use Azure APIS directly and even OSB for anything .

Let's talk about Kubernetes Service Catalog first. This was developed by the Kubernetes community and makes it possible for your Kubernetes manifests (or Helm charts or whatever) to spell out your application's dependencies declaratively at the time the application is deployed and have the provisioning of those dependencies automatically fulfilled by some broker. OSBA isn't the only broker. There are many. OSBA is an Azure-specific broker. Naturally, you can imagine that it is very important for Service Catalog and all the brokers in the the "broker ecosystem" to all "speak the same language." That is where the OSB API comes into play. It is the common language.

With all of the context above, you can then start to think of OSBA as a sort of adapter that makes Azure's existing APIs compatible with Kubernetes Service Catalog (and Cloud Foundry too).

The scenario you have described doesn't align with this well. You aren't looking to declare dependencies at the time your application is deployed. You are looking to programmatically provision things dynamically at runtime. The question becomes one of "what is the easiest way to accomplish this?"

Choice no. 1 is the one you've been asking about: Writing really low level code to make HTTP calls to OSBA to interact with it RESTfully. But recall that OSBA itself is an adapter of sorts-- and it is one you do not need. Because choice no. 2 is to use a Java SDK that already works seamlessly with Azure-- i.e. the Azure SDK for Java. You will find this much simpler than the first option.