Artwork

Treść dostarczona przez Udi Dahan. Cała zawartość podcastów, w tym odcinki, grafika i opisy podcastów, jest przesyłana i udostępniana bezpośrednio przez Udi Dahan lub jego partnera na platformie podcastów. Jeśli uważasz, że ktoś wykorzystuje Twoje dzieło chronione prawem autorskim bez Twojej zgody, możesz postępować zgodnie z procedurą opisaną tutaj https://pl.player.fm/legal.
Player FM - aplikacja do podcastów
Przejdź do trybu offline z Player FM !

[Podcast] Message Priority – You Aren’t Gonna Need It

 
Udostępnij
 

Manage episode 65045178 series 63841
Treść dostarczona przez Udi Dahan. Cała zawartość podcastów, w tym odcinki, grafika i opisy podcastów, jest przesyłana i udostępniana bezpośrednio przez Udi Dahan lub jego partnera na platformie podcastów. Jeśli uważasz, że ktoś wykorzystuje Twoje dzieło chronione prawem autorskim bez Twojej zgody, możesz postępować zgodnie z procedurą opisaną tutaj https://pl.player.fm/legal.

In this podcast we’ll be discussing the issues around supporting different kinds of service-level agreements in an SOA, and how using message prioritization helps and hurts. We’ll also be looking at alternative solutions more distributed in nature,which make use of specific deployment and configuration schemes that result in a more robust system.

Symon asks:

Hi Udi,

I don’t know if this is really an NServiceBus question or a more general architecture question, so if you want to treat it as an Ask Udi question feel free. 🙂 My question is about handling message prioritization between services in an SOA architecture using an ESB- in this case NServiceBus.

We’ve been running along nicely getting the hang of using the NServiceBus but have just hit a point in our application where it’s become clear that we’re going to need to prioritize messages between services according to an arbitrary set of rules. To that end we’ve created a “controller” that determines a message’s priority according to a set of rules and that controller should forward the message to other services for handling according to that priority. Where we’re stuck is figuring out the best way to handle the prioritization of the forwarded message.

We touched on the idea of having several endpoints representing low, medium or high priority and shunting the message to the appropriate endpoint, however since the receiving service consists of multiple workers located on other machines we need to have a dispatcher for each of these endpoints. Since we’re using MSMQ this seems to be causing an explosion of queues and the solution seems to require a lot of overhead in terms of set up, but it *does* look like it might be flexible as long as we come up with a smart dispatcher.

Is this an “ideal” way to handle message prioritization? I know there is a notion of priority in MSMQ messages, but this isn’t exposed in NServiceBus as far as I can tell.

Any suggestions?

Cheers,

Symon

Download

Download via the Dr. Dobb’s site

Or download directly here.

Additional References

Want more?

Check out the “Ask Udi” archives.

Got a question?

Send Udi your question to answer on the show.

  continue reading

21 odcinków

Artwork
iconUdostępnij
 
Manage episode 65045178 series 63841
Treść dostarczona przez Udi Dahan. Cała zawartość podcastów, w tym odcinki, grafika i opisy podcastów, jest przesyłana i udostępniana bezpośrednio przez Udi Dahan lub jego partnera na platformie podcastów. Jeśli uważasz, że ktoś wykorzystuje Twoje dzieło chronione prawem autorskim bez Twojej zgody, możesz postępować zgodnie z procedurą opisaną tutaj https://pl.player.fm/legal.

In this podcast we’ll be discussing the issues around supporting different kinds of service-level agreements in an SOA, and how using message prioritization helps and hurts. We’ll also be looking at alternative solutions more distributed in nature,which make use of specific deployment and configuration schemes that result in a more robust system.

Symon asks:

Hi Udi,

I don’t know if this is really an NServiceBus question or a more general architecture question, so if you want to treat it as an Ask Udi question feel free. 🙂 My question is about handling message prioritization between services in an SOA architecture using an ESB- in this case NServiceBus.

We’ve been running along nicely getting the hang of using the NServiceBus but have just hit a point in our application where it’s become clear that we’re going to need to prioritize messages between services according to an arbitrary set of rules. To that end we’ve created a “controller” that determines a message’s priority according to a set of rules and that controller should forward the message to other services for handling according to that priority. Where we’re stuck is figuring out the best way to handle the prioritization of the forwarded message.

We touched on the idea of having several endpoints representing low, medium or high priority and shunting the message to the appropriate endpoint, however since the receiving service consists of multiple workers located on other machines we need to have a dispatcher for each of these endpoints. Since we’re using MSMQ this seems to be causing an explosion of queues and the solution seems to require a lot of overhead in terms of set up, but it *does* look like it might be flexible as long as we come up with a smart dispatcher.

Is this an “ideal” way to handle message prioritization? I know there is a notion of priority in MSMQ messages, but this isn’t exposed in NServiceBus as far as I can tell.

Any suggestions?

Cheers,

Symon

Download

Download via the Dr. Dobb’s site

Or download directly here.

Additional References

Want more?

Check out the “Ask Udi” archives.

Got a question?

Send Udi your question to answer on the show.

  continue reading

21 odcinków

Wszystkie odcinki

×
 
Loading …

Zapraszamy w Player FM

Odtwarzacz FM skanuje sieć w poszukiwaniu wysokiej jakości podcastów, abyś mógł się nią cieszyć już teraz. To najlepsza aplikacja do podcastów, działająca na Androidzie, iPhonie i Internecie. Zarejestruj się, aby zsynchronizować subskrypcje na różnych urządzeniach.

 

Skrócona instrukcja obsługi