Терминология .Net Remoting

Как и любая другая технология .NET Remoting вводит свои термины и понятия. Рассмотрим основные термины, связанные с удаленным доступом в .NET.

MarshalByRefObject

Имеется два способа, которыми клиент может взаимодействовать с объектами, расположенными на сервере. Во-первых, мы можем передавать клиенту ссылку на объект, выполняющийся на сервере. Клиент будет осуществлять вызовы по этой ссылке. Как будто это локальный объект. Однако когда производятся вызовы, ссылка будет на самом деле передавать вызовы в серверный процесс, там исполнять запрос и при помощи маршалинга передавать результаты обратно клиенту. Объекты, которые доступны через удаленный доступ как MarshalByRefObject, исполняются на сервере; на стороне клиента не выполняется никакой работы. Клиент имеет объект-прокcи, который отвечает за взаимодействие с сервером. Объект на сервере наследуется от System.MarshalByRefObject, который является базовым классом для того, чтобы позволить клиенту взаимодействовать с прокcи-объектами.

Сериализуемый (ByValue - по значению)

В отличие от MarshalByRefObject; мы можем реализовать объект, который, будучи созданным, передается назад клиенту. Клиент запрашивает объект у сервера, сервер создает этот объект, сериализует его в текстовое или двоичное представление и полностью передает его клиенту. Как только клиент получает этот объект в сое распоряжение, между клиентом и сервером не происходит никакого взаимодействия. Все вызовы выполняются относительно объекта, который выполняется на стороне клиента, как будто клиент сам создал этот объект. Сериализуемые объекты часто называются «Передаваемыми» (маршализуемыми) по значению, чтобы подчеркнуть то, что клиенту передается весь объект целиком, а не только ссылка на него.

В .NET все, что мы должны сделать, чтобы передавать наш объект от сервера к клиенту по значению -это предоставить атрибут Serializable. Структура удаленного доступа сама позаботится об упаковке объекта, пересылке его к клиенту и воссоздании его в пространстве клиента.

Форматер

Когда данные передаются между процессами при помощи Remoting или веб-служб, они должны посылаться в формате, понимаемом как клиентом, так и сервером. Существует возможность создать свой собственный форматер, который определяет, какие передаются данные, к какому типу они относятся, и так далее. Стек, используемый на сервере для упаковки данных, будет точно таким же, как и стек, используемый в клиенте для их распаковки.

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

В дополнение к предоставлению возможности создавать ваш собственный форматер, структура удаленного доступа предлагает два готовых форматера - двоичный форматер и форматер SOАР.

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

Однако эффективность двоичного форматера имеет свою цену; его выходной поток не является читабельным для человека и ограничен теми платформами, на которых установлен двоичный форматер. В настоящий момент двоичный форматер был реализован, только на платформе ,NET, так что использование двоичного форматера требует, чтобы вы посылали данные от сервера .NET к клиенту .NET и обратно.

Форматер SOAP передает данные в формате сообщений SOAP. Сообщения SOAP более многословны, чем их двоичные аналоги, что делает их менее эффективными, чем сообщения в двоичном формате.

Однако форматер SOAP имеет гораздо больше возможностей, чем двоичный форматер, с точки зрения предоставления переносимости и взаимодействия с сообщениями. Возможно, наиболее интересным использованием SOAP является возможность обрабатывать и интерпретировать сообщения SOAP любой платформой, которая понимает SOAP. Эта гибкость позволяет нам реализовать сервер и клиента для различных платформ, в частности для .NET и Java, но не только для них. Клиент Java может принимать сообщение Java от сервера .NET, и наоборот. Это является основой веб-служб. Единственным еще не указанным требованием для обеспечения межплатформенного взаимодействия является передача сообщения SOAP по одному и тому же протоколу или каналу.

Канал

Аналогично тому, как клиент и сервер должны договориться по формату сообщений, они также должны договориться о механизме взаимодействия, или канале, с помощью которого будут передаваться данные. Каналы являются транспортными механизмами, с помощью которых передаются данные. Например, World Wide Web использует в качестве соглашения по каналу взаимодействия HTTP. Если клиентский компьютер может послать запрос HTTP к серверу, то сервер может ответить при помощи ответа HTTP и взаимодействие успешно состоится. Если клиентский компьютер передает запрос, используя канал SMTP, и получает данные в формате HTTP, то взаимодействия не произойдет. Аналогично веб, клиенты и серверы удаленного доступа должны договориться о канале взаимодействия.

Аналогично тому, как можно в .NET Remoting написать наш собственный форматер, также возможно создать наш собственный канал. Создание канала будет вопросом реализаций набора идентификаторов, которые будет понимать как клиент; так и сервер. Например, мы можем реализовать канал SMTP и посылать сообщения в формате SMTP.

.NET Framework поставляется с двумя готовыми каналами, которые называются каналами TCP и HTTP. Канал TCP взаимодействует по протоколу TCP и очень эффективен. Канал HTTP посылает сообщения по протоколу HTTP, высокоуровневому протоколу, основанному на TCP/IP.

Аналогично двоичному форматеру, канал TCP ограничен теми платформами, которые могут осуществлять взаимодействие по TCP. Обычно это означает, что, так же как и двоичный форматер, обе стороны взаимодействия должны быть клиентами .NET.

Канал HTTP посылает сообщения по протоколу HTTP. Если процессы клиента и сервера могут осуществлять взаимодействие по каналу HTTP, то взаимодействие будет успешным. Так как HTTP основан на TCP, канал HTTP не так эффективен, как взаимодействие на основе TCP. Однако так как протокол HTTP очень популярен и реализован на большинстве платформ, канал HTTP более гибок.