与 MassTransit 或手写 MSMQ 客户端等框架相比，使用 WCF 有何优势？
我正在考虑使用 MSMQ 作为在我即将进行的项目中执行异步执行的解决方案。 我想知道使用 WCF 和 MassTransit 等框架甚至手写 MSMQ 客户端来放置/读取 MSMQ 任务之间的区别。
基本上，应用程序将是多个网站（通过 LAN 内部或通过 Internet 外部）通过服务层（无论是 WCF 还是普通 Web 服务）读取/写入数据。 然后，该服务层将执行以下两件事之一： 1. 将数据写入数据库 2. 和/或通过将消息放入队列来触发后台进程。 3.显然它也可以从数据库中检索数据。 队列另一端的小代理（Windows 服务）将监视队列并根据任务命令执行。
与 RPC 或分布式执行等相比，这种架构非常容易扩展（添加更多队列和代理）并且易于实现。 并且代理处理不需要是实时的。 代理层和服务层是独立的应用程序，除了它们共享公共域对象和存储库等。
您认为呢？ 欢迎针对上述需求提出架构建议。 谢谢你！
I am looking at using MSMQ as a solution to do asynchronous execution in my upcoming project. I want to know the differences between using WCF and frameworks like MassTransit or even hand written MSMQ client to place/read task off MSMQ.
Basically the application will be several websites (internal through LAN or external through the Internet) reading/writing data through a service layer (be it WCF or normal web service). Then this service layer will do one of two things: 1. write data to database 2. and/or trigger the background process by placing a message in the queue. 3. obviously it can also retrieve data from database. The little agent (a windows service) on the other side of the queue will monitor the queue and execute based on the task command.
This architecture will be quite easy to scale (add more queues and agents) and easy to implement compared to RPC or distributed execution or whatever. And the agent processing doesn’t need to be real time. And the agent and service layer are separate applications except they share the common domain objects and Repositories etc.
What do you think? Architecture suggestions for the above requirements are welcomed. Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
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 命令配合使用（我在 Linux 上的 Mono 中使用它并进行事务处理）。 它还将为您提供事务发送/接收，甚至是远程发送/接收（我认为 MSMQ 4 现在允许这样做）。 它确实减轻了消息队列的很多痛苦，如果您已经在使用 SQL Server...
SSSB 经常被忽视，因为 SQL Management Studio 没有这一切的 GUI 设计器，但这并不难是一个很好的选择。 一个缺点是，如果您需要本地发送功能（即在网络中断时对消息进行队列），则需要运行本地 SQL Express 实例。
WCF adds an abstraction over MSMQ. In fact, once you define compatible contracts (operations must be OneWay), you can switch out MSMQ in the config, transparently. (For instance, you could switch to normal HttpWS or a NetTcp binding.)
You should evaluate the other WCF benefits, like security and so on, to see how those fit in with your needs. Again, they should be reasonably transparent of the fact you're using MSMQ underneath. For instance, adding SOAP security and so on should "just work", independent of using MSMQ.
(Although, IIRC, you still need to login to the desktop on each machine that uses MSMQ, with the service account that will use MSMQ, to generate the certificate in the machines local profile. And then, it doesn't work very well from IIS6, since user profiles aren't loaded. A real pain in general, but nothing to do with WCF specifically.)
Apart from that:
Have you looked at SQL Server Service Broker? After using MSMQ + WCF and SSSB, I think that SSSB is vastly easier to configure and manage. SSSB works with T-SQL commands over any SQL client (I use it from Mono, on Linux, with transactions). It'll also give you transactional send/receive, even remotely (I think MSMQ 4 now allows this). It really takes a lot of the pain away from message queuing, and if you're using SQL Server already...
SSSB is often overlooked since the SQL Management Studio doesn't have GUI designers for it all, but it isn't hard and is a great option. The one downside is that if you want local send capability (i.e., queue message when network is down), you'll need to run a local SQL Express instance.
您的架构看起来健全且合理。 但是，您应该考虑使用 WCF 网络 MSMQ 传输而不是手动编码的 MSMQ 类。 WCF 将这种常见功能包装到一个很好的编程模型中。 另外我相信与基本的 System.Messaging 相比，wcf 使用的协议有一些改进
Your architecture seems sound and reasonable. However you should consider using the WCF net MSMQ transport over hand coded MSMQ classes. WCF wraps this common functionality into a nice programming model. Also I believe there is some improvements in the protocol used by wcf compared to basic System.Messaging
查看普通 MSMQ 的增值：
http://readthedocs .org/docs/masstransit/en/latest/overview/valueadd.html
总之，通过 MassTransit，您可以在 API 中清楚地了解许多消息传递概念； 在某种程度上，如果您手动编码或使用 WCF，则不会有这种情况。
Have a look at the value-add over plain MSMQ:
http://readthedocs.org/docs/masstransit/en/latest/overview/valueadd.html
In summary, you get a lot of messaging concepts clearly presented in the API with MassTransit; to an extent you wouldn't have if you hand-coded it or used WCF.