сеть для стахановцев

ПАЛАГИН АНТОН AKA TONY

Спецвыпуск: Хакер, номер #065, стр. 065-012-3

//Инстанцируем тестовый объект

Test test = new Test();

//Вызываем тестовый объект и выводим на экран то, что он вернул

Console.WriteLine(test.hello());

}

}

}

Для того чтобы клиент «знал» о тестовом объекте, необходимо сослаться на сборку TestObject. Выбор вызываемого объекта осуществляется с помощью сценария конфигурации SimpleClient.exe.config. Вот он:

<configuration>

<system.runtime.remoting>

<application>

<client>

<wellknown

type="TestObject.hello, TestObject"

url="http://192.168.10.87:8000/RemotingTest/Test.rem" />

</client>

</application>

</system.runtime.remoting>

</configuration>

Ключевым для нас является узел wellknown. Здесь указывается, какой именно объект и его метод будут вызываться (атрибут type). Также важна ссылка на сервер в атрибуте url, здесь можно указать способ общения (http или tcp). Завершающим штрихом к этой картине служит код сборки, которая содержит реализацию тестового объекта. Для того чтобы мы могли обращаться к объекту удаленно по ссылке, необходимо пронаследовать его от класса MarshalByRefObject.

using System;

namespace TestObject

{

public class Test: MarshalByRefObject

{

public string hello()

{

return "Hello world!!!";

}

}

}

кишки

Теперь откомпилируем код. В результате должно получиться два консольных приложения (клиент и сервер), а также сборка, хранящая тестовый объект. Запустим сервер, запустим клиент… Здравствуй, мир. Посмотри на рисунок «Сетевой обмен»: вот такой кучей пакетов обменялись наш сервер с клиентом. Если отбросить в сторону избыточные данные протокола TCP/IP, то останутся HTTP-запросы и SOAP-сообщения (см. рис. «Протокол обмена»). Серверу с адресом 192.168.10.87 SOAP клиент послал запрос на выполнение метода TestObject.hello, а в ответ получил SOAP-сообщение с результатами выполнения, то есть со строкой «Hello world!!!». Кстати, трафик на одно такое обращение составил 2500 байт для протокола SOAP и 1000 байт для бинарного протокола.

Как видно по таблице «Способы общения клиента и сервера», нам позволено произвольно выбирать то, в какой именно форме будет происходить обмен данными между приложениями: можно использовать TCP/IP и сообщения SOAP, а можно обмениваться бинарными данными с помощью HTTP. По скорости работы .NET Remoting слегка отстает от DCOM и CORBA, но весьма незначительно. Разница в работе с режимами TCP/IP и HTTP минимальна. Кроме самого первого обращения клиента к серверу, в этом случае обмен с использованием протокола HTTP идет в несколько раз медленнее.

web-службы

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

Если сравнивать возможности этой технологии и .NET Remoting, то выделится одно-единственное существенное различие — существенное ограничение типов данных, пригодных для использования при разработке web-служб. Собственно, ничего непонятного в этом нет: web-службы рассчитаны на широкий спектр платформ, клиентов и языков разработки, но за такой праздник приходится расплачиваться ограничением типов данных. Взамен клиенту предоставляется возможность обращаться к службе любым удобным ему способом. Главное, что он должен знать, — это формат сообщения SOAP для нужной службы. В .NET Remoting спектр клиентов ограничивается шириной платформы .NET, зато там больше возможностей удаленного взаимодействия.