[FEATURE REQ] Add ability to manage rules with the ServiceBusReceiver

[JoshLove-msft]

This existed in Track 1, and allowed users with only Listen claims to manage rules on the subscription that they had listen claims for. In Track 2, this can be done using the ServiceBusAdministrationClient, but it requires Manage claims.

.NET issue - Azure/azure-sdk-for-net#25523
.NET PR - Azure/azure-sdk-for-net#27346

[ZejiaJiang]

Hi @JoshLove-msft @jsquire I'm looking at this issue, after going through dotnet code, it feels like we just add a new client type RuleManager to manage rules if user set topic, subscription and connectionString with Listen claims. It seems like that we don't add ability to ServiceBusReceiver. Did I misunderstand?

[jsquire]

That was the approach that .NET took for modeling the API. Since this functionality requires a dedicated set of AMQP links, it cannot be done directly via the Receiver's existing infrastructure and isolating that functionality in a dedicated type helps to manage that scope as well as logically group the related operations.

Personally, I'd like to see the pattern in Java align with the .NET API unless there's a good reason to deviate.

[ZejiaJiang]

Thank you @jsquire .I got it. And I'd like to make it clear. Actually the sender client or other client, they both use the dedicated set of AMQP links. What I mean above is we don't just add some new API to ServiceBusReceiver. My understanding is the rule manager use AMQP link to send operations to server just like sender and receiver, different from admin client using the HTTP.

[jsquire]

Correct; rule management here goes over a special set of AMQP links, not via the HTTP Atom service.