Video: Simplifying distributed application development with NServiceBus and the Windows Azure Platform

Yesterday I delivered a presentation to my fellow mvp’s on how NServiceBus and the Windows Azure Platform can be combined to simplify distributed application development in the cloud. The session has been recorded and is now available for everyone who is interested.

Enjoy (and sorry for my crappy presentation skills)

About these ads

9 Responses to Video: Simplifying distributed application development with NServiceBus and the Windows Azure Platform

  1. Pingback: Windows Azure and Cloud Computing Posts for 10/19/2011+ - Windows Azure Blog

  2. Oskar says:

    Very interesting! And no need to apolologize for your presentation skills, they are fine.

    I have two questions:

    1) You mentioned that there is no need for a back off algorithm when using appfabric queues since transactions against it is free. But the reason you would not need a back off algorithm for app fabric queues is because you can specify a timeout in the Receive method, so that the message receiver will wait until a message appears on the queue, right?

    2) It is possible to specify when a message should appear on an appfabric queue when sending it. Couldn’t that be used instead of the timeoutmanager (one less moving part)?

    / Oskar

    • Thanks Oskar,

      1) If you don’t have to pay for access, there seems to be no point for me to block the thread waiting for a message?
      2) Yes, that is indeed an option for a timeoutmanager, andreas also mentioned that in the past. Would you prefer this strategy over the current one (which stores timeouts in table storage but keeps them in memory all the time, sends are synced by leases on blob storage)

      • Oskar says:

        1) No need to block a thread, you have BeginReceive/EndReceive which are considered best practices according to http://windowsazurecat.com/2011/09/best-practices-leveraging-windows-azure-service-bus-brokered-messaging-api/. Quote from that article: “To build a truly effective messaging solution using the Service Bus brokered messaging API, you should always perform the receive operation asynchronously. Whether your solution receives one message at a time or fetches multiple messages, you begin the receive operation using the BeginReceive() method with the specified timeout.”

        2) I would definitely investigate if BrokeredMessage.ScheduledEnqueueTimeUtc could replace the TimeoutManager in terms of functionality. It would be easier to use sagas since developers wouldn’t have to understand, configure and deploy the TimeoutManager. And your codebase would probably be a bit smaller and easier to maintain since fiddling with table storage and synchronizing using blob storage leases etc would not be needed.

  3. 1) I agree that it is a best practice, but any async call has a waiting thread in the background and as I’m in an internal background thread already when I get the message, I see no need to hand over the waiting to yet another one. But it is definitly something I will keep in mind if transaction cost ever comes into play.

    2) Yes it makes sense from that pov and also from a cost perspective, Now you need an instance to host the timeoutmanager, with this option you don’t.

    I’ll look into it!

  4. Valery says:

    Great video Yves! I took the 5-day nServiceBus trainingcourse last week in San Francisco and you answered many of my questions on the relationship between Windows Azure and nServiceBus. Is the sample application you demonstrated in your presentation available for download? It would be very helpful to me.

  5. Valery says:

    My bad, the sample IS in the link mentioned at the end of the presentation. I thought it wasn’t because of using the Flickr style and name. Thanks.

  6. Valery,

    The code of the sample itself is not yet available, I still need to strip it from it’s layout before I can put it in the samples repository.

    Kind regards,
    Yves

  7. Pingback: NServiceBus at Twin Cities Code Camp 13 | David Boike's Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: