VMware Cloud Community
panjl3
Contributor
Contributor
Jump to solution

What is ISslService and IEndpointConfigurationService?

Sorry if I post in wrong place but I don't know where is the right place to ask this  question , to admin, please feel free to move this post to right place:)


We're VMware Parter that develop plugins for vRO.Recently we received a mail from VMware saying that Compatibility Certification with vRO 7.0 is changed a bit compared with vRO 6.0, and raised the follwing questions as the required certification process in vRO 7.0:



4: Question: If your plug-in uses SSL/TLS for communicating to a certain host, is the library responsible for establishing the SSL/TLS connection using the SSLContext provided by the ISslService?

Expected answer is yes.

5: Question: If your plug-in is storing connection data for communicating with the third-party system (such as host/ip and credentials), is the plug-in using the IEndpointConfigurationService?

Expected answer is yes.

Rational for 4 and 5: SSLContext() and IEndpointConfigurationService() APIs are required to achieve cluster-aware configuration - configuring the plug-in on one node will configure the plug-in on all other nodes.


However, we'd like to ask what is ISslService and IEndpointConfigurationService?  How to implement it? What jars are they in?We googled , looked up the development guide vrealize-orchestrator-60-developers-guide.pdf(vRealize Orchestrator Plug-in SDK for vRA 7.0 - VMware Developer Center but still points to 6.0's developers guide and I can find 7.0's guide) but can not find the docs about  ISslService and IEndpointConfigurationService.

We'll appreciate if anyone can advise on the sample codes/docs/API about how to implement them. Thanks!

Tags (2)
1 Solution

Accepted Solutions
dvatov
VMware Employee
VMware Employee
Jump to solution

The purpose of ISslService is to decouple the configuration of SSLContext from the plugin's code. In versions 7.1+ the trust store is stored in the database to enable cluster scenarios and ISslService hides the complexity to retrieve the truststore. For few releases trust store will be still shadowed in jssecacerts file for backward compatibility of older plugins however at some point it will not be used as source of CAs.

Another set of method in ISslService accept as parameter keystoreId. Those keystores are also stored in the database (only there). They are managed by Configurator plugin which is shipped with vRO. Their purpose is to provide plugins the ability to create and support their own keystores. For example REST plugin can use different trust store for each remote host configured in it.

IEndpointConfigurationService provides access to the database storage for configuration data. This is done again because of the cluster rediness of the plugins.

The implementation of these interfaces is provided by vRO platform and plugins should only ask platform to provide these implementations to them. For non spring plugins your plugin adaptor class should implement interface ch.dunes.vso.sdk.IServiceRegistryAdaptor. In 'void setServiceRegistry(IServiceRegistry registry)' mehtod store reference to the registry and use it to get implementations for ISslService and IEndpointConfigurationService.

For example:

sslService = (ISslService)registry.getService(ch.dunes.vso.sdk.IServiceRegistry.SSL_SERVICE)

Attached a document with more details on services provided by IServiceRegistry. The formatting is not the best, sorry for that.

View solution in original post

3 Replies
dvatov
VMware Employee
VMware Employee
Jump to solution

The purpose of ISslService is to decouple the configuration of SSLContext from the plugin's code. In versions 7.1+ the trust store is stored in the database to enable cluster scenarios and ISslService hides the complexity to retrieve the truststore. For few releases trust store will be still shadowed in jssecacerts file for backward compatibility of older plugins however at some point it will not be used as source of CAs.

Another set of method in ISslService accept as parameter keystoreId. Those keystores are also stored in the database (only there). They are managed by Configurator plugin which is shipped with vRO. Their purpose is to provide plugins the ability to create and support their own keystores. For example REST plugin can use different trust store for each remote host configured in it.

IEndpointConfigurationService provides access to the database storage for configuration data. This is done again because of the cluster rediness of the plugins.

The implementation of these interfaces is provided by vRO platform and plugins should only ask platform to provide these implementations to them. For non spring plugins your plugin adaptor class should implement interface ch.dunes.vso.sdk.IServiceRegistryAdaptor. In 'void setServiceRegistry(IServiceRegistry registry)' mehtod store reference to the registry and use it to get implementations for ISslService and IEndpointConfigurationService.

For example:

sslService = (ISslService)registry.getService(ch.dunes.vso.sdk.IServiceRegistry.SSL_SERVICE)

Attached a document with more details on services provided by IServiceRegistry. The formatting is not the best, sorry for that.

panjl3
Contributor
Contributor
Jump to solution

Thank you dvatov!

After reading your answer and doc, I get more understanding. Thank you. Just want to confirm: is this the right way to use ISSLService:

in SomePluginAdaptor.java:

SomePluginAdaptor impements IPluginAdaptor, ch.dunes.vso.sdk.IServiceRegistryAdaptor {

public static IServiceRegistry _serviceRegistry;  // then in other class that makes SSL connection we can use sslService = (ISslService)SomePluginAdaptor._serviceRegistry.getService(ch.dunes.vso.sdk.IServiceRegistry.SSL_SERVICE) to get sslService?

@Override

public void setServiceRegistry(IServiceRegistry arg0) {

  _serviceRegistry=arg0;

}

}

Is making _serviceRegistry static the right way or acceptable way? If not, what is the best practice and how can we get SomePluginAdaptor instance and so we can use getters to get the non-static field.

Thanks!

Reply
0 Kudos
dvatov
VMware Employee
VMware Employee
Jump to solution

The only way to receive IServiceRegistry is in plugin adaptor's setServiceRegistry(). The plugin should store this for later usage. You can make it static but this relates only to the design of the plugin. I personally prefer to inject it in the plugin factory in adaptor.createPluginFactory()

Reply
0 Kudos