Azure-sdk-for-java: ServiceBus-Track-2-Analyse
Wir müssen die erforderlichen Arbeiten für Service Bus Track 2 analysieren. Track 1 ist bereits freigegeben.
Annahmen:
- Track 2 wird von Grund auf neu geschrieben. Wir können uns die Codebasis von Track 1 ansehen und analysieren, ob dieser Code oder ein Teil davon verwendet werden kann. Die Track1-Bibliothek finden Sie unter https://github.com/Azure/azure-service-bus-java
- Im Geltungsbereich: Nur Warteschlangen und Themen
- Java-Script-API-Vertrag folgt: Mai 2018 GA wurde für Javascript veröffentlicht und ist bald ausgereift. Diese API finden Sie hier https://docs.microsoft.com/en-us/javascript/api/%40azure/service-bus/queueclient?view=azure-node-latest
Wir könnten uns diese API ansehen und in der Java-API nachahmen. Ramya ist dafür Ansprechpartnerin.
Fragen:
- Identifizieren Sie, welche Arbeiten in Service Bus track2 erledigt werden müssen.
- Dokumentieren und erstellen Sie Probleme für Arbeitselemente. Dies gibt uns eine Vorstellung davon, wie viel Arbeit wir tun müssen.
- Analysieren Sie EvenHubs und identifizieren Sie eine gemeinsame Codebasis, die von ServiceBus verwendet werden könnte. Erstellen Sie ein Problem für allgemeinen Code, der aus Eventhubs in
azure-core-amqpverschoben werden muss. - Sehen Sie sich die Probleme/Beschwerden/Schmerzpunkte von Service Bus Track1 an und finden Sie Lösungen dafür.
Klärungsbedarf:
- Ist das ServiceBus-Relay im Geltungsbereich. @AlexGhiondea bitte vorschlagen? https://docs.microsoft.com/en-us/azure/service-bus-relay/
- Da Track2 viele Änderungen in der API von Track1 API haben wird. Wie können wir die Migrationskosten für bestehende Kunden von Track1 zu Track 2 API messen?
hemanttanwar
Alle 3 Kommentare
Was ist der Grund für eine komplette Neufassung? Können Sie eine Richtung oder allgemeine Designdokumente teilen, damit die Kunden verstehen können, wohin sich die Bibliothek entwickelt und warum?
Ich mache mir Sorgen, dass wir am Ende mit einer unerwünschten Umschreibungssituation enden werden, ähnlich der, die beim Umschreiben der Speicherbibliothek passiert ist. Hier finden Sie eine offene Diskussion der Probleme: https://github.com/Azure/azure-storage-java/issues/432. Nachdem das Team, das an dieser Bibliothek arbeitet, das gesamte Feedback angehört hat, hat es ein ausgezeichnetes Anleitungsdokument geteilt: https://github.com/Azure/azure-storage-java/blob/master/V12%20Upgrade%20Story.md
Es wäre schön, wenn hier etwas in dieser Richtung für Transparenz sorgen würde.
jordanjennings
am 6. Aug. 2019
Hallo @jordanjennings , danke, dass du diese Frage gestellt hast. Zur Verdeutlichung: Innerhalb von Microsoft werden Anstrengungen unternommen, um eine neue Generation von Client-Bibliotheken für Azure für viele der wichtigsten Programmiersprachen zu entwickeln. Die Diskussion, die Sie von Storage aus verlinkt haben, ist hier relevant – V12 ist die „Umschreibung“, die wir für Storage vorgenommen haben, und ist hier für Service Bus ähnlich. Sie können mehr in unserer Ankündigung für die erste Vorschauversion lesen .
Was @hemanttanwar hier sagt, ist, dass er im Begriff ist, einen gleichwertigen Überprüfungs-, Entwurfs- und Implementierungsprozess zu beginnen, um eine konsistente, idiomatische und produktive Entwicklererfahrung für Service Bus zu gewährleisten, wie wir es in den letzten Monaten getan haben. Ein High-Level-Designdokument, das Sie vielleicht interessant finden könnten, ist das Dokument mit den Java-API-Designrichtlinien, das ich geschrieben habe. Dieses Dokument hat die V12-Speicher-API sowie alle zukünftigen Java-Client-Bibliotheken geleitet (von denen sich viele derzeit in der Entwicklung und/oder im Vorschau-Release-Status befinden). Bitte zögern Sie nicht, mir bei Fragen oder Bedenken direkt eine E-Mail zu senden.
JonathanGiles
am 12. Aug. 2019
Behoben in #4506
conniey
am 23. März 2020
Verwandte Themen
amitbaer
·
3Kommentare
alzimmermsft
·
3Kommentare
abelmariam
·
4Kommentare
SukruthKS
·
5Kommentare
thanhngo219
·
4Kommentare
Hilfreichster Kommentar
Hallo @jordanjennings , danke, dass du diese Frage gestellt hast. Zur Verdeutlichung: Innerhalb von Microsoft werden Anstrengungen unternommen, um eine neue Generation von Client-Bibliotheken für Azure für viele der wichtigsten Programmiersprachen zu entwickeln. Die Diskussion, die Sie von Storage aus verlinkt haben, ist hier relevant – V12 ist die „Umschreibung“, die wir für Storage vorgenommen haben, und ist hier für Service Bus ähnlich. Sie können mehr in unserer Ankündigung für die erste Vorschauversion lesen .
Was @hemanttanwar hier sagt, ist, dass er im Begriff ist, einen gleichwertigen Überprüfungs-, Entwurfs- und Implementierungsprozess zu beginnen, um eine konsistente, idiomatische und produktive Entwicklererfahrung für Service Bus zu gewährleisten, wie wir es in den letzten Monaten getan haben. Ein High-Level-Designdokument, das Sie vielleicht interessant finden könnten, ist das Dokument mit den Java-API-Designrichtlinien, das ich geschrieben habe. Dieses Dokument hat die V12-Speicher-API sowie alle zukünftigen Java-Client-Bibliotheken geleitet (von denen sich viele derzeit in der Entwicklung und/oder im Vorschau-Release-Status befinden). Bitte zögern Sie nicht, mir bei Fragen oder Bedenken direkt eine E-Mail zu senden.