使用WCF而不是MassTransit或手写MSMQ客户端等框架有什么好处？

我正在考虑使用MSMQ作为在即将到来的项目中执行异步执行的解决方案.我想知道使用WCF和MassTransit等框架之间的区别,甚至是手写的MSMQ客户端来放置/读取MSMQ上的任务.

基本上,应用程序将是通过服务层(无论是WCF还是普通的Web服务)读取/写入数据的几个网站(内部通过LAN或通过Internet外部).然后,此服务层将执行以下两项操作之一:1.将数据写入数据库2.和/或通过在队列中放置消息来触发后台进程.3.显然它也可以从数据库中检索数据.队列另一端的小代理(Windows服务)将监视队列并根据任务命令执行.

与RPC或分布式执行或其他任何方式相比,此体系结构将非常容易扩展(添加更多队列和代理)并且易于实现.并且代理处理不需要是实时的.代理和服务层是单独的应用程序,除了它们共享公共域对象和存储库等.

你怎么看？欢迎对上述要求的架构建议.谢谢!

WCF在MSMQ上添加了一个抽象.实际上,一旦定义了兼容的合同(操作必须是OneWay),您就可以透明地在配置中切换出MSMQ.(例如,您可以切换到正常的HttpWS或NetTcp绑定.)

您应该评估其他WCF的好处,例如安全性等,以了解这些好处如何适合您的需求.同样,他们应该合理地透明你在下面使用MSMQ的事实.例如,添加SOAP安全性等应该"正常工作",与使用MSMQ无关.

(虽然,IIRC,你仍然需要在使用MSMQ的每台机器上登录桌面,使用MSMQ 的服务帐户,在机器本地配置文件中生成证书.然后,它不能很好地工作IIS6,因为没有加载用户配置文件.一般来说真的很痛苦,但与WCF没有任何关系.)

除此之外:

你看过SQL Server Service Broker吗？使用MSMQ + WCF和SSSB后,我认为SSSB是大大易于配置和管理.SSSB可以在任何SQL客户端上使用T-SQL命令(我在Mono上使用它,在Linux上使用事务).它也会给你交易发送/接收,甚至远程(我认为MSMQ 4现在允许这样做).消息排队真的需要很多痛苦,如果你已经使用SQL Server了......

SSSB经常被忽视,因为SQL Management Studio没有GUI设计器,但它并不难,而且是一个很好的选择.一个缺点是,如果您想要本地发送功能(即网络中断时的队列消息),您将需要运行本地SQL Express实例.