Организация удаленного взаимодействия при помощи технологии .Net

8.1. Цель работы

Ознакомление с концепцией удаленного взаимодействия в рамках техно- логии .NET и выработка навыков создания распределенных приложений с ис- пользованием низкоуровневых возможностей предоставляемых CLR (Common

Language Runtime, общеязыковая среда выполнения).

8.2. Теоретические сведения

Термин удаленное взаимодействие в рамках технологии .NET относится к возможности организации взаимодействия двух или более объектов происхо- дящего через границу доменов приложений. Домен приложения (AppDomain) задает границы выполнения компоновочного блока .NET в рамках процесса ОС. Соответствующие домены приложений могут физически находиться в сле- дующих условиях:

1) Два домена приложения определены в рамках одного и того же процесса (и следовательно располагаются на одной и той же машине).

2) Два домена приложения определены в рамках разных процессов на одной и той же машине.

3) Два домена приложения определены в разных процессах на разных машинах.

Независимо от расстояния между объектами в отношении взаимодейст-

вующих объектов используются термины «клиент» и «сервер». Клиента можно определить как сущность, пытающуюся взаимодействовать с удаленными объ- ектами, а сервер – это программный агент, содержащий удаленные объекты.

Библиотеки базовых классов .NET содержат большое количество пространств имен, позволяющих строить распределенные приложения. Большинство типов, содержащихся в этих пространствах имен, находятся

в библиотеке mscorlib.dll, но дополнения и расширения базовых пространств имен вынесены в отдельный компоновочный блок System.Runtime.Remoting.dll. В таблице 8.1 представлено описание наи- более часто используемых пространств имен удаленного взаимодействия плат- формы .NET.

Таблица 8.1

Пространства имен .NET для поддержки возможностей удаленного взаимодействия

Пространство имен	Описание
System.Runtime.Remoting	Базовое пространство имен, которое долж- но использоваться при построении любого распределенного приложения .NET
System.Runtime.Remoting.Activation	Пространство имен, в котором определя- ются несколько типов, обеспечивающих тонкую настройку процесса активизации удаленного объекта
System.Runtime.Remoting.Channels	Содержит типы, представляющие каналы и приемники каналов
System.Runtime.Remoting.Channels.Http	Содержит типы, использующие протокол HTTP для транспортировки сообщений и объектов в удаленную точку и обратно
System.Runtime.Remoting.Channels.Ipc	Пространство имен содержащее типы, ис- пользующие архитектуру IPC (InterProcess Communication – взаимодействие процес- сов) Win 32. Архитектура IPC обеспечива- ет быстрое взаимодействие доменов при- ложений, существующих на одной физи- ческой машине
System.Runtime.Remoting.Services	Определяет ряд общих базовых классов (и интерфейсов), которые обычно использу- ются только внутренними агентами уда- ленного взаимодействия

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

.NET обеспечивает совместную работу следующих четырех ключевых элемен- тов: агентов, сообщений, каналов и форматеров.

Клиенты и объекты сервера взаимодействуют не напрямую, а через по-

средника, обычно называемого агентом (или proxy-модулем). Роль агента

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

ному объекту.

Формально такой агент, вызываемый клиентом непосредственно, называ- ется прозрачным агентом (transparent proxy). Этот объект, генерируемый средой CLR автоматически, несет ответственность за проверку того, что при вызове удаленного метода клиент получит нужное число параметров (и они будут нужного типа). Поэтому прозрачный агент можно интерпретировать, как фик- сированный слой взаимодействия, который нельзя программно изменить или

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

System.Runtime.Remoting.Messaging.IMessage:

public inteface IMessage

^{

IDictionary Properties {get;}

^}

Интерфейс IMessage определяет единственное свойство (с именем Prop- erties) , которое обеспечивает доступ к коллекции, используемой для хране- ния представленных клиентом аргументов. При наполнении объекта сообщения содержимым средой CLR он будет передан родственному типу, называемому реальным агентом (real proxy).

Реальный агент – это сущность, которая фактически посылает объект со- общения в канал. Реальный агент, который (в отличие от прозрачного агента) может быть расширен программистом, представлен базовым типом класса с именем RealProxy. Среда CLR сама генерирует клиентскую реализацию ре- ального агента для использования по умолчанию, которая подходит для боль- шинства встречающихся в практике случаев.

После того как агенты проверят и отформатируют поставляемые клиен- том аргументы, упаковав их в объект сообщения, соответствующий IMessage- совместимый тип передается от реального агента объекту канала. Каналы – это

