Retiring support for Windows Server Service Bus

[SeanFeldman]

With WSSB been deprovisioned, SBE doesn't have to support it anymore.
Current code has to cater for both, on premises SB 1.1 and ASB. This makes code unnecessary complex.

Suggest the following:

• Create a support branch to ensure bugs related to SB 1.12 are addressed
• master to support ASB only and tag it as a new major (@paolosalvatori I know you want to keep the major version aligned with the WindowsAzure.ServiceBus client, but it doesn't have to be. This client will be replace by another one and versioning of this tool should be independent).

Any suggestions/ideas are welcomed.

[SeanFeldman]

Given WSSB is no longer supported by MSFT, could you chime in on this @paolosalvatori ? Thanks.

[paolosalvatori]

Hi @SeanFeldman, does this has an impact on the codebase? Should we make any code change?

[SeanFeldman]

Some impact @paolosalvatori.

We have a few places where we execute conditionally and condition if the code is running against ASB or WSSB. ServiceBusHelper is one of them. Another example is when we determine certain properties of entities and we distinguish between ASB and WSSB (queues and topics. Quick search shows a few places like that.

I suggest to release the currently pending changes (4.0.106) and start a "cleaned-up" version to target v5. Support for WSSB would be still available as documented here. Bug fixes if needed, thought doubt would be required, could be added in support branch support-2.1.

[paolosalvatori]

@SeanFeldman, let's have a call in a few weeks, so we can make a plan. The next few weeks I'll be onm customer site

[tomkerkhove]

What's the status here?

[SeanFeldman]

Good question. What is it? 😃
I've outlined the proposal in the issue description. Perhaps we should do it in async mode as it's almost impossible to get on a call.

[paolosalvatori]

@SeanFeldman @tomkerkhove SBE 2.1.3 was the latest version of the tool supporting Windows Server Service Bus. We created a separate branch for Windows Server Service Bus, but we are not going to make any development to mantain and evolve this version. What do you have in mind?

[SeanFeldman]

I've created support branch support-2.1 so that SBE 2.1 can live independently and be updated if needed.

Quoting from the issue description:

master to support ASB only and tag it as a new major

[paolosalvatori]

@SeanFeldman I read the original post, but I don't get it. Which client library would you like to use?

[SeanFeldman]

@paolosalvatori what client library to use is not a question here. For now we'll continue with the same client used for the last X year. I was mentioning your desire to keep the tool version in sync with the client version. The argument for that is probably becoming even weaker, considering that there's no planned v5 of the ASB client ( WindowsAzure.ServiceBus) since it will be in maintenance mode only.

As for the original post, the focus is on removing support for anything that is not the core functionality of the tool and releasing that as v5.

[paolosalvatori]

What do you mean with "anything is not the core functionality of the tool"? Notification Hubs? IoT Hubs? I have users that ping me offline as they use the tool with minor, not mainstream features like relays and notification hubs... I don't see the need the remove this support. I'd prefer to add rather than remove features :)

[SeanFeldman]

Personally, I'd carve those out into dedicated tool. But that's not the point.
Let's focus on what this issue is for - removing suport for WSSB in the next major (5.0).

[paolosalvatori]

Agreed, let's focus on removing support for WSSB in the next major release. :)
P.S. Microsoft Azure Storage Explorer tool also supports Cosmos Db, even if the latter is a separate service with respect to Azure Storage Services :)

[ErikMogensen]

During the Q&A session at Integrate 2018 in London Dan Rosanova said that Service Bus would be available on Azure Stack "sooner than you think". We should of course provide support for that and even though the handling of SB on Azure Stack will most likely be different from SB on Windows Server it is probably the same places in the source code that needs to be changed.

Therefore I think we should pause this until SB on Azure Stack is released.

[tomkerkhove]

I think this is not related to Service Bus for Windows Server as Azure Stack is in parity with Azure in general so we do not need to do anything there from what I know.

[SeanFeldman]

I'm also under the same impression that Azure Stack services are the same cloud serivces just provisioned locally. Therefore there should be no difference between ASB and ASB on Azure Stack in terms of invoking ASB client.

[paolosalvatori]

Yes, Service Bus in Azure Stack has nothing to do with Service Bus for Windows Server but it will share the same architecture of Service Bus on Azure.

[SeanFeldman]

@paolosalvatori do you know if this one is OK to be closed under 5.0.0?

[paolosalvatori]

@SeanFeldman I think we can close this issue. @SeanFeldman @ErikMogensen feel free to close it.

[SeanFeldman]

5.0.0 milestone applied, closing

[NiklasEMS]

Service Bus on Windows Server is still supported together with SharePoint 2013, 2016, 2019 until their end of lifecycle as they use Workflow Manager which uses Service Bus on Windows Server. Using Service Bus Explorer is great tool for troubleshooting as well so would be great if multi-support can still be maintained or at least if there is already compiled older version to download at least that works quickly. Right now what I could find, there is older VS 2012 SBE solution that has no compiled version. If there is a need to quickly troubleshoot having to find and install VS 2012 and the dependencies, compile etc it takes a lot of time.

[paolosalvatori]

@NiklasEMS no worries, there's a dedicated version of SBE for Service Bus on Windows Server. There should be a link on the main page for it. The main codebase stopped supporting Service Bus on Windows Server due to some breaking changes introduced by SDK client library.