Брокер сообщений SQL Server — внешняя активация

У меня есть сервер Sql внутри сети с ограниченным доступом. Мне нужно как-то получить данные извне.

Я хотел бы использовать использование Message Broker. Я думаю, что внешняя база данных помещает сообщение в очередь, тогда мне требуется служба, которая находится внутри ограниченной локальной сети, чтобы прослушивать (опрашивать?) Эти сообщения, а затем действовать в соответствии с ними. Я не могу заставить внешнюю очередь инициировать обычный диалог брокера в локальной сети с ограниченным доступом.

Мой вопрос: должен ли я смотреть на внешний активатор брокера, чтобы сидеть внутри ограниченной локальной сети и слушать новые сообщения, а затем действовать в соответствии с ними? Есть ли у кого опыт в этом. Документация/примеры для внешнего активатора довольно скудны, а монологи пока не поддерживаются в брокере сообщений.

Является ли msmq лучшим вариантом?


sql-server messagebroker msmq service-broker
person redsquare    schedule 08.09.2009    source источник
comment
насколько ограничена локальная сеть? может ли внешний db установить TCP-соединения с сервером sql внутри?   -  person Remus Rusanu    schedule 08.09.2009
comment
нет, это не разрешено. Он не может инициировать диалог (по крайней мере, это то, над чем мы работаем, правила безопасности нечеткие)   -  person redsquare    schedule 09.09.2009

Ответы (1)


arrow_upward
2
arrow_downward

Я бы рекомендовал разрешить Service Broker полностью доставлять сообщение в экземпляр SQL Server внутри локальной сети с ограниченным доступом. Для этого потребуется ограниченная локальная сеть, чтобы разрешить входящее соединение (разрешить внутреннему серверу слушать и принимать). MSMQ ничем не отличается, порт(ы) MSMQ должны быть открыты в локальной сети с ограниченным доступом.

Если вы хотите использовать выделенный процесс внутри локальной сети с ограниченным доступом, который «получает» данные внутри, вы должны обеспечить согласованность транзакций между «get» внешнего сервера и записью внутреннего сервера: две операции должны быть зарегистрированы в распределенной транзакции. а самому протоколу DTC необходимо разрешить проникновение в ограниченную локальную сеть. Таким образом, некоторые порты все еще должны быть открыты в локальной сети с ограниченным доступом.

Разработчики безопасности локальных сетей должны понимать, что соединения Service Broker не являются соединениями Transact-SQL. Service Broker использует выделенный протокол, который позволяет обмениваться только сообщениями Service Broker. Весь трафик зашифрован и защищен шифрованием RC4 или AES. Криптография SSB соответствует требованиям FIPS. Разрешение трафика Service Broker на внутренний SQL Server, вероятно, является наиболее безопасным способом обеспечения доступа данных с внешнего сервера к защищенному серверу. В сети Service Broker нет понятия «клиент» и «сервер», и нельзя спроектировать сеть, допускающую соединения только в одном направлении (например, в отличие, скажем, от HTTP, который может быть разработан для соединения изнутри наружу, но не в обратном направлении). ). Сеть SSB требует, чтобы обе задействованные машины могли подключаться друг к другу, потому что ответные сообщения могут приходить после длительных задержек (часы, дни, рассмотрим случай, когда очередь резервируется, поэтому требуется много времени, пока сообщение будет обработано и ответ отправлен). НЕВОЗМОЖНО держать соединения открытыми в течение нескольких дней, чтобы ожидать ответа, поэтому получатель сообщения должен иметь возможность обратного подключения к отправителю для доставки ответа.

person Remus Rusanu    schedule 09.09.2009