.NET Remoting

.NET Remoting — компонент, созданный компанией Microsoft. API для межпроцессного взаимодействия. Реализация от Microsoft протокола SOAP (веб-сервисы). Выпущен в 2002 году вместе с версией 1.0 пакета .NET Framework. Это одна из серии технологий от Microsoft, начатой в 1990 году первой версией OLE для 16-разрядной Windows. Промежуточными шагами в разработке подобных технологий были COM, выпущенная в 1993 году и доработанная в 1995 году под названием COM-95, DCOM, выпущенная в 1997 году (и переименованная в ActiveX), и COM+ с её Microsoft Transaction Server (MTS), выпущенная в 2000 году^[1]. В данный момент на смену .NET Remoting пришёл WCF, являющийся частью .NET Framework 3.0.

Так же, как и все члены данного семейства и подобные технологии, например CORBA и RMI, функция .NET Remoting заключается в следующем: при поддержке со стороны инфраструктуры .NET Remoting, клиентский процесс отправляет сообщение серверному процессу и получает ответ^[2]^[3].

Краткий обзорПравить

.NET Remoting позволяет приложению создать объект, (именуемый remotable object) доступный в рамках remoting boundaries и расположенный в домене приложения внутри одного процесса, в другом процессе, исполняющемся на этом компьютере или даже на другом компьютере, соединённом сетью^[4]. Процесс .NET Remoting содержит приёмник запросов к объекту в домене серверного приложения. На стороне клиента любые запросы к удалённому объекту направляются средой выполнения .NET Remoting через объекты Channel, являющиеся обёрткой для средств транспортного уровня, таких как потоки TCP, потоки HTTP и именованные каналы. В результате запросы к удаленным объектам для клиентского кода ничем не отличаются от локальных вызовов, а созданием экземпляра нужного Channel-объекта приложение .NET Remoting можно без перекомпиляции перевести на другой коммуникационный протокол. Среда выполнения сама по себе выполняет этапы сериализации и маршалинга объектов в среде между клиентским и серверным доменами приложения^[4].

.NET Remoting делает ссылку на удалённый (remotable) объект доступной клиентскому приложению, которое затем направляет запросы к экземпляру удалённого объекта так, как если бы это был локальный объект^[4]. Однако, фактическое исполнение кода происходит на серверной стороне. Удалённый объект имеет идентификаторы в форме URL активации. В зависимости от конфигурации серверного процесса экземпляр удаленного объекта создаётся при подключении по данным URL^[5] в момент создания ссылки на удалённый объект или в момент первого обращения к удалённому объекту. Прослушивающий приёмник (listener) для объекта создаётся исполняющей средой .NET Remoting в момент, когда сервер регистрирует канал, который будет использоваться для подключения к удалённому объекту. На клиентской стороне инфраструктура .NET Remoting создаёт объект-заместитель (proxy), который является псевдоэкземпляром замещаемого объекта. Он не реализует функциональность удалённого объекта, но предоставляет похожий интерфейс, перенаправляя все запросы серверному объекту и возвращая результаты от него клиенту . Как следствие, инфраструктуре .NET Remoting для создания заместителя нужно обладать метаданными, описывающими публичный интерфейс удалённого объекта. Это можно обеспечить статическим связыванием со сборкой, содержащей метаданные, во время компиляции или динамическим получением метаданных в виде WSDL или проприетарного формата, разработанного фирмой Microsoft.

В процессе выполнения запросов любые вызовы методов, направленные объекту, включая идентификатор метода и любые передаваемые параметры, сериализуются в байтовый поток и передаются посредством канала связи, реализованного для конкретного протокола, принимающему прокси-объекту на серверной стороне («маршализируются»). Передача происходит путём записи данных в транспортный ввод канала^[5]. На серверной стороне прокси читает поток данных из вывода канала и выполняет вызов удалённого компонента от лица клиента. Результаты сериализуются и передаются через канал клиенту, где прокси читает результат и передаёт его вызывающему приложению^[5].

Если удалённому объекту нужно обеспечить обратный вызов (callback) клиентскому объекту, клиентский объект обратного вызова должен быть помечен как remotable, а инфраструктура .NET Remoting должна быть сконфигурирована на создание прослушивателя для него^[5]. Сервер может подключиться к нему по другому каналу или по уже существующему, если соединение, на котором он основан, поддерживает двунаправленный обмен данными^[5]. Канал может быть составлен из нескольких канальных объектов, возможно, даже с разными транспортными механизмами. Таким образом, система, основанная на .NET Remoting, может состоять из нескольких подсистем, связанных подключёнными друг к другу гетерогенными сетями, включая Интернет^[5]

ПримечанияПравить

↑ Cornella-Dorda, Santiago. Component Object Model and Related Capabilities (англ.). Carnegie-Mellon Software Engineering Institute (13 марта 2001). Архивировано 15 мая 2008 года.
↑ Scott McLean, James Naftel and Kim Williams. Microsoft .NET Remoting (англ.). — Microsoft Press (англ.) (рус., 2002.
↑ Ingo Rammer and Mario Szpuszta. Advanced .NET Remoting (англ.). — Apress, 2005.
↑ ¹ ² ³ .NET Remoting Overview (англ.). Дата обращения: 23 октября 2007. Архивировано 30 июня 2007 года.
↑ ¹ ² ³ ⁴ ⁵ ⁶ ..NET Remoting Architecture (англ.). Дата обращения: 23 октября 2007. Архивировано 8 июня 2007 года.

[1] Cornella-Dorda, Santiago. Component Object Model and Related Capabilities (англ.). Carnegie-Mellon Software Engineering Institute (13 марта 2001). Архивировано 15 мая 2008 года.

[2] Scott McLean, James Naftel and Kim Williams. Microsoft .NET Remoting (англ.). — Microsoft Press (англ.) (рус., 2002.

[3] Ingo Rammer and Mario Szpuszta. Advanced .NET Remoting (англ.). — Apress, 2005.

[overview-4] ¹ ² ³ .NET Remoting Overview (англ.). Дата обращения: 23 октября 2007. Архивировано 30 июня 2007 года.

[arch-5] ¹ ² ³ ⁴ ⁵ ⁶ ..NET Remoting Architecture (англ.). Дата обращения: 23 октября 2007. Архивировано 8 июня 2007 года.

[1]

[2]

[3]

[4]

[5]