Действительно ли .NET Remoting устарел?

95

Все говорят, что .NET Remoting заменяется WCF, но мне интересно, насколько это точно. Я не встречал официального сообщения о том, что удаленное взаимодействие устарело, и мне кажется, что существуют сценарии, в которых удаленное взаимодействие имеет больше смысла, чем WCF. Ни один из объектов или методов, связанных с удаленным взаимодействием, не объявлен устаревшим даже в версии 4.0 платформы. Я также понимаю, что System.AddIn в фреймворках 3.5 и 4.0 использует удаленное взаимодействие.

Есть ли у кого-нибудь официальное заявление об обратном?

В статье Выбор параметров связи в .NET (для 3.0, поскольку это последняя версия этой статьи) говорится:

8 Обмен данными между приложениями

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

Конечно, это неверно, поскольку WCF, безусловно, можно использовать для пересечения границ доменов приложений, но дает ли он официальную рекомендацию для этого сценария?

Обновление: я отправил Клеменсу Вастерсу (который был в команде, владеющей удаленным взаимодействием и WCF) этот вопрос:

Клеменс, я понимаю, что вы входите в команду, которая владеет как удаленным взаимодействием, так и wcf, и у меня есть пара вопросов, которые, как мне кажется, мне нужно задать источнику.

Во-первых, у меня вопрос о том, исчезнет ли удаленное взаимодействие. В частности, у нас есть довольно большое приложение, которое широко использует удаленное взаимодействие для внутрипроцессного взаимодействия между доменами приложений, и мне было интересно, считается ли такое использование удаленного взаимодействия «устаревшим». Если да, будут ли заменены AppDomain.CreateInstance и друзья на что-то другое?

Это его ответ:

Удаленное взаимодействие является частью .Net Framework и никуда не денется. COM присутствует в Windows со времен Windows NT 3.5 / Windows 95 и никуда не делся, и я не думаю, что он исчезнет в ближайшее время.

Тем не менее, в Remoting вкладываются минимальные инвестиции. WCF является преемником удаленного взаимодействия и заменяет COM / DCOM управляемым кодом.

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

.net wcf remoting отметка
источник
1
См. Stackoverflow.com/questions/1295353/…, чтобы узнать, почему WCF намного медленнее, чем удаленное взаимодействие в моей конкретной ситуации.
Марк
1
Удаленное взаимодействие является неотъемлемой частью .NET, и подробности о роли, которую он играет и о том, как работает, можно найти в Essential .NET, написанном Доном Боксом и Крисом Селлсом. Однако он разваливается, когда межкомпонентная связь ненадежна или медленна, и практически все виды транспорта - даже гигабитная локальная сеть - ненадежны и медленны по сравнению с обменом сообщениями внутри процесса. Когда люди говорят о медленной работе WCF, они обычно имеют в виду веб-службы. Веб-сервисы работают слишком медленно, если вы пытаетесь использовать их для связи в процессе. Однако они рассчитаны на то, чтобы выдерживать медленные и ненадежные соединения и хорошо работать в этих условиях.
Peter Wone
3
@Peter: спасибо за информацию, но пара ваших предположений совершенно неверна. Во-первых, удаленное взаимодействие работает медленно или ненадежно. Это не. Это очень быстро и очень надежно (конечно, по надежным каналам). Другой - то, что «веб-сервисы» (что бы это ни значило) работают медленно. Они не. Конечно, все, что находится в процессе, будет намного быстрее, чем что-либо в сети, но вопрос совсем не об этом ...
Марк

Ответы:

54

Назвать это устаревшей технологией - более точное описание.

http://msdn.microsoft.com/en-us/library/72x4h507%28VS.85%29.aspx

Этот раздел относится к устаревшей технологии, которая сохраняется для обратной совместимости с существующими приложениями и не рекомендуется для новой разработки. Распределенные приложения теперь должны разрабатываться с использованием Windows Communication Foundation (WCF).

Обновление: WCF не делает различий между доменами между / внутри / процесса / между / внутри приложения. Если вы используете связь на одной машине в WCF, вы используете именованные каналы - их использование должно обеспечивать хорошую производительность практически во всех реалистичных сценариях.

Для сравнения производительности различных распределенных коммуникационных технологий см. Здесь .

RichardOD
источник
Разве эта статья не относится конкретно к использованию удаленного взаимодействия в межпроцессном взаимодействии? Мне кажется, что удаленное взаимодействие по-прежнему имеет место во взаимодействии между доменами приложений (AppDomain.CreateInstanceFromAndUnwrap и друзья).
Марк
Да, это так. Если бы эти классы были «устаревшими», к ним был бы применен атрибут ObsoleteAttribute - msdn.microsoft.com/en-us/library/system.obsoleteattribute.aspx .
RichardOD
2
@Mark, @RichardOD: Эта статья является основной по .NET Remoting. Это касается не только межпроцессного взаимодействия. Кроме того, тот факт, что атрибут ObsoleteAttribute отсутствует в .NET 3.5, ничего не значит, поскольку решение объявить Remoting (и веб-службы ASMX) «устаревшими» было принято после публикации .NET 3.5 RTM.
Джон Сондерс
@John: Они также не помечены [Устарело] в 4.0 (по крайней мере, пока).
Марк
@Mark: вы имеете в виду 4.0 beta 1.
Джон Сондерс,
11

