Связывание WCF для TCP-сервера, отличного от WCF

Question

У меня есть старая служба Windows без WCF, которая создает TCPClient для подключения к TCP-серверу без WCF. Я не могу изменить приложение сервера вообще. Он пытается создать 2 потока, один для чтения и обработки сообщений с Сервера, а другой для чтения из очереди MSMQ, обработки, а затем для отправки на TCP-сервер. К сожалению, есть проблемы, и иногда, если есть отключение от сети, я получаю два экземпляра потоков чтения или записи. Потоки используют одно и то же соединение TCPClient.

Хотел переключить мою службу на WCF, размещенную службой Windows. Я знаю, что мог бы использовать привязку MSMQIntegration для метода отправки, но я не уверен, как можно привязать к общему TCP-соединению. Похоже, что netTCPBinding также ограничен соединениями WCF и WCF. У кого-нибудь есть предложения, как поступить?

Answer 1

Библиотека WCF - это библиотека, которая позволяет разработчикам взаимодействовать между службами WCF и не-WCF независимо от протокола.Разработчикам сервисов, использующим WCF, не нужно знать детали протокола, используемого между этими сервисами, потому что эти сложности скрыты в привязках WCF.Таким образом, разработчики сервисов должны просто правильно настроить конечные точки / привязки / поведения своих клиентов или серверов, и эти конечные точки / привязки / поведения выполняют всю работу.

Но WCF не является универсальной платформой для связи с «чем-либо».Например, NetTcpBinding использует TCP-сокеты для связи.Протокол TCP позволяет создать конвейер между обеими сторонами, но когда этот конвейер установлен, TCP не указывает и не предписывает, какой контент следует передавать через этот конвейер.Это может быть какой-то стандартизированный протокол, такой как HTTP, или собственный проприетарный протокол, изобретенный разработчиком ПО, который никогда не был опубликован.Существуют сотни, может быть, тысячи пользовательских протоколов, которые могут проходить через TCP, включая такие протоколы, как Modbus через TCP или IEC104.Эти 2 протокола, например, были специально разработаны, чтобы быть крошечными для связи со встроенными устройствами и не могут использоваться в качестве протоколов для обмена универсальными сообщениями между веб-службами.

NetTcpBinding отправляет через конвейер TCP свой собственный полностью независимый протоколразработанный MS для обеспечения эффективной связи с сервисами WCF, основанными на NetTcpBinding.Его нельзя использовать для связи с вашей пользовательской службой, используя какой-то неизвестный протокол с различными (неизвестными) сериализацией данных, синхронизацией, безопасностью, схемами обмена данными и т. Д.

Так что единственно приемлемым вариантом здесь является использование«сырые сокеты» - классы типа Socket или TcpClient для связи с вашей проприетарной службой.Но сначала вы должны знать, какой протокол использует ваш TCP-сервер.Может быть, это какой-то стандартизированный протокол, такой как SOAP или HTTP, или полностью независимый проприетарный протокол, который никогда не публиковался и не документировался.

И даже несмотря на то, что WCF имеет много опций расширяемости, которые позволяют разработчикам расширять библиотеку WCF, эти опции расширяемости предназначены дляиспользоваться, если вы хотите разрешить WCF взаимодействовать через другой транспортный протокол (UDP, последовательная линия, общий сетевой путь) или добавить некоторые новые функции в привязки WCF, такие как новая опция безопасности, некоторая расширенная поддержка транзакций или ведение журнала.Но расширение WCF для связи с какой-либо проприетарной службой, отличной от WCF (с использованием некоторого самодельного протокола), будет неэффективным (возможно, невозможным) и чрезмерно сложным.

Так что, если ваша служба не-WCF не использует протоколэто очень близко (практически то же самое), что и протокол NetTcpBinding, тогда WCF здесь не вариант.Используйте Socket или TcpClient классы.

Answer 2

Это теоретически возможно с расширяемостью WCF, но вам придется написать собственную конечную точку, пользовательский форматировщик сообщений и пятьдесят других классов. Я бы рекомендовал реализовать службу TCP отдельно.

Расширяемость WCF лучше всего рассматривать, когда вы имеете дело с SOAP-подобным сервисом, который использует XML-подобные сообщения через стандартную конечную точку (транспорт). Когда вы «достаточно близки» к этому, вы обычно можете исправлять различия. Когда вы не используете ничего из этого, WCF становится помехой, а не экономит время. Например, я бы использовал расширяемость WCF, если:

• У меня был сервис SOAP, который должен был работать через SMTP или какой-то другой нечетный транспорт (пользовательская конечная точка)
• У меня был пользовательский формат xml, который работает на стандартной конечной точке (I*MessageInspector)
• У меня был пользовательский формат, который можно легко преобразовать в XML, работающий через стандартную конечную точку (пользовательский кодировщик сообщений)

Я бы не использовал WCF для:

• Любой формат, который не конвертируется легко в XML
• Любой формат, в котором трудно определить метод Action / target
• REST-сервисы (несмотря на внутреннюю поддержку - посмотрите MVC Web API)
• Все, что требует транспортировки больших двоичных двоичных объектов (если MTOM не покрывает это)
• Услуги, в которых необходимо заменить более одного встроенного компонента