Использование WCF для выполнения кода и возврата объектов в другое адресное пространство CLR

Question

После прочтения я понял, что .NET Remoting - устаревший API, который был заменен WCF.

Я пишу инфраструктуру автоматизации и хотел бы сослаться на DLL с типами / методами либо локально, либо на некоторой удаленной машине, и выполнять их независимо от того, где они выполняются.

Я подумал, что удаленный доступ - это путь, так как я полагаю, что все функции выполняются на прокси-объекте, что делает его неактуальным, если это локальный объект или удаленный.

Как WCF может выполнять такие действия (если они вообще есть) или .NET Remoting - это путь?

Или, может быть, какой-то другой вариант, о котором я не подумал?

Answer 1

Насколько мне известно, не существует волшебного способа назвать метод полностью прозрачным, независимо от того, на какой машине его запускать, включая .NET Remoting. Однако WCF широко использует прокси-серверы, которые либо генерируются автоматически из документов WSDL, либо напрямую ссылаются на типы / интерфейсы из общей библиотеки DLL.

Таким образом, вы можете создать совместно используемую dll, содержащую некоторые методы, добавить некоторые сантехнические функции WCF (т. Е. Создать интерфейс службы из методов / типов, которые вы хотите представить), а затем решить, использовать ли их непосредственно / локально в вашем проекте, или получить доступ к ним через прокси. Это позволяет довольно легко вызывать методы удаленно. Однако обратите внимание, что вы не можете создавать полноценные классы, которые предоставляют состояние и функциональность удаленно, память, содержащая реальные объекты, не используется совместно, это, в конце концов, всего лишь «трюк».

В зависимости от настроек вы можете:

• Использовать Именованные каналы для внутримашинной связи (самый быстрый)
• Используйте TCP для связи в интрасети (также довольно быстро)
• Использовать HTTP / HTTPS для интернет-связи (самый медленный)

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

Праймер для WCF можно найти здесь .

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

Для C # есть две реализации известных мне буферных протоколов: Protobuf CSharp от Jon Skeet и Protobuf-net от Marc Gravell.

Последнее замечание, чтобы было ясно; нет, WCF не не позволяет полностью абстрагироваться от расположения типов / методов.

Answer 2

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

WCF имеет прокси-объекты, такие как .NET remoting ... тогда как в .NET remoting прокси-объекты являются объектами MarshalByRef, в WCF прокси-объекты являются интерфейсами иликлассы, приписываемые атрибуту ServiceContract.

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

http://msdn.microsoft.com/en-us/library/system.runtime.remoting.proxies.realproxy.aspx.

В конце дняПрактически все, что вы ранее использовали для .NET Remoting, может быть сделано с помощью WCF.Единственное, что я знаю о том, что действительно функционирует по-разному, - это понятия асинхронных обратных вызовов (которые, IMHO, в любом случае не очень хорошо работали в .NET Remoting).

Answer 3

WCF использует подход SOA:

Вы можете определить ServiceContracts и DataContracts,
однако вы не можете выставлять объекты как с состоянием, так и с функциональностью.

ServiceContract - это объект, срок жизни которого не связан с таковым из DataContracts, он может быть либо единичным, либо созданным при каждом вызове.

DataContracts - это просто тупые данные, передаваемые обратно между сервером и клиентом.
Клиенту доступны только их члены DataMembers.

ServiceContracts предоставляет клиенту все методы в виде OperationContracts, которые могут получать и возвращать DataContracts.

WCF создает прокси для ServiceContract и DataContracts на стороне клиента, поэтому вам не нужно думать о отправке / получении пакетов и т. Д., Когда вы пишете сервис или используете его.

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