Какой из них лучше Remoting или WebServices в .NET?

Question

Это может быть новичок, но я хочу знать,

В чем основное отличие между Remoting или WebServices?

Какой из них лучше?

Answer 1

«Лучше» довольно обстоятельно.

Remoting использует двоичную сериализацию, поэтому занимает меньше места по проводу и, как правило, быстрее, но работает только с .net на обоих концах. Версии вашей DLL должны совпадать, и вы можете размещать конечные точки сервера в приложениях, не требуя IIS.

Webservices являются более гибкими, поскольку они выполняются с использованием XML, предназначены для взаимодействия с другими поставщиками (Java, Python и т. Д.).

В качестве альтернативы, посмотрите на WCF (Windows Communication Foundation), так как это происходит в мире .net. Он позволяет вам писать код один раз, а затем размещать его на разных конечных точках.

Answer 2

«Что лучше» - это относительное сравнение, которое может быть определено только по вашему сценарию. Оба этих механизма для реализации распределенных приложений существуют по разным причинам, и для вас важно выбрать тот, который наиболее подходит для вашей установки.

Имейте в виду, что вся инфраструктура Webservices основана на структуре Remoting. IOW, Webservices - это абстракция, созданная с помощью Remoting. Поэтому, хотя веб-службы ASP.NET обеспечивают гораздо более простую модель программирования и большую интероперабельность, Remoting предлагает полную гибкость и мощь пространства имен System.Net.Remoting, требует гораздо больше технических ноу-хау и имеет меньшую функциональную совместимость. Тем не менее, удаление с использованием TCP, несомненно, лучше, чем Webservices через HTTP.

Вот MSDN article, который объясняет, какой из них выбрать, при каких обстоятельствах. And another, который подробно описывает различия.

Answer 3

Это зависит от того, что вы хотите сделать; удаленность исчезает из-за истинных «отдаленных» сценариев; в общем случае для связи между системами было бы предпочтительнее использовать сервисный интерфейс, например, через WCF.

Remoting по-прежнему ценен для связи между AppDomains в одном приложение.

Обратите внимание, что удаленный доступ недоступен для всех .NET-фреймворков - например, Silverlight не поддерживает удаленный доступ, но WCF и такие вещи, как http/(raw) сокеты, прекрасны.

Если вы можете, посмотрите на WCF. Если WCF не является вариантом, посмотрите на обычные веб-сервисы.

В частности, проблемы с Remoting:

• она связывает клиент и сервер для.NET
• она связывает клиент и сервер в том же двоичную реализацию
• это, как правило, приводит к плохо рассматриваемым границам (это очень легко просачиваться неправильными объекты по проводам, которые могут привести к большим проблемам латентности)

и т.д.

Re performance; remoting использует двоичную сериализацию, которая в некоторых случаях является полезной, проблематична в других (см. выше маркеры). Веб-службы, как правило, основаны на xml (хотя существуют и другие форматы) - и составляют контракт на основе (а не на основе реализации) - то есть клиент и сервер могут иметь разные типы, представляющие объекты, если они достаточно похожи.

Также возможно использовать двоичные файлы на веб-сервисах; например, protobuf-net предоставляет WCF-крючок для использования бинарного (контрактного) формата «буферов протокола» Google в отношении службы WCF (оговорка: это протокол на заказ, и вам понадобится инструмент с обоих концов).

Есть и другие способы говорить между системами, все из них, возможно, предпочтительнее Remoting (даже если они менее универсальны - иногда, минималистская добродетель):

• розетка (пользовательские сообщения)
• HTTP (простой POX сообщения и т.д.)
• среднего изделия (MSMQ, BizTalk и т.д.)