сущности, отвечающие за транспортировку сообщения удаленному объекту и, если это необходимо, за то, чтобы возвращаемое значение от удаленного объек- та было доставлено обратно клиенту. В библиотеках базовых классов .NET предлагаются готовые реализации каналов трех типов:

1) TCP-канал;

2) HTTP-канал;

3) IPC-канал.

TCP-канал представляется типом класса TcpChannel и используется для передачи сообщений с использованием сетевого протокола TCP/IP. Класс Tcp- Channel удобен тем, что форматированные пакеты оказываются небольшими по объему, благодаря чему удаленный доступ осуществляется быстрее. Недос- татком же является то, что TCP-каналы не согласуются с брандмауэром автома- тически и могут требовать вмешательства сервисов администратора системы, чтобы получить разрешение на пересечение границы машины.

В противоположность этому, HTTP-канал, представляемый типом класса

HttpChannel, преобразует объекты сообщений в формат SOAP (Simple Object Access Protocol – простой протокол доступа к объектам), используя для этого соответствующий форматер SOAP. Так как формат SOAP опирается на XML (eXtensible Markup Language — расширяемый язык разметки), то пакеты в этом случае оказываются более объемными, чем в случае с TcpChannel. Поэтому при использовании HttpChannel удаленный доступ может осуществляться медленнее. С другой стороны, при использовании протокола HTTP большинст- во сетевых экранов позволяет сетевым экранам направляться через порт с но- мером 80.

IPC-канал, представленный в .NET типом IpcChannel, определяет коммуникационный канал связи для удаленного взаимодействия с использова- нием IPC-архитектуры ОС. Ввиду того, что IpcChannel при пересечении до- менов приложений действует в обход традиционных систем сетевой коммута- ции, то он оказывается намного быстрее, чем HTTP-и TCP-каналы, однако, он может использоваться только для организации взаимодействия доменов прило- жения на одном и том же компьютере. Поэтому IpcChannel не может приме- няться для построения распределенных приложений, допускающих использо- вание множества физических компьютеров.

Вне зависимости от типа каналов они реализуются интерфейсами

IChannel, IChannelSender и IChannelReceiver. Интерфейс IChannel определяет небольшой набор членов класса, обеспечивающих об- щую функциональность всех типов каналов. Роль IChannelSender заклю- чается в определении для каналов общего множества членов класса, позволяю- щих отправлять информацию данному получателю, а IChannelReceiver определяет множество членов класса, позволяющих каналу получать информа- цию от данного отправителя. Для регистрации приложениями кли- ента и сервера выбранного канала применяется метод

ChannelServices.RegisterChannel(), который в качестве параметра получает тип, реализующий IChannel, например:

// создание и регистрация Http-канала с портом 32469

HttpChannel c = new HttpChannel(32469); ChannelServices.RegisterChannel(c);

Типы TcpChannel и HttpChanne используют свои внутренние форматеры,

задачей которых является перевод объекта сообщения в термины соответст- вующего протокола. После создания форматированного сообщения оно переда-

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

При написании распределенного приложения .NET в большинстве случа- ев требуется создание трех компоновочных блоков:

1) Клиент. Этот компоновочный блок представляет сущность

(например, консольное или оконное приложение), заинтересованную в получе- нии доступа к удаленному объекту.

2) Сервер. Этот компоновочный блок представляет сущность, получающую канальные запросы от удаленного клиента и обслуживающую удаленные объекты.

3) Общий компоновочный блок. Этот компоновочный блок представляет

сущность, определяющую и реализующую удаленные объекты.

Такое разделение компоновочного блока, содержащего удаленные объек- ты и хосту сервера, является очень важным, поскольку компоновочные блоки и клиента, и сервера устанавливают ссылки на общий компоновочный блок, что- бы получить метаданные типов, допускающих удаленный доступ. В простей- шем случае общий компоновочный блок размещается в каталогах приложений

и клиента, и сервера. Потенциальным недостатком такого подхода является то, что клиент ссылается на компоновочный блок, содержащий программный CIL- код (Common Intermediate Language — общий промежуточный язык), который никогда не используется (и соответствующий программный код нельзя будет скрыть от конечного пользователя). Поскольку общий компоновочный блок нужен клиенту лишь для получения метаданных удаленных типов, то для уст- ранения вышеуказанного недостатка можно использовать следующие способы:

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

