I want implement the claim-check workflow with Azure Service Bus:
claim check
Is it possible to do that using node.js?
I just found only .net examples and I cant see anything in #azure/service-bus node package that seems to refer to claim check.
Anyone that had the same problem?
A claim check pattern can be implemented using any language as long as there's support to hook into the pipeline. For a long time, this pattern was not easy not possible to implement with .NET either as the previous .NET SDK did not provide a way to hook into the sending/receiving. The new .NET SDK had that consideration from the beginning. Almost. Once it was implemented, claim-check pattern implementation was a no brainer.
If you're looking to implement a claim check pattern as a plugin, it would need to have a pipeline concept support in the Node.js SDK.. You can raise an issue for the Service Bus library to request it or contribute yourself.
Another alternative is to abstract sending and receiving operations with your custom implementation that would use some kind of storage for the payloads.
Related
I'm using Python 3.8 and Azure's service bus SDK (azure-servicebus==0.50.3). Currently, I can use the below code to get a shared access policy rule (and key/value) for a specific topic within a namespace
from azure.mgmt.servicebus import ServiceBusManagementClient
...
self._sb_client = ServiceBusManagementClient(credential, subscription)
...
rule = self._sb_client.topics.list_keys(
self._resource_group_name,
self._namespace,
self._topic_name,
SB_SAS_POLICY_LISTEN
)
How do I make the logic a little more general so that I can query policies at the namespace level? We have a root shared access policy and I wanted to see if there's a programmatic way to get the rule similar to the above. I've tried excluding the topic parameter, but I'm unable it is required.
Aha. It appears you're specifically using azure-mgmt-servicebus for the tooling you're leveraging, which is exactly the right thing, and has the functionality you're looking for:
There is a comparable list_keys method present on the namespace as well as on a given topic, which would be called via client.namespaces.list_keys(.
Don't hesitate to shout if I've misunderstood or if any of this is unclear.
I want to create a nodejs Azure Service Bus client to read from a topic, and I want my client to automatically register its subscription.
So #azure/service-bus allows to work with SB normally, yet does not allow to create a subscription. azure-sb does allow to create one and also operate on the bus.
Do I need to install both in my nodejs app? Both seem official package from Microsoft, however, I wonder what is the intended usage for both and intended future (will one replace the other?)
To put things simply, azure-sb is the old SDK for managing Service Bus while #azure/service-bus is the new one.
There are a few differences in the two packages:
Protocol: azure-sb is a wrapper over Service Bus REST API (HTTP protocol) while #azure/service-bus makes use of AMQP protocol to communicate with Service Bus.
Features: azure-sb enables you to work with entities (Queues, Topics and Subscriptions) by allowing them to perform CRUD operations on them. These features were removed from #azure/service-bus as Microsoft is moving these CRUD operations under control plane by enforcing RBAC on these operations. For performing these operations, you will need to use #azure/arm-servicebus. #azure/service-bus package is more geared towards sending and receiving messages. It also supports Websockets in case you need that.
Do I need to install both in my nodejs app? Both seem official package
from Microsoft, however, I wonder what is the intended usage for both
and intended future (will one replace the other?)
Considering your requirement, my answer is yes. You would need both of these packages. I'm not sure if that will cause any problems. In our project, we ended up implementing REST API directly (instead of using azure-sb package) for CRUD operations on entities and used #azure/service-bus for working with messages.
Regarding #azure/service-bus will eventually replace azure-sb package, I will be purely speculating but I don't think that will happen anytime soon. For this, Service Bus team will have to remove the REST API first which seems highly unlikely however Microsoft is pushing hard for RBAC at entities level so I would recommend that you use #azure/arm-servicebus along with #azure/service-bus if you're starting new.
We're planning on implementing a server-side notification mechanism that pushes out to iOS and Android via ANH. We will have no code footprint on our mobile clients, short of a call to our server API for "registration". In this way our approach is looking similar to this MSDN discussion.
I also see the alternate, more bare-bones, approach noted on MSDN.
Is it fair to conclude that the two approaches will have similar performance on the 'send' side?
It appears the main difference is this:
The former approach has already done the work of integrating with the Task and Async mechanism, presenting a callable C# mechanism that has taken on more of the RESTful API layer,
The DirectBatch/Send API is just that -- the raw RESTful API for you to use as you see fit.
For operations that are available as both REST API and SDK, you shouldn't see any significant difference in performance on the client side because the SDK is just a wrapper around the REST APIs. There are SDKs for both iOS and Android and it's recommended to use those so that you don't have to re-write the wrapper.
Direct Send is only available in .NET SDK at the moment and for other platforms as REST API, so you'd have to implement your own wrapper in case you're using something other than .NET for the operation. You can use the sample to help you in the process.
In terms of performance it depends on what you mean by that.
Direct send will most likely be delivered to customers a bit faster because ANH service doesn't have to do any registrations in the process, it just delivers notifications with your parameters. But it has it's limitations in terms of number of handles you can provide and also you need to manage handles yourself.
If you only mean performance on the client side, then there should be no difference as all calls are asynchronous. And if you take advantage of tags, then you can do really tricky sends in one server call and let ANH figure out the details behind it.
But without knowing your scenario and requirements there's no way to give a proper recommendation.
I just want to know, does service bus support async programming.
Can I use Async/Await in service bus?
How should I do that?
Does there any samples for that?
Thanks.
The beta of sdk 2.0 has this, see http://nuget.org/packages/WindowsAzure.ServiceBus/2.0.0-beta for the bits, and check http://blogs.msdn.com/b/windowsazure/archive/2013/04/11/task-based-apis-for-service-bus.aspx for example of api usage
I think most of the Azure client libraries (SDK) do have support for asyncronous calls. In fact, this is the suggested way of using them. For example, the QueueClient type (part of ServiceBus cliend SDK) has a bunch of Begin*, End* methods. You may find the list of all methods here.
However these signatures are using the pattern with IAsyncResult, which is different from the Async/Await pattern.
So to answer your question more correctly: No, the current version of ServiceBus does not support task based async processing. It does however support IAsyncResult based asynchronous processing.
As a followup to Does ServiceStack support binary responses?, I'm wondering whether there are injection points built (or planned) to use binary serializers such as Mark Gravell's protobuf-net for efficiency between non-HTTP clients. In fact, it might not be long before protocol buffers work in JavaScript.
Yep, ServiceStack has a custom pluggable format API where its own built-in CSV Format and HTML Report Format are both registered using it. The tutorial of Nortwind Database's custom v-card media type shows how to register your own format/media type using this API.
Support for protobuf-net is planned for the near future. There was someone on the ServiceStack Group looking at exploring adding support for it. In any case, I plan to be catching up with protobuf-net's author soon so I'll find out the best way of how to add support for it then.