CODEWITHSUNDEEP
azureazure-queues
Mike W
Mike W

Reputation: 559

Azure Loosely Coupled / Scalable

I have been struggling with this concept for a while. I am attempting to come up with a loosely coupled Azure component design that is completely scalable using Queues and worker roles, which dequeue and process the items. I can scale the worker roles at will, and publishing to the queue is never an issue. So far so good, but, it seems that the only real world model this could work in is fire and forget. It would work fantastic for logging and other one way operations, but let's say I want to up load a file using queues/worker roles, save it to blob, then get a response back once it is complete. Or should this type of model not be used for online apps? What is the best way to send a notification back once an operation is completed? Do I create a response Q, then (somehow) retrieve the associated response? Any help is greatly appreciated!!!!!

Upvotes: 0

Views: 179

Answers (2)

Didier Caron
Didier Caron

Reputation: 570

you could also look into the servicebus appfabric instead of using queues. with the servicebus you can send messages, use queues etc all from the servicebus appfabric. you could go to publish and subscribe instead of polling then!

Upvotes: 1

user94559
user94559

Reputation: 60143

I usually do a polling model.

  1. Client (usually a browser) sends a request to do some work.
  2. Front-end (web role) enqueues the work and replies with an ID.
  3. Back-end (worker role) processes the queue and stores the result in a blob or table entity named .
  4. Client polls ("Is done yet?") at some interval.
  5. Front-end checks to see if the blob or table entity is there and replies accordingly.

See http://blog.smarx.com/posts/web-page-image-capture-in-windows-azure for one example of this pattern.

Upvotes: 4

Related Questions