2) Использовать приложение командной строки soapsuds.exe. С помощью этого инструмента можно сгенерировать компоновочный блок, содержащий

только метаданные удаленных типов.

3) Вручную построить компоновочный блок, содержащий только мета- данные удаленных типов.

Далее приводится пример распределенного приложения, состоящего из трех компоновочных блоков:

1) Общий компоновочный блок с именем SimpleRemoteingAsm.dll.

2) Компоновочный блок клиента с именем SimpleRemoteObjectClient.exe.

3) Компоновочный блок сервера с именем SimpleRemoteObjectServer.exe

Текст программы общего компоновочного блока приведен в листинге

8.1, сервера – в листинге 8.2, клиента – в листинге 8.3.

Листинг 8.1. Текст общего компоновочного блока (*.dll библиотека)

using System;

^{using System.Collections.Generic;}

^{using System.Text;}

^{namespace SimpleRemotingAsm}

{

^{// для этого типа при удаленном доступе}

^{// будет использоваться маршаллинг по ссылке}

^{public class RemoteMessageObject : MarshalByRefObject}

^{

^{public RemoteMessageObject()}

^{

Console.WriteLine("Создание RemoteMessageObject");

^}

// этот метод получает входную строку

^{// от вызывающей стороны}

^{public void DisplayMessage(string msg)}

{

^{Console.WriteLine("Сообщение {0}:", msg);}

^}

^{// этот метод возвращает значение вызывающей стороне}

^{public string ReturnMessage()}

^{

return ("Привет от сервера");

^}

^}

^}

Листинг 8.2. Текст общего блока сервера (консольное приложение)

using System;

^{using System.Runtime.Remoting;}

^{using System.Runtime.Remoting.Channels;}

^{using System.Runtime.Remoting.Channels.Http;}

^{using SimpleRemotingAsm;}

^{namespace SimpleRemoteObjcetServer}

{

class SimpleObjServer

^{

^{static void Main(string[] args)}

^{

^{Console.WriteLine("Начало работы}

^{SimpleRemoteObjectServer");}

Console.WriteLine("Для завершения нажмите Enter");

// Регистрация нового HTTPChannel HttpChannel c=new HttpChannel(32469); ChannelServices.RegisterChannel(c);

^{// Реистрация WKO-типа с активация синглета}

RemotingConfiguration.RegisterWellKnownServiceType

(typeof(SimpleRemotingAsm.RemoteMessageObject), "RemoteMsgObj.soap", WellKnownObjectMode.SingleCall); Console.ReadLine();

^}

}

^}

Листинг 8.3. Текст общего блока клиента (консольное приложение)

using System;

^{using System.Runtime.Remoting;}

^{using System.Runtime.Remoting.Channels;}

using System.Runtime.Remoting.Channels.Http;

^{using SimpleRemotingAsm;}

^{namespace SimpleRemoteObjectClient}

^{

^{class SimpleObjClient}

^{

^{static void Main(string[] args)}

^{

Console.WriteLine("Начало работы

^{SimleRemoteObjectClient");}

^{Console.WriteLine("Для завершения нажмите <Enter>");}

^{// Создание нового Http-канала}

^{HttpChannel c = new HttpChannel();}

ChannelServices.RegisterChannel(c);

^{// Получения агента для удаленного доступа к WKO-типу}

^{Object remoteObj=Activator.GetObject}

(typeof(SimpleRemotingAsm.RemoteMessageObject), "http://localhost:32469/RemoteMsgObj.soap");

^{// Использование удаленного объекта}

^{RemoteMessageObject simple =}

(RemoteMessageObject)remoteObj; simple.DisplayMessage("Привет от клиента"); Console.WriteLine("Сервер говорит:{0}",

^{simple.ReturnMessage());}

^{Console.ReadLine();}

^}

^}

^}

8.3. Программа работы

Взяв за основу текст приложений, приведенный выше, написать про- грамму, которая позволила бы обмениваться текстовыми сообщениями между компьютерами (Chat). Добавить в эту программу следующие возможности:

1) обмениваться сообщениями между несколькими компьютерами;

2) обеспечивать поиск пользователя с определенным именем, подключенным к чату;

3) пересылаемые сообщения снабжать именами отправителя и

получателя;

4) осуществлять настройку цвета для отображения текстовых сообщений (текст каждого сообщения отображается выбранным им при входе в чат цве- том);

5) ввести защиту идентификации псевдонима пользователя от возможного дублирования.