Azure-sdk-for-java: ServiceBus Track 2 Analyse
Nous devons analyser le travail à faire pour Service Bus Track 2. Track 1 est déjà sorti.
Hypothèses:
- La piste 2 sera une réécriture complète à partir de zéro. Nous pouvons examiner la base de code de la piste 1 et analyser si ce code ou une partie de celui-ci peut être utilisé. La bibliothèque Track1 se trouve sur https://github.com/Azure/azure-service-bus-java
- Dans la portée : uniquement les files d'attente et les sujets
- Contrat API Java Script à suivre : mai 2018 GA a été publié pour javascript et en avance sur la maturité. Ces API peuvent être trouvées ici https://docs.microsoft.com/en-us/javascript/api/%40azure/service-bus/queueclient?view=azure-node-latest
Nous pourrions regarder cette API et imiter l'API Java. Ramya est la personne de contact pour cela.
Interroger:
- Identifiez les travaux à effectuer dans Service Bus track2.
- Documentez et créez des problèmes pour les éléments de travail. Cela nous donnera une idée de la quantité de travail que nous devons faire.
- Analysez EvenHubs et identifiez la base de code commune qui pourrait être utilisée par ServiceBus. Créer un problème pour le code commun qui doit être déplacé hors d'Eventhubs vers
azure-core-amqp. - Examinez les problèmes/réclamations/points douloureux de Service Bus track1 et identifiez des solutions.
Précisions nécessaires :
- Le relais ServiceBus est-il dans la portée. @AlexGhiondea s'il vous plaît suggérer? https://docs.microsoft.com/en-us/azure/service-bus-relay/
- Étant donné que Track2 aura beaucoup de changements dans l'API de l'API Track1. Comment pouvons-nous mesurer le coût de migration pour un client existant de l'API Track1 vers Track 2 ?
hemanttanwar
Tous les 3 commentaires
Quelle est la justification d'une réécriture complète? Pouvez-vous partager des directives ou des documents de conception de haut niveau afin que les clients puissent comprendre où va la bibliothèque et pourquoi ?
Je crains que nous nous retrouvions avec une situation de réécriture indésirable similaire à ce qui est arrivé à la réécriture de la bibliothèque de stockage. Voir ici pour une discussion franche des problèmes : https://github.com/Azure/azure-storage-java/issues/432. Après avoir écouté tous les commentaires, l'équipe travaillant sur cette bibliothèque a partagé un excellent document d'orientation : https://github.com/Azure/azure-storage-java/blob/master/V12%20Upgrade%20Story.md
Ce serait formidable de voir quelque chose dans ce sens prévu pour la transparence ici.
jordanjennings
le 6 août 2019
Bonjour @jordanjennings , merci d'avoir posé cette question. Pour clarifier, un effort est en cours au sein de Microsoft pour créer une nouvelle génération de bibliothèques clientes pour Azure, pour de nombreux langages de programmation de premier plan. La discussion que vous avez liée à partir de Storage est pertinente ici - la V12 est la "réécriture" que nous avons faite pour Storage, et est similaire ici pour Service Bus. Vous pouvez en savoir plus dans notre annonce de la première version de prévisualisation .
Ce que @hemanttanwar dit ici, c'est qu'il est sur le point de commencer un processus équivalent de révision, de conception et de mise en œuvre pour assurer une expérience de développement cohérente, idiomatique et productive pour Service Bus, comme nous le faisons depuis quelques mois. Un document de conception de haut niveau que vous pourriez trouver intéressant est le document de directives de conception de l'API Java que j'ai écrit. Ce document est ce qui a guidé l'API de stockage V12, ainsi que toutes les futures bibliothèques clientes Java (dont beaucoup sont actuellement en développement et/ou en préversion). N'hésitez pas à m'envoyer un e-mail directement pour toute question ou préoccupation.
JonathanGiles
le 12 août 2019
Corrigé dans # 4506
conniey
le 23 mars 2020
Questions connexes
srnagar
·
4Commentaires
abhikt48
·
3Commentaires
shubhambhattar
·
4Commentaires
amitbaer
·
3Commentaires
frank-fischer-by
·
3Commentaires
Commentaire le plus utile
Bonjour @jordanjennings , merci d'avoir posé cette question. Pour clarifier, un effort est en cours au sein de Microsoft pour créer une nouvelle génération de bibliothèques clientes pour Azure, pour de nombreux langages de programmation de premier plan. La discussion que vous avez liée à partir de Storage est pertinente ici - la V12 est la "réécriture" que nous avons faite pour Storage, et est similaire ici pour Service Bus. Vous pouvez en savoir plus dans notre annonce de la première version de prévisualisation .
Ce que @hemanttanwar dit ici, c'est qu'il est sur le point de commencer un processus équivalent de révision, de conception et de mise en œuvre pour assurer une expérience de développement cohérente, idiomatique et productive pour Service Bus, comme nous le faisons depuis quelques mois. Un document de conception de haut niveau que vous pourriez trouver intéressant est le document de directives de conception de l'API Java que j'ai écrit. Ce document est ce qui a guidé l'API de stockage V12, ainsi que toutes les futures bibliothèques clientes Java (dont beaucoup sont actuellement en développement et/ou en préversion). N'hésitez pas à m'envoyer un e-mail directement pour toute question ou préoccupation.