.NET Remoting

Материал из Википедии — свободной энциклопедии
Это старая версия этой страницы, сохранённая BPK (обсуждение | вклад) в 13:52, 23 июня 2009 (Краткий обзор). Она может серьёзно отличаться от текущей версии.
Перейти к навигации Перейти к поиску

.NET Remoting это созданный компанией Microsoft API для межпроцессного взаимодействия. Выпущен в 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 сложен, но его сущность проста. При помощи со стороны операционной системы и сетевых агентов, клиентский процесс отправляет сообщение серверному процессу и получает ответ.[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) для объекта создаётся исполняющей средой remoting в момент, когда сервер регистрирует канал, который будет использоваться для подключения к удалённому объекту. На клиентской стороне инфраструктура remoting создаёт proxy, который замещает собой удалённый объект, является его псевдоэкземпляром. Он не реализует функциональность удалённого объекта, но предоставляет похожий интерфейс. Как результат, инфраструктуре удалённого выполнения нужно знать публичный интерфейс удалённого объекта заранее. Любые вызовы методов, направленные объекту, включая идентификатор метода и любые передаваемые параметры, сериализуются в байтовый поток и передаются посредством канала связи, реализованного для конкретного протокола, принимающему прокси-объекту на серверной стороне («маршализируются»). Передача происходит путём записи данных в транспортный sink Канала.[5] На серверной стороне прокси читает поток из sink и выполняет вызов удалённого компонента от лица клиента. Результаты сериализуются и передаются через sink клиенту, где прокси читает результат и передаёт его вызывающему приложению.[5] Если удалённому объекту нужно сделать обратный вызов (callback) клиентскому объекту, клинетское приложение должно пометить его как remotable и заставить исполняющую среду remoting создать прослушиватель (listener) для него.[5] Сервер может подключиться к нему по другому Каналу, или по уже существующему если соединение, на котором он основан, поддерживает двунаправленный обмен данными.[5] A channel can be composed of a number of different Channel objects, possibly with different heterogeneous transports. Thus, remoting can also work across systems separated by an interconnection of heterogeneous networks, including the internet.[5] Type safety is enforced by the CTS and the .NET Remoting runtime. Remote method calls are inherently synchronous; asynchronous calls can be implemented using threading libraries. Authentication and access control can be implemented for clients by either using custom Channels or by hosting the remotable objects in IIS and then using the IIS authentication system.[6]

Примечания

  1. Software Technology Roadmap. Component Object Model and Related Capabilities. Carnegie-Mellon Software Engineering Institute (2001).
  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.
  4. 1 2 3 .NET Remoting Overview. Дата обращения: 23 октября 2007.
  5. 1 2 3 4 5 6 .NET Remoting Architecture. Дата обращения: 23 октября 2007.
  6. Security. MSDN. Дата обращения: 23 октября 2007.