Yesterday we were referring to the design of Kubernetes Service brokers. Today we look at the implementation for one of them.
A typical service broker will implement the ServiceInstanceService and ServiceInstanceBindingService Methods that correspond to the ServiceInstance and ServiceBinding definititons in the Kubernetes framework.
The ServiceInstanceService implementation will determine
1) whether to accept a given service instance request for create, update, delete, get or list operations.
2) The classes are separate for each resource they represent.
3) They are composed under a composite service that represents a facade to the composite OSBA service. The OSBA service therefore allows service oriented architecture for the implementations of the service broker.
4) The service is looked up by the service broker with a match to the service definition in the request. The method accepting the request in the composite service implementation can determine if it should handle the request.
5) validations for accepting requests are performed by the service broker.
6) when a service instance is created, it tries to populate the resource representation and persist the resource. Sometimes persisting the resource to be created or updated requires interacting with other services. These may need to be done in a transaction scope and support good exception handling, diagnosability and transparency.
A service instance binding is looked up for a service instance with the help of the following supported lookup techniques:
ClusterServiceClassExternalName and ClusterServicePlanExternalName
ClusterServiceClassExternalID and ClusterServicePlanExternalID
ClusterServiceClassName and ClusterServicePlanName
ServiceClassExternalName and ServicePlanExternalName
ServiceClassExternalID and ServicePlanExternalID
ServiceClassName and ServicePlanName
A typical service broker will implement the ServiceInstanceService and ServiceInstanceBindingService Methods that correspond to the ServiceInstance and ServiceBinding definititons in the Kubernetes framework.
The ServiceInstanceService implementation will determine
1) whether to accept a given service instance request for create, update, delete, get or list operations.
2) The classes are separate for each resource they represent.
3) They are composed under a composite service that represents a facade to the composite OSBA service. The OSBA service therefore allows service oriented architecture for the implementations of the service broker.
4) The service is looked up by the service broker with a match to the service definition in the request. The method accepting the request in the composite service implementation can determine if it should handle the request.
5) validations for accepting requests are performed by the service broker.
6) when a service instance is created, it tries to populate the resource representation and persist the resource. Sometimes persisting the resource to be created or updated requires interacting with other services. These may need to be done in a transaction scope and support good exception handling, diagnosability and transparency.
A service instance binding is looked up for a service instance with the help of the following supported lookup techniques:
ClusterServiceClassExternalName and ClusterServicePlanExternalName
ClusterServiceClassExternalID and ClusterServicePlanExternalID
ClusterServiceClassName and ClusterServicePlanName
ServiceClassExternalName and ServicePlanExternalName
ServiceClassExternalID and ServicePlanExternalID
ServiceClassName and ServicePlanName
No comments:
Post a Comment