SQL Service Broker 2008 中的 Monolog 对话
我有一个场景，我需要处理（在 SQL Server 中）作为文件夹中的 .xml 文件实时传递的消息。
我开始研究 SQL Service Broker 来满足我的排队需求。基本上，我希望 Service Broker 拾取我的 .xml 文件，并在它们到达文件夹时将它们放入队列中。但是，SQL Service Broker 不支持“Monolog”对话，至少在当前版本中不支持。它仅支持启动器和目标服务之间的对话。
我可以使用 MSMQ，但之后我需要维护两件事 - MSMQ 中用于文件处理的 .Net 代码和 SQL Server T-SQL 存储过程。我还有哪些选择？
谢谢。
I have a scenario in which I need to process(in SQL Server) messages being delivered as .xml files in a folder in real time.
I started investigating SQL Service Broker for my queuing needs. Basically, I want the Service Broker to pick up my .xml files and place them in a queue as they arrive in the folder. But, SQL Service Broker does not support "Monolog" conversations, at least not in the current version. It supports only a dialog between an initiator and a target service.
I can use MSMQ but then I will have two things to maintain - the .Net Code for file processing in MSMQ and the SQL Server T-SQL stored procs. What options do I have left?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您需要利用 FileSystemWatcher 来监视目录。您的实现可以简单地响应新文件并使用事件对文件的处理进行排队（如果这能让您的生活更美好，可以在 Service Broker 中实现）。
正如其他发帖者所提到的，您确实把事情搞倒了：Service Broker 响应消息；Service Broker 响应消息；Service Broker 响应消息；Service Broker 响应消息；Service Broker 响应消息；必须有人发送消息才能对其做出响应。它不是通用服务主机进程。根据功能集和横向扩展/纵向扩展要求，您可能需要查看 BizTalk，因为这是使用它实现的非常常见的模式，并且它拥有大量基础设施来支持所有正交的“开展业务的成本”组件，从而使事情要可靠并且确实有效。
一旦您自己编写/调试完所有必需的代码，您通常会发现您花费的费用比许可证费用还要多。不过，这一切都与要求有关。
You'll want to leverage the FileSystemWatcher to monitor the directory. Your implementation can simply respond to new files and use the event to queue processing of the file(s) (which could implemented in Service Broker if that makes your life better).
As the other posters have mentioned, you're really got things backwards: Service Broker responds to messages; someone must send a message for it to respond to. It is not a generic service host process. Depending on the feature set and scale out/up requirements, you might want to look at BizTalk as this is a very common pattern implemented with it and it has TONS of infrastructure to support all the orthagonal "cost of doing business" components to make the thing be reliable and actually work.
Once you're done writing/debugging all the required code on your own you'll often find you've spent more $ than the licenses cost. Again though, it's all about requirements.
没有任何。您的整个想法已经被打破 - 因为您必须从目录中获取文件，所以使用服务代理根本没有意义。您需要一个监听进程，因此您也可以让监听进程进行处理。
None. The whole idea you have is broken - as you have to pick up the files from a directory, the use of service broker simply does not make sense to start with. YOu need a listening process, so you can have the listening process do the processing, too.