Azure-sdk-for-java: ServiceBus Track 2 Analysis

[hemanttanwar]

We need to analyze the work needed to be done for Service Bus Track 2. Track 1 is already released.

Assumptions:

1. Track 2 will be complete rewrite from scratch. We can look at Track 1 code base and analyze if this code or part of it can be used. Track1 library is found at https://github.com/Azure/azure-service-bus-java
2. In Scope: Only Queues and Topics
3. Java Script API contract to follow : May 2018 GA was released for javascript and ahead in maturity. These API can be found here https://docs.microsoft.com/en-us/javascript/api/%40azure/service-bus/queueclient?view=azure-node-latest
   We could look at this API and mimic in Java API. Ramya is contact person for this.

Ask:

1. Identify what work needs to be done in Service Bus track2.
2. Document and create issues for work items. This will give us idea how much work we need to do.
3. Analyze EvenHubs and identify common code base that could be used by ServiceBus. Create issue for common code that needs to be moved out of Eventhubs and into azure-core-amqp.
4. Look into Service Bus track1 issues/complaints/pain points and identify solutions for them.

Clarification Needed:

1. Is ServiceBus Relay in Scope. @AlexGhiondea please suggest ? https://docs.microsoft.com/en-us/azure/service-bus-relay/
2. Since Track2 will have lot of changes in API from Track1 API. How can we measure migration cost for existing customer from Track1 to Track 2 API ?

[jordanjennings]

What is the rationale for a complete rewrite? Can you share any direction or high level design documents so customers can understand where the library is headed and why?

I am worried that we'll end up with an undesirable rewrite situation similar to what happened to the storage library rewrite. See here for some frank discussion of the issues: https://github.com/Azure/azure-storage-java/issues/432. After listening to all the feedback the team working on that library shared an excellent direction document: https://github.com/Azure/azure-storage-java/blob/master/V12%20Upgrade%20Story.md

It would be great to see something along those lines provided for transparency here.

[JonathanGiles]

Hi @jordanjennings, thanks for asking this question. To clarify, there is an effort underway within Microsoft to bring about a new generation of client libraries for Azure, for many of the top-tier programming languages. The discussion you linked to from Storage is relevant here - the V12 is the 'rewrite' we did for Storage, and is similar here for Service Bus. You can read more in our announcement for the first preview release.

What @hemanttanwar is saying here is that he is about to begin an equivalent process of review, design, and implementation to ensure a consistent, idiomatic, and productive developer experience for Service Bus, like we have been doing for the past few months. A high level design document you might find interesting is the Java API design guidelines document I wrote. This document is what guided the V12 Storage API, as well as all future Java client libraries (of which many are in development and / or preview release state now). Please feel free to email me directly with any questions or concerns.

[conniey]

Fixed in #4506