Форматер

Когда данные передаются между процессами при помощи 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 более гибок.