We're trying to determine what kind of logic we should use for provisioning our client, both for initial connection and for later disconnects or changes to the broker configuration on our DXL fabric.
As it is right now, we run through the provisioning process as part of our connection logic because our service is expected to start once and run indefinitely.
It is not recommended to include the provisioning logic inside of the actual connection logic if you are doing both as a part of the runtime operation of your integration.
A client's connection to the DXL fabric is subject to outside influences such as network connectivity (among other issues), and if the provisioning is a part of connecting it would be possible to end up sending several provisioning requests. Provisioning is not only a relatively expensive operation in terms of computation compared to simply connecting, each new successful provisioning will store the certificate and related information in your ePO database (for ePO-managed fabrics) and/or in your brokers' client certificate store.
Long story short... If you are using a script or some other programmatic way of provisioning your client, this should be entirely separate to your connection logic. This way, it will only run one time.
What happens if we provision our client, and later add brokers to the fabric? What if we remove brokers?
As long as at least one of the brokers in your client's broker list in the dxlclient.config file is available, and an administrator has not removed the client's certificate information from ePO (for ePO-managed fabrics) or the broker (for open fabrics), the client would be expected to connect successfully.
The only scenarios where re-provisioning should be required: