Implemented messaging_servicebus crate

[danbugs]

This PR is addressing and hoping to close issue #255 — That is, I've updated the crate to use the new Azure core's HttpClient, as requested. Plus, coming from MindFlavor's AzureSDKForRust, I had to make some changes to error handling, so I did that too following the pattern used by other crates under sdk/.

Signed-off-by: Dan Chiarlone dchiarlone@microsoft.com

[cataggar]

Thanks for this. Sorry, we moved the goal post. Instead of thiserror, can you please use azure_core::error. See #771.

[danbugs]

@cataggar ~ Thank you for the review! Like I mentioned in an earlier comment, I was testing this project locally, and, while doing so, I realized none of the functions related to getting messages (i.e., receive_and_delete, peek_lock, or peek_lock_full) work — no wonder there's no test coverage for anything but send_event lol

Looking further into it, I realized that's because, rather than asking for a simple queue, we are sneakily asking for an event hub, which doesn't really have that sort of functionality as can be seen per our REST API reference:

Note: source

Considering event hubs are built on top of service buses, the user could just pass in a queue name instead of an event hub name and that would work fine-ish, but I figured that's just bad UX for a crate called messaging_servicebus.

I have an upcoming PR where I'm re-organizing things:

• renamed stuff (e.g., event_hub to queue).
• because we don't need different functions for every single type of request we want to prepare (e.g., send_event_prepare, and so on), so I'm unifying all those into a single prepare_request function — similar to how other crates under sdk/ do it.
• considering delete_message, renew_lock, and unlock_message only work when we have a lock-id, which is only ever returned in the PrepareLockResponse object, I made them member functions to that struct instead.
• added documentation comments and dev comments.
• removed the duration parameter that was passed to pretty much every function of our crate and hid that detail from the user — mostly because I think it's confusing to have to pass a SAS duration when I want to, for example, just get a message. I just made it a set (and safe) expiry duration of 1 hour.
• updated the existing example (we might want to add more later).
• added test coverage for everything.

Also, per your request, I'll drop the thiserror dependency (✅)*.

Considering this was a lot of work, what are your thoughts on making this a 0.3?

[danbugs]

Another thing I'd like to point out is that, as soon as I push these latest changes, the tests from messaging_servicebus will probably fail because I changed one of the required environment variables from AZURE_EVENT_HUB_NAME to AZURE_QUEUE_NAME.

[cataggar]

I haven't looked at this library enough to know if a conversion to a String for a body is the right thing or if it should be passed around as Bytes.

[danbugs]

I followed what the crate initially did there. Plus, as a user of the crate, I'd want String rather than having to add a dependency for Bytes and handle that.

[cataggar]

We are okay with returning Bytes. A recent similar change I made is here. I'm not going to hold up this PR for this.

[danbugs]

@rylev, and @cataggar ~ Is this good to merge? Once we do, we'll have to trigger the new release of the crate!

[cataggar]

We are okay with returning Bytes. A recent similar change I made is here. I'm not going to hold up this PR for this.

[Mossaka]

it would be great to have

1. multi-thread example using rust channels, where one thread sends msg to the queue, and another thread recieves the msg from the queue.
2. multi sender-receiver where one sender sends msg to multiple queues, and mutiple recivers are able to subscribe to different queues.

what do you think?

[danbugs]

Hmmm, I don't know if we should block the PR on examples.

Also, I should note: the Azure Service Bus API does not include the concept of "subscribing".