Reading the MassTransit docs on RPC/Request/Response processing. It got me to wondering what are the pros/cons of using MassTransit for RPC versus using WCF for RPC?scott_m
--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/9e113080-1357-4f24-9c78-e7955eaf617b%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Theres a lot of 'depends' in there.MassTransit uses 'MQ' systems and these are typically not the 'best' (in terms of performance and probably other things) for Request/Response patterns.WCF can use both MQ systems as well as HTTP or TCP/IP protocols. Its the non-MQ protocols which are better suited for R/R.Does that help??
On Fri, Dec 13, 2013 at 3:35 PM, Scott McFadden <scott.kenda...@gmail.com> wrote:
Reading the MassTransit docs on RPC/Request/Response processing. It got me to wondering what are the pros/cons of using MassTransit for RPC versus using WCF for RPC?scott_m
--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.
Message backed WCF mainly provides durability for the caller. The pros of wcf solution is that the message durability is a concern handled under the covers. The con is that I don't know that you can get to the raw messages that WCF uses during the call if you wanted to. And if you can, you're probably setting yourself up for heartache. The advantage for MT is that it's designed for building loosely coupled distributed systems. So if a message contract represents your call, multiple components can process the message independently of each other. I.E. one that does the actual work, and the other that does logging or auditing. Using interfaces a single handler could receive all messages for auditing, while other handlers are specific to each message. With that said though, you could probably solve your immediate use-case by using Aop or a wcf interceptor for each call and then write a message to MQ for processing.
You might want to check out Davy Brion's request response service layer. I've used a similar pattern for projects in the past where we wanted WCF message-based contracts but didn't need async or message backed durability for the caller.
HTH.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/6f15b188-ae9f-4d1b-8de4-afaff90a48b0%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/6f15b188-ae9f-4d1b-8de4-afaff90a48b0%40googlegroups.com.