Замена TCP / IP-канала на WCF

Question

Так что в настоящее время моя компания использует соединение TCP / IP для связи между серверными и клиентскими программами, сейчас мы создаем это соединение с помощью System.RunTime.Remoting, который является неуклюжим и не настолько надежным. Он был построен около 5 лет назад, и модель продолжает использоваться повторно, и начинает распространяться информация о некоторых проблемах, используемых портах, отклоненных соединениях и т. Д.

Я пытаюсь найти некоторые ресурсы о том, как изменить это на WCF, но я не совсем уверен, что я ищу или что я должен искать.

Если вам нужна дополнительная информация о том, что на самом деле с ним происходит, я могу углубиться в некоторые детали, но мне нужно разобраться с кодом и убедиться, что я полностью его объясню.

спасибо!

Answer 1

Микаэль уже затронул большинство важных моментов в своем посте - выберите netTcpBinding, который достаточно быстр, отлично работает в локальной сети и обладает всеми необходимыми функциями.

Основным отличием будет изменение мышления: при удаленном взаимодействии вы в основном работаете с «удаленными объектами» - вы более или менее дистанционно управляете существующими объектами .NET на другом компьютере.

WCF сильно отличаетсяв основном: у вас есть сервер и клиент, и они не разделяют больше, чем контракт на обслуживание (описание методов) и контракты на данные (описание передаваемых данных).Во время выполнения вы делаете вызов прокси на клиенте, среда выполнения WCF перехватывает этот вызов, сериализует его (включая все параметры), а затем отправляет по кабелю сериализованное сообщение (двоично-сериализованное в случае netTcpBinding).

Сервер на другом конце имеет компонент времени выполнения, который прослушивает эти сообщения и извлекает их из сети, разворачивает их и затем вызывает экземпляр службы, чтобы запустить нужный метод.

Важная часть: это система, основанная на сообщениях - помимо контрактов (интерфейс службы и структуры данных, выраженные в XML-схеме), у вас нет соединения во время выполнения между двумясторон.

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

Кроме того: поскольку обмен данными проходит через сериализованные сообщения и должен соответствовать стандартам XML-схемы, вы не можете использовать такие вещи, как интерфейсы или универсальные шаблоны - вы можете только передавать конкретные экземпляры классов.

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

Answer 2

Есть старая, но хорошая статья под названием " Миграция .NET Remoting на WCF (и даже ASMX!) ", на которую вы должны взглянуть.

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

Что мне больше нравится в WCF, так это то, что вы должны создать свой прокси-объект, а затем выполнить вызовы. Вы можете гораздо легче увидеть, что вы делаете удаленный вызов. Remoting в некоторой степени скрывает это imo.

Стоит отметить, что настраивать события в WCF - это больше работы, чем в удаленном режиме, но это небольшая цена. Как только вы познакомитесь с WCF и узнаете, как его оптимально настроить для вашего конкретного сценария, вы не вернетесь назад. Он гораздо более гибкий, чем удаленное взаимодействие, и его можно использовать на больших расстояниях, в которых удаленное взаимодействие не слишком хорошо (из моего опыта).

Обязательно выберите транспортный канал в WCF для ваших нужд, будь то TCP, именованные каналы или мыло.