I am working to port an application which was designed to work in a non-Azure environment. One of the elements of the architecture is a singleton which does not scale, and which I'm hoping to replace w/ multiple worker processes serving the resource that the singleton currently provides.
I have the necessary changes in place to replace the singleton, and am at the point of constructing the communications framework to provide interconnection from the UI servers to the resource workers and I'm wondering if I should just use a TCP binding on a WCF service or whether using the Azure Service Bus would make more sense. The TCP/WCF is easy, but doesn't solve the complete problem: how do I ensure that only one worker processes a UI request?
From reading the available documentation, it sounds like the service bus will solve this, but I've yet to see a concrete example of implementation. I'm hoping someone here can assist and/or point me in the right direction.
Seems that Azure Service Bus queues are the right solution for you.
Azure Service Bus can be used in 3 different ways:
Queues
Topics
Relays
From windows azure site:
Service Bus queues provide one-way asynchronous queuing. A sender sends a message to a Service Bus queue, and a receiver picks up that message at some later time. A queue can have just a single receiver
You can find more info at:
http://www.windowsazure.com/en-us/develop/net/fundamentals/hybrid-solutions/
Adding to Davide's answer.
Another alternative would be to use Windows Azure Queues. They are designed to facilitate asynchronous communication between web and worker roles. From your web role you push messages into a queue which is polled by your worker roles.
Your worker role can "Get" one or more messages from a queue and work on those messages. When you get a message from a queue, you can instruct the queue service to make those messages invisible to other callers for a certain amount of time (known as message visibility timeout). That would ensure that only worker role instance get to work on a message.
Once the worker role has completed the work, it can simply delete the message. If there's an error in processing the message, the message automatically reappears in the queue once the visibility timeout period has expired. You may find this link helpful: http://www.windowsazure.com/en-us/develop/net/how-to-guides/queue-service/.
Azure queues are not designed for inter process communication, but inter-application communication. The message delivery latency is substantial, and delivery timing cannot be guaranteed. Websockets or NetTcpBinding is more suitable for applications that talk to eachother in realtime. Although must admit, you get some free stuff with queuez, especially the locking mechanisms. Just my 2 cents
Related
I've created an Azure Function App which is triggered from Azure Service Bus Queues. The Service Bus has two queues in it and there is a function with a trigger for each of the queues. The Function App is developed using C# in Visual Studio and uses package deployment publishing.
What I would like to do is be able to indicate that one function/trigger should be processed before the other if they both have messages waiting. (They both do basically the same thing but one queue is for handling messages with a higher priority since queues are only FIFO.)
I have read that functions are processed in alphabetical order but that doesn't feel like something to rely on really.
Is there any way to explicitly indicate a priority (or even a scale-out preference) for one function/trigger over another?
(They both do basically the same thing but one queue is for handling messages with a higher priority since queues are only FIFO.)
The above scenario looks like competing consumers which has a dedicated design pattern known as competing consumers pattern where it contains the limitation with the messaging order in this pattern.
Consumer service instances may receive messages in any order, and this order need not correspond to the order in which the messages were created.
So unfortunately, it's not possible to prioritize one function over another function listening to the Service Bus queue.
You can control the activity function & orchestrator but not the starter function using the Azure Durable Functions.
Microsoft Azure Service Bus Queues can implement guaranteed first-in-first-out ordering of messages by using message sessions. For more information, see Messaging Patterns Using Sessions.
There is an async method in WPF viewmodel
var asyncTask = await Service.Execute();
Execute method is a method of a microservice, which is executed asynchronyously.
Is there any way to send the task status of execute method from microservice to WPF viewmodel ?
There are a couple of options, but it all depends a bit on your setup.
The idea is to have a callback to your application, one way or the other. This can be a direct response to the application, the application listening to a shared notification system or by polling.
Remote Procedure Call (RPC)
WebSockets / notification system
Polling
Message queuing like MSMQ, RabbitMQ, SQS, Azure Service Bus
These methods all have pro's and cons. Depending on the requirements you need to pick a suited one.
Let me elaborate.
Remote Procedure Call (RPC)
In this setup the micro service (MS) needs to to communicate back to the UI application. This usually is a bad idea, because you need to make the MS aware of the Client application - and also, you'll need connectivity inbound to the client application.
The Client applicationto host RPC endpoints to make this work.
Normally this is not really an option.
WebSockets / notification system
Basically this is a similar method as above. However WebSockets or a notification system like Azure or AWS SNS is likely to overcome the burden of the incoming connection.
I'll add some documentation for some libraries.
Polling
This is by far the easiest to implement Client side, but harder in MS side.
Since it's a long running task, after initiation on could send back the ID of the job, (in a HTTP ACCEPTED way (assuming you use HTTP to interact with the MS), and periodically request the status of the given job at the MS.
Message queuing like MSMQ, RabbitMQ, SQS, Azure Service Bus
This is unlikely, but I want to name it for completeness.
Often MS inter process communication is done over a Message Queuing (MQ) mechanism. You could hook up the application onto this MQ system and let it listen to an event/message broadcasted by the MS.
I have a WCF service (the fact that it's WCF shouldn't matter) and I'm not looking for message queuing, but instead for an asynchronous work queue in which to place tasks, once a request / message is received. Requirements:
Must support persistent store that enables recovery of tasks in the case of Server / service process failure.
Supports re-running of failed jobs, up to a given limit (i.e. try re-running a job up to 5 times)
Able to record the failed job call along with its parameters, in an easily queried fashion. For example, I would query the store for failed jobs and receive a list of "job name, parameters".
Unfortunately cannot be a cloud-based / hosted solution.
Queues that I'm probably not looking for:
MSMQ (RabbitMQ, AMQP). Low level, and is focused on message transport.
Quartz.NET. Has some of the above but its error-recording facilities are lacking. Geared more toward cron-like scheduling than async work and error reporting.
the Default Task Scheduler of .NET TPL. It has no persistence of the process owning it stops abruptly and doesn't support re-running of tasks very well.
I think I'd be looking for something more along the lines of Celery, Resque, or even qless. I know Resque.NET exists (https://www.nuget.org/packages/Resque/), but not sure if there's something more mainstream, or if that could suffice.
What about Amazon SQS? You don't have to worry about infrastructure as you would with RabbitMQ/MSMQ. SQS is dirt cheap, too. Last time I checked, it was $0.01 per 10,000 messages. Why re-invent the wheel? Let Amazon (or other cloud providers with similar services, like Microsoft and Rackspace) do all the worrying.
I use Amazon SQS in production for all message-based services. Some of these messages act like chron jobs; an external process queues the message at a specific time. Some of them are acted upon immediately.
I would be grateful for some design suggestions concernig a windows service (c#) for publishing reports to a SOAP service.
It fetches a limited set of reports from a database (reports in Oracle AQ table), aggregates them into a message and forwards this message to a WCF SOAP service.
Reports are marked as "sent" if they have been transmitted via SOAP successfully.
Otherwise they are added again to the AQ table (via a db job).
So I came up with following designs.
What would be the best way to go?
Would the queue improve the design in terms of scalability, robustness, decoupling?
Is it a good idea to use queuing in this case?
Proposed design A:
Service with 1 to N threads.
Each thread processes reports synchronously (fetching reports, aggregating, translating, sending via SOAP)
Proposed design B:
Windows service with:
1 MSMQ message queue
1 to N Producer threads: (fetching reports,
aggregating, enqueuing message via MSMQ)
1 to N Consumer threads:
(dequeuing, translating, dipatching via SOAP)
Proposed design C:
Windows service with producer threads (fetching reports, aggregating, enqueuing messages to a private MSMQ queue via WCF NetMsmqBinding Client)
IIS/WAS hosted MSMQ-enabled service (listens to the MSMQ queue, dequeuing, translating, dipatching via SOAP)
Is there a particular reason you chose MSMQ? If you use your proposed design B, you could use BlockingCollection.
I don't see that MSMQ provides a particular advantage in this scenario unless you want multiple processes or you're expecting to spread this out across multiple computers.
But do you really even need multiple threads? It seems like your limiting factor here will be either database access time or communication to the WCF service. Unless the WCF service has to do some major processing before you can call the job successful.
So are you sure you can't just have:
while there are unsent jobs in the database
get job
send job to WCF
if job sent successfully
mark job as sent
end while
Obviously my knowledge of your situation is limited to what you've posted in your question, so it's possible I've missed something important.
I am looking for a message broker API to use it with c#.
Normally the things are quite simple. I have a server that knows what jobs are to do and I have some clients that need to get these jobs.
And here are the special requirements I have:
If a client got a job but fails to answer within a specific time, then another client should do the work.
More than one queue and priorities
If possible it needs to work with big message queues (this way I could just load all jobs sometimes a month and forget about it
secured communications would be good.
API for talking with the broker from c#. How much work is done? What is still to do?
Delete some jobs...
If available replication to another broker would be good.
The broker needs to run on windows
What is not an issue:
low latency (there is no problem when a message needs minutes)
Do you know such a message broker that is free to use?
RabbitMQ and several other AMQP implementations satisfy most of (if not all of) these requirements.
RabbitMQ allows clients to acknowledge receipt and/or processing of messages. As per http://www.rabbitmq.com/tutorials/amqp-concepts.html#message-acknowledge:
If a consumer dies without sending an acknowledgement the AMQP broker
will redeliver it to another consumer or, if none are available at the
time, the broker will wait until at least one consumer is registered
for the same queue before attempting redelivery.
Many queues (and in fact many brokers) are supported, in a variety of different configurations
It scales particularly well, even for very large message queues: http://www.rabbitmq.com/faq.html#performance
Encryption is supported: http://www.rabbitmq.com/faq.html#channel-encryption
There is a .NET Client Users Guide and API docs: http://www.rabbitmq.com/documentation.html
There is live failover if a broker dies: http://www.rabbitmq.com/clustering.html
It runs on Windows, Linux, and probably anything else that has an Erlang implementation