SQL Server 消息代理 - 外部激活
我在受限网络内有一个 Sql Server。我需要以某种方式从外向内获取数据。
我想利用消息代理的使用。我的想法是外部数据库将消息放在队列中，然后我需要位于受限 LAN 内部的服务来侦听（轮询？）这些消息，然后对它们采取行动。 我无法让外部队列启动与受限 LAN 的正常代理对话。
我的问题是，我是否应该查看代理外部激活器以使其位于受限 LAN 内并侦听新消息，然后对其采取行动？有没有人有这方面的经验。外部激活器的文档/示例非常薄弱，并且消息代理尚不支持独白。
msmq 是更好的选择吗？
I have a Sql Server inside a restricted network. I need to somehow get data from the outside in.
I would like to harness the use of Message Broker. My thinking is the external db places a message on a queue then I require a service that sits inside of the restricted LAN to listen (poll?) for these messages and then act upon them.
I cannot have the external queue initiate the normal broker conversation into the restricted LAN.
My question is should I be looking at the broker external activator to sit inside the restricted LAN and listen for new messages and then act upon them? Has anyone got any experience with this. Documentation / examples for external activator are pretty thin on the ground and monologues are not supported in message broker yet.
Is msmq a better option?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我的建议是允许 Service Broker 将消息一直传送到受限 LAN 内的 SQL Server 实例中。这将需要受限 LAN 允许传入连接（允许内部服务器侦听和接受）。 MSMQ 也不例外，MSMQ 端口必须在受限 LAN 中打开。
如果您想在受限制的 LAN 内使用专用进程“获取”内部数据，则必须确保外部服务器“获取”和内部服务器写入之间的事务一致性：这两个操作必须注册到分布式事务中并且需要允许DTC协议本身渗透到受限制的LAN中。所以在受限制的局域网中仍然需要开放一些端口。
LAN 安全设计人员需要了解的是，Service Broker 连接不是 Transact-SQL 连接。 Service Broker 使用专用协议，仅允许交换 Service Broker 消息。所有流量均通过 RC4 或 AES 加密进行加密和保护。 SSB 加密符合 FIPS 标准。允许 Service Broker 流量到达内部 SQL Server 可能是允许来自外部服务器的数据到达安全服务器的最安全方法。在 Service Broker 网络中，没有“客户端”和“服务器”的概念，并且无法设计仅允许在一个方向上进行连接的网络（例如，与 HTTP 不同，HTTP 可以设计为从内到外连接，但不能以其他方式进行连接） ）。 SSB 网络要求涉及的两台机器能够相互连接，因为响应消息可能会在很长的延迟（几小时、几天，考虑队列备份时的情况）之后出现，因此需要很长时间才能处理消息并且响应已发送）。不可能让连接保持开放数天以期望得到响应，因此消息的接收者必须能够连接回发送者以传递响应。
My recommendation would be to allow Service Broker to deliver the message all the way into the SQL Server instance inside the restricted lan. That will require the restricted LAN to allow incomming connection (allow the inside server to listen and accept). MSMQ would be no different, the MSMQ port(s) would have to be open in the restricted LAN.
If you want to use a dedicated process inside the restricted LAN that 'gets' the data inside then you must ensure the transactional consistency between the external server 'get' and the internal server write: the two operation have to be enrolled into a distributed transaction and the DTC protocol itself needs to be allowed to penetrate into the restricted LAN. So some ports still need to be open in the restricted LAN.
What your LAN security designers need to understand is that Service Broker connections are not Transact-SQL connections. Service Broker uses a dedicated protocol that only allows exchange of Service Broker messages. All traffic is encrypted and secured with RC4 or AES encryption. SSB cryptography is FIPS compliant. Allowing for Service Broker traffic to the SQL Server inside is probably the most secure way of allowing data from the external server to reach the secured server. In Service Broker networking there is no concept of 'client' and 'server' and one cannot design the network allowing connections only in one dirrection (eg. unlike say HTTP, which can be designed to connect from inside to outside but not the other way). SSB networking requires both machines involved to be able to connect to each other, because response messages can come after long delays (hours, days, consider the case when a queue is backed up so it takes a long time until the message is processed and a response is sent). IS not feasable to keep connecitons open for days to expect a response, so the receiver of a message must be able to connect back to the sender to deliver a response.