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.
Related
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.
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.
I have an azure function with an azure storage queue trigger. It runs fine without any problems. Inside the queue there will be saved a json and then the function does their job.
But now we need more functionality. I like to expand the json with a functionality key. Now is it better to expand also the function
If functionality = A go to class A
Else go to class B
Or is it better to create a new function with the same trigger?
Regards
It is okay to have different classes in the function.
To make the function responsible only for a particular process, you can split it into two functions and have Service Bus Topic Subscriptions instead of Storage Queues. This will keep the implementation reliable as Service Bus got wide set of features when compared to Storage Queues.
You can use Rules in Topic Subscriptions for filtering the messages.
Functions are just like traditional apps. There's no issues in referencing a class library that handles that deserializing.
What you are looking for is a concept called Message Versioning. It's a heavy topic so I may not be able to handle it here completely but versioning will happen.
One possibility, is to consider each messages as a Command (read on CQRS). You could pre parse the version number in the message and have a CommandHandler for each version.
This is not specific to Functions. Here's a piece of advice Functions related. Keep a single function. With versioning happening, it will be simpler to debug and find what Functions is still working or not.
The documentation of Service Fabric recommends service remoting, ICommunicationClient or WcfCommunicationClient to realize the communication between the micro services.
The ServiceBus, which I always used for inter-service communication, is not even mentioned. Why?
I think you misinterpreted the docs. It does not recommend any protocol or service (the word is not even present on the page). What it does do is list the built-in communication options and appropriate situations of when to use them.
There is nothing that prevent you from using service bus for inter service communications. In fact, if you google around you will find some projects like this one
The ability to plug in any desired service or protocol is one of the great things about SF, but they leave the implementation to you.
There are many approaches to do service to service communication, if they had to document all of then, they would spend more time writing the possible approaches than doing the actual communication.
They probably decided for the one with closest relation to the platform, but they could write about any possible, it is just a matter o preference.
I could name a few from many just to have an idea:
Http
Remoting
WCF
Service Bus
Event Hub
AMQP
MQTT
gRPC + protobuf
TCP
UDP
Pipes
And many more, Imagine if they had to document all of then.
The communication is flexible enough to let you implement using any communication mechanism.
Regarding the ones you mentioned,
I always opt for HTTP for being platform agnostic and widely implemented on most platforms, does not matter if is .Net, Java, NodeJs, Windows or Linux, they all talk the same language, the others are very tight to the .Net and Windows platform and force every other solution to be also tighten or adapted to then. And also there is the fact of some being synchronous and other asynchronous like Service bus.
Then, when performance is an issue, I evaluate the other options.
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.