Да. Удаленное взаимодействие устарело ... и официально от Microsoft. Вот ссылка:

Удаленное взаимодействие .NET

В первой строке статьи выделено жирным шрифтом:

Этот раздел относится к устаревшей технологии, которая сохраняется для обратной совместимости с существующими приложениями и не рекомендуется для новой разработки. Распределенные приложения теперь должны разрабатываться с использованием Windows Communication Foundation (WCF).

Я думал, что это словоблудие «устарело», но, видимо, они называют его «наследием»

Джастин Нисснер
источник
21
«Устаревший» IMO сильнее, чем «устаревший»: «устаревший» означает «не запускать», а «устаревший» означает «если вы уже начали, остановитесь сейчас, потому что он может быть полностью удален в будущих версиях».
ChrisW
1
@Mark: Я так не читаю. WCF кажется таким же применимым для внутрипроцессного взаимодействия, как и удаленное взаимодействие (см. NetNamedPipeBinding в WCF).
Майкл Петротта
1
@Mark: Тем не менее, удаленное взаимодействие устарело. @ChrisW: Я сомневаюсь, что удаленное взаимодействие будет удалено в ближайшее время, но вы можете ожидать меньшего количества исправлений ошибок, если таковые имеются, и меньшей поддержки, если таковые имеются.
Джон Сондерс,
1
@Mark - в чем ваш настоящий вопрос? Удаленное взаимодействие считается устаревшей технологией. Похоже, вы не хотите, чтобы это было правдой. У вас могут быть веские причины, но это не совсем соответствует текущим рекомендациям Microsoft.
Майкл Петротта
1
@ Джон: Думаю, да. Я специально занимаюсь внутрипроцессным взаимодействием между доменами приложений (с помощью AppDomain.CreateInstanceFromAndUnwrap и друзей), и я не вижу способа сделать это так чисто (или как высокопроизводительно) с помощью WCF. Я счастлив использовать вместо этого WCF (я часто использую его в других сценариях), но для этого мне трудно заставить его работать так, как я хочу. Я отправлю еще один вопрос об этом конкретном сценарии.
Марк
6

Если вы хотите перейти на .NET Core, вам все равно нужно найти другое решение для удаленного взаимодействия:

.NET Remoting была определена как проблемная архитектура. Он используется для связи между доменами приложений, которая больше не поддерживается. Кроме того, удаленное взаимодействие требует поддержки во время выполнения, что требует больших затрат на обслуживание. По этим причинам .NET Remoting не поддерживается в .NET Core, и мы не планируем добавлять его поддержку в будущем.

Источник: https://docs.microsoft.com/en-us/dotnet/core/porting/libraries#remoting

Жан-Клод
источник
1
Здесь вы можете найти обсуждение того, какие альтернативы доступны в .NET Core: github.com/dotnet/corefx/issues/18394
Жан-Клод,
Также упоминается здесь: docs.microsoft.com/en-us/dotnet/core/porting/…
Жан-Клод
2

Клеменс Вастерс, технический руководитель Microsoft .NET Service Bus (что означает как удаленное взаимодействие, так и WCF), в этом сообщении на форуме рассказывает о WCF и удаленном взаимодействии . Подводя итог посту, он в конечном итоге рекомендует WCF вместо удаленного взаимодействия.

Я не уверен, использует ли .NET 4.0 внутреннее удаленное взаимодействие, но вы можете попробовать отправить Клеменсу вопрос ... Я уверен, что он знает ответ.

JohannesH
источник
11
Сотрудник Microsoft рекомендует использовать новый метод блестящего нового несовместимости со всем остальным вместо любого стандарта? Шокирует.
quillbreaker
14
Каким образом WCF несовместим со всем остальным? А удаленное взаимодействие с чем было совместимо?
Джон Сондерс
2
Если вы ищете совместимость, выбор -only- - это WCF (конечно, кроме asmx, но это тоже «устаревший»). Удаленное взаимодействие никогда не подходило для сценариев, в которых требовалась совместимость.
Марк
3
Я принял ваше предложение и спросил Клеменса. Его ответ: «Удаленное взаимодействие - это часть .Net Framework, и поэтому оно никуда не денется ... Для внутрипроцессного взаимодействия между доменами удаленное взаимодействие - это родной способ общения CLR».
Марк
1
Далее он говорит, что вам следует «серьезно взглянуть на WCF и NetNamedPipeBinding».
Джон Сондерс,
2

Я думаю, что сейчас (2015 г.) это достаточно ясно даже для доменов кросс-приложений: https://msdn.microsoft.com/en-us/library/vstudio/ms180984(v=vs.100).aspx

Удаленное взаимодействие между доменами приложений Этот раздел относится к устаревшей технологии, которая сохраняется для обратной совместимости с существующими приложениями и не рекомендуется для новой разработки. Распределенные приложения теперь должны разрабатываться с использованием Windows Communication Foundation (WCF).

Тогда WCF следует использовать и для доменов с несколькими приложениями.

Армандо
источник