русс | укр

Языки программирования

ПаскальСиАссемблерJavaMatlabPhpHtmlJavaScriptCSSC#DelphiТурбо Пролог

Компьютерные сетиСистемное программное обеспечениеИнформационные технологииПрограммирование

Все о программировании


Linux Unix Алгоритмические языки Аналоговые и гибридные вычислительные устройства Архитектура микроконтроллеров Введение в разработку распределенных информационных систем Введение в численные методы Дискретная математика Информационное обслуживание пользователей Информация и моделирование в управлении производством Компьютерная графика Математическое и компьютерное моделирование Моделирование Нейрокомпьютеры Проектирование программ диагностики компьютерных систем и сетей Проектирование системных программ Системы счисления Теория статистики Теория оптимизации Уроки AutoCAD 3D Уроки базы данных Access Уроки Orcad Цифровые автоматы Шпаргалки по компьютеру Шпаргалки по программированию Экспертные системы Элементы теории информации

ТЕхнология .NET Remoting 7 страница


Дата добавления: 2013-12-23; просмотров: 946; Нарушение авторских прав


</service>

</application>

</system.runtime.remoting>

</configuration>

Для применения настроек конфигурационного файла в вашем приложении достаточно вызвать метод RemotingConfiguration.Configure() и передать ему в качестве параметра имя config-файла:

String filename = "server.exe.config";

RemotingConfiguration.Configure(filename);

Ниже рассмотрены правила создания конфигурационных файлов. Файл с конфигурацией Remoting имеет следующую структуру:

<configuration>

<system.runtime.remoting>

<application>

<lifetime />

<channels />

<service />

<client />

</application>

</system.runtime.remoting>

</configuration>

 

<lifetime />

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

· leaseTime – начальное время жизни (time to live, TTL) объекта (по умолчанию – 5 минут);

· sponsorshipTimeout – время ожидания ответа от спонсора (по умолчанию – 2 минуты);

· renewOnCallTime – время, добавляемое к TTL объекта, когда вызывается его метод (по умолчанию – 2 минуты);

· leaseManagerPollTime – интервал проверки TTL диспетчером лицензий (по умолчанию – 10 секунд).

Все атрибуты являются необязательными и могут быть заданы в различных временных единицах. При этом используется обозначение D для дней, H для часов, M для минут, S для секунд и MS для миллисекунд. Комбинации вида 1H5M не поддерживаются.

Пример секции <lifetime>:

<lifetime

leaseTime="90MS"

renewOnCallTime="90MS"

leaseManagerPollTime="100MS"

/>

 

<channels />

Этот тэг служит для группировки тэгов, описывающих отдельные каналы. Сам он не имеет каких-либо атрибутов.



<channel />

Тэг позволяет указать номер порта для канала на стороне сервера, сослаться на нестандартный пользовательский канал, а также провести дополнительную настройку канала. Если планируется использовать стандартные TCP или HTTP каналы, этот тэг не требуется указывать на клиенте, так как стандартные каналы регистрируются .NET Framework автоматически. На стороне сервера требуется указать, по крайней мере, номер порта для канала.

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

Тэг <channel> может иметь следующие атрибуты:

· ref – ссылка на стандартный канал ("tcp" или "http") или ссылка на канал, предварительно описанный в конфигурационном файле;

· displayName – используется .NET Framework Configuration Tool;

· type – главный атрибут, если не задан атрибут ref. Содержит точное имя типа канала, с указанием пространства имен и сборки. Для глобальных сборок требуется указывать сильное имя. В качестве примера использования рассмотрите описание HTTP-канала в файле machine.config;

· port – Номер порта канала на сервере. Если клиент планирует получать от сервера сообщения обратного вызова, то в качестве номера порта на клиенте требуется указать 0.

В дополнение к описанным атрибутам, HTTP-канал поддерживает следующие дополнительные атрибуты (для некоторых атрибутов указано, где их требуется задавать – на клиенте (К) или на сервере (С)):

· name – имя канала (по умолчанию "http"). При регистрации нескольких каналов должно быть уникальным, или требуется указать пустую строку (""). Значение данного атрибута можно использовать при вызове функции ChannelServices.GetChannel();

· priority – индикатор вероятности того, что исполняющая среда выберет данный канал для пересылки данных (по умолчанию параметр равен 1). Чем больше указанное целое число, тем выше вероятность;

· clientConnectionLimit – число соединений, которые клиент может одновременно открыть к заданному серверу (по умолчанию – 2) (К);

· proxyName – имя (адрес) прокси-сервера (К);

· proxyPort – номер порта прокси-сервера (К);

· suppressChannelData – атрибут указывает, будут ли данные о канале присутствовать в структуре ChannelData, используемой при создании объекта ObjRef (по умолчанию – "false") (С);

· useIpAddress – значение "true" (по умолчанию) указывает на использование в URL IP-адреса (а не символьного имени сервера) (С);

· listen – значение "true" (по умолчанию) позволяет использовать перехватчики, прослушивающие канал (С);

· bindTo – IP-адрес обслуживаемого сервером сетевого адаптера (если их несколько) (С);

· machineName – имя компьютера, используемого каналом. Указание имени отменяет атрибут useIpAddress (С).

TCP-канал (<channel ref="tcp">) поддерживает атрибуты HTTP-канала и один дополнительный атрибут:

· rejectRemoteRequests – если данное значение установлено в "true", то сервер принимает запросы Remoting только от приложений с локальной машины (С).

Рассмотрим примеры. На стороне сервера следующую конфигурацию можно использовать для указания канала HTTP, прослушивающего порт 1234:

<channels>

<channel ref="http" port="1234">

</channels>

На стороне клиента при помощи такой настройки можно увеличить число одновременных запросов от клиента к серверу:

<channels>

<channel ref="http" port="0" clientConnectionLimit="100">

</channels>

В рамках каждого канала можно указать и настроить нестандартные канальные приемники и форматеры. Как было сказано выше, Remoting основана на передаче объектов-сообщений. Используя секции конфигурационных файлов <clientProviders> и <serverProviders>, можно задать цепочку канальных приемников, через которые проходит сообщение, и форматер сериализации сообщения.

Структура секции <serverProviders> на стороне сервера выглядит следующим образом:

<channels>

<channel ref="http" port="1234">

<serverProviders>

<formatter />

<provider />

</serverProviders>

</channel>

</channels>

Свойство <formatter> может присутствовать в одном экземпляре, свойств <provider> допускается несколько. Требуется учесть, что порядок свойств <provider> имеет значение. Подробно об атрибутах, специфичных для канальных приемников, будет рассказано ниже.

Следующие атрибуты являются общими, как для приемника, так и для форматера:

· ref – ссылка на стандартный канальный приемник или форматер ("soap", "binary", "wsdl") или ссылка на канальный приемник или форматер, предварительно описанный в конфигурационном файле;

· type – главный атрибут, если не задан атрибут ref. Содержит точное имя типа канального приемника, с указанием пространства имен и сборки. Для глобальных сборок требуется указывать сильное имя.

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

На стороне сервера требуется записать в конфигурационном файле[18]:

<channels>

<channel ref="http" port="1234">

<serverProviders>

<formatter ref="binary" />

</serverProviders>

</channel>

</channels>

На стороне клиента используется такой фрагмент:

<channels>

<channel ref="http>

<clientProviders>

<formatter ref="binary" />

</clientProviders>

</channel>

</channels>

<service />

Тэг позволяет зарегистрировать и настроить удаленные классы с серверной и клиентской активацией, которые публикует данная сборка как сервер. Секция <service> содержит требуемое количество подсекций <wellknown> и <activated>.

 

<wellknown>

В этой подсекции на стороне сервера описываются публикуемые удаленные типы с серверной активацией. Тэг поддерживает атрибуты, которые аналогичны параметрам вызова метода RegisterWellKnownServiceType():

· type – информация о типе публикуемого класса в форме "<namespace>.<classname>, <assembly>". Если используется сборка из GAC, требуется указать версию, культуру и public key;

· mode – индикатор, указывающий вид активации: "Singleton" или "SingleCall";

· objectUri – концевая точка, URI для обращений к объектам удаленного класса. Если используется IIS-хостинг для классов, URI должен оканчиваться на .soap или .rem для корректной обработки. Эти расширения отображаются на инфраструктуру Remoting в метабазе IIS;

· displayName – необязательный атрибут, используемый .NET Framework Configuration Tool.

Используя следующий файл, сервер позволяет осуществить доступ к объектам класса CustomerManager по URI http://<host>:1234/CustomerManager.soap:

<configuration>

<system.runtime.remoting>

<application>

<channels>

<channel ref="http" port="1234" />

</channels>

<service>

<wellknown mode="Singleton"

type="Server.CustomerManager, Server"

objectUri="CustomerManager.soap" />

</service>

</application>

</system.runtime.remoting>

</configuration>

<activated>

В подсекции <activated> описываются публикуемые сервером удаленные типы с клиентской активацией. Так как полное имя концевой точки в случае клиентской активации определяется именем приложения сервера, единственный атрибут, который указывается в секции <activated> – это тип публикуемого класса:

· type – информация о типе публикуемого класса в форме "<namespace>.<classname>, <assembly>". Если используется сборка из GAC, требуется указать версию, культуру и public key.

Следующий пример позволит клиентам создавать объекты класса MyClass по адресу http://<hostname>:1234/

<configuration>

<system.runtime.remoting>

<application>

<channels>

<channel ref="http" port="1234" />

</channels>

<service>

<activated type="MyClass, MyAssembly"/>

</service>

</application>

</system.runtime.remoting>

</configuration>

 

<client />

На клиентской машине тэг <client> является аналогом тэга <service> на сервере. Структура этих тэгов совпадает:

<configuration>

<system.runtime.remoting>

<application>

<client>

<wellknown />

<activated />

</client>

</application>

</system.runtime.remoting>

</configuration>

При использовании объектов с клиентской активацией тэг <client> должен при помощи атрибута url указать адрес сервера, содержащего типы, указанные в секции <activated>[19]:

· url – URL сервера. Обязательно указывать, если используются объекты с клиентской активацией;

· displayName – необязательный атрибут, используемый .NET Framework Configuration Tool.

Секция <wellknown> используется, чтобы зарегистрировать типы с серверной активацией на клиенте и позволяет использовать оператор new для инициализации ссылок на удаленные объекты. Секция <wellknown> на клиентской стороне имеет такие же атрибуты, как и параметры метода Activator.GetObject():

· url – полный URL к классу, зарегистрированному на сервере;

· type – информация о типе публикуемого класса в форме "<namespace>.<classname>, <assembly>". Если используется сборка из GAC, требуется указать версию, культуру и public key;

· displayName – необязательный атрибут, используемый .NET Framework Configuration Tool.

Если клиент указал некий тип как удаленный, исполняющая среда изменяет поведение оператора new. CLR отслеживает вызовы new, и в том случае, когда речь идет об удаленном типе, возвращается ссылка на серверный объект, а не создается локальный экземпляр типа. В случае следующего конфигурационного файла для получения удаленной ссылки достаточно написать CustomerManager x = new CustomerManager().

<configuration>

<system.runtime.remoting>

<application>

<client>

<wellknown type="Server.CustomerManager, Client"

url="http://localhost:1234/CustomerManager.soap" />

</client>

</application>

</system.runtime.remoting>

</configuration>

Секция <activated> используется, чтобы указать типы с клиентской активацией на клиенте. Так как URL сервера уже был указан как атрибут секции <client>, то единственный атрибут секции <activated> позволяет специфицировать тип:

· type – информация о типе публикуемого класса в форме "<namespace>.<classname>, <assembly>". Если используется сборка из GAC, требуется указать версию, культуру и public key.

Данные из секции <activated> также используются для переопределения поведения оператора new. При использовании конфигурационного файла, приведенного ниже, для получения удаленной ссылки достаточно написать MyRemote x = new MyRemote().

<configuration>

<system.runtime.remoting>

<application>

<client url="http://localhost:1234">

<activated type="Server.MyRemote, Client" />

</client>

</application>

</system.runtime.remoting>

</configuration>

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

3.7. Хостинг распределенных приложений

В данном параграфе обсуждаются различные виды размещения (хостинга) серверных компонент распределенных приложений. В качестве примера удаленного класса на протяжении параграфа будет использоваться простой класс BSUIR.Calculator, который скомпилирован в сборку с именем calc.dll.

 

using System;

namespace BSUIR {

public class Calculator: MarshalByRefObject {

public Calculator() {

log("Calculator constructor");

}

public double Add(double x, double y) {

log("Add " + x + " + " + y);

return x + y;

}

public static void log(string s) {

Console.WriteLine("[{0}]: {1}",

AppDomain.CurrentDomain.FriendlyName, s);

}

}

}

Обратите внимание, что в компоненте не выделен интерфейс. Для предоставления клиенту метаданных компонента будем просто передавать сборку с компонентом клиенту.

Клиент, используемый в примерах, достаточно стандартен:

using System;

using System.Runtime.Remoting;

using BSUIR;

 

class CalcClient {

public static void Main() {

string filename = "client.exe.config";

RemotingConfiguration.Configure(filename);

Calculator c = new Calculator();

Console.WriteLine(c.Add(3, 4));

}

}

Настройка Remoting на стороне клиента выполняется при помощи файлов конфигурации, которые будут описаны ниже.

В Remoting серверные компоненты распределенных приложений могут использовать хостинг на основе консольных приложений или приложений Windows Forms, хостинг Windows-сервиса или хостинг при помощи веб-сервера Internet Information Server (IIS).

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

Рассмотрим хостинг компонент с использованием Windows-сервиса. В .NET Framework пользовательский Windows-сервис – это класс, производный от ServiceProcess.ServiceBase. Обычно в классе требуется переписать виртуальный метод onStart() для выполнения некоторых полезных действий. В следующем листинге приведена «заготовка» пользовательского сервиса:

using System;

using System.ServiceProcess;

 

namespace WindowsService {

public class DummyService : ServiceBase {

public static string SVC_NAME = "Some dummy service";

public DummyService() {

// в конструкторе установим свойство – имя сервиса

this.ServiceName = SVC_NAME;

}

static void Main() {

//стартуем сервис

ServiceBase.Run(new DummyService());

}

protected override void OnStart(string[] args) {

// полезный код сервиса

}

protected override void OnStop() {

// действия сервиса перед остановкой

}

}

}

Для установки пользовательского сервиса в систему требуется создать специальный класс-инсталлятор. Этот класс будет обрабатываться утилитой установки installutil.exe, которая входит в состав .NET Framework. В следующем листинге показан простой класс-инсталятор, настраивающий сервис на автоматический старт при запуске системы:

using System.Configuration.Install;

using System.ServiceProcess;

using System.ComponentModel;

 

using WindowsService;

 

[RunInstallerAttribute(true)]

public class MyProjectInstaller: Installer {

private ServiceInstaller serviceInstaller;

private ServiceProcessInstaller processInstaller;

public MyProjectInstaller() {

processInstaller = new ServiceProcessInstaller();

serviceInstaller = new ServiceInstaller();

processInstaller.Account = ServiceAccount.LocalSystem;

serviceInstaller.StartType =

ServiceStartMode.Automatic;

serviceInstaller.ServiceName = DummyService.SVC_NAME;

Installers.Add(serviceInstaller);

Installers.Add(processInstaller);

}

}

Два файла – файл с кодом сервиса и файл с классом-инсталлятором – требуется скомпилировать в одну сборку (например, CustomWinServ.exe). Для установки сервиса выполняется следующая команда:

installutil CustomWinServ.exe

В случае успешной установки сервис ведет себя как любой стандартный сервис, он допускает управление (старт-стоп) при помощи оснастки администрирования (MMC).

Разрабатываемый сервис имеет возможность записывать информацию в Журнал событий (Event Log) системы. Для этого достаточно объявить в классе-сервисе статическую переменную типа System.Diagnostics.EventLog и использовать ее метод WriteEntry().

В листинге представлен класс-сервис для BSUIR.Calculator:

using System;

using System.Diagnostics;

using System.ServiceProcess;

using System.Runtime.Remoting;

 

namespace WindowsService {

public class RemotingService : ServiceBase {

private static EventLog evt = new EventLog("Application");

public static string SVC_NAME = "Remoting Sample Service";

public RemotingService() {

this.ServiceName = SVC_NAME;

}

static void Main() {

evt.Source = SVC_NAME;

evt.WriteEntry("Remoting Service intializing");

ServiceBase.Run(new RemotingService());

}

protected override void OnStart(string[] args) {

evt.WriteEntry("Remoting Service started");

String filename = "WinServ.exe.config";

RemotingConfiguration.Configure(filename);

}

protected override void OnStop() {

evt.WriteEntry("Remoting Service stopped");

}

}

}

Класс-инсталятор остается практически без изменений (используется имя класса-сервиса RemotingService). Два файла компилируются в сборку CustomWinServ.exe, к которой подключается сборка calc.dll.

Конфигурационный файл CustomWinServ.exe.config имеет такой вид:

<configuration>

<system.runtime.remoting>

<application>

<channels>

<channel ref="http" port="1234" />

</channels>

<service>

<wellknown mode="Singleton"

type="BSUIR.Calculator, Calc"

objectUri="Calculator.soap" />

</service>

</application>

</system.runtime.remoting>

</configuration>

Соответствующий конфигурационный файл для клиента:

<configuration>

<system.runtime.remoting>

<application>

<channels>

<channel ref="http" port="0" />

</channels>

<client>

<wellknown type="BSUIR.Calculator, Calc"

url="http://localhost:1234/Calculator.soap" />

</client>

</application>

</system.runtime.remoting>

</configuration>

Хостинг с использованием IIS обладает рядом преимуществ по сравнению с другими видами хостинга. В частности, IIS может быть сконфигурирован для обеспечения аутентификации пользователей удаленного компонента, а также для шифрования серверного трафика. Необходимо понимать, что IIS-хостинг накладывает ряд ограничений на конфигурацию удаленного класса. Допустимо использование только HTTP-канала (возможно, с нестандартным форматером). По сравнению с другими видами хостинга, использование IIS является менее производительным решением.

Общая схема IIS-хостинга проста:

1.Удаленные типы размещаются в отдельной сборке (библиотеке классов).

2.При помощи оснастки IISAdmin создается виртуальная директория, соответствующая серверной части распределенного приложения.

3.В поддиректорию bin помещается библиотека классов.

4.В виртуальной директории размещается конфигурационный файл, который называется web.config.

Создадим при помощи оснастки IISAdmin виртуальный каталог. Виртуальный каталог является частью URL и соответствует некому физическому каталогу на сервере. Например, в URL вида http://host_name/directory_name виртуальный каталог – это directory_name. Ему может соответствовать физический каталог c:\somedirectory. Стандартному URL http://host_name/ по умолчанию соответствует каталог c:\inetpub\wwwroot. После запуска оснастки IISAdmin (Пуск → Программы → Администрирование → Internet Information Services) требуется выбрать пункт Веб-узел по умолчанию, в контекстном меню пункта выбрать Создать → Виртуальный каталог. Запустится Мастер создания виртуального каталога. Требуется указать имя для каталога (укажем remote) и соответствующую каталогу директорию на диске (c:\rem). В сформированной виртуальной директории необходимо создать подкаталог bin и поместить в него сборку с удаленным типом. Альтернативное решение заключается в размещении сборки в GAC, но помните, что для доступа к сборке будет необходимо использовать сильное имя.

Конфигурационный файл web.config, размещенный в каталоге c:\rem, выглядит следующим образом:

<configuration>

<system.runtime.remoting>

<application>

<service>

<wellknown mode="Singleton"

type="BSUIR.Calculator, Calc"

objectUri="Calculator.soap" />

</service>

</application>

</system.runtime.remoting>

</configuration>

В конфигурационном файле отсутствует описание канала (ISS-хостинг подразумевает HHTP и стандартный порт). При необходимости изменить форматер по умолчанию для HTTP-канала описание канала должно присутствовать. Также при указании концевой точки обязательно должен быть записан суффикс soap.

Конфигурационный файл клиента выглядит следующим образом:

<configuration>

<system.runtime.remoting>

<application>

<client>

<wellknown type="BSUIR.Calculator, Calc"

url="http://localhost/remote/Calculator.soap" />

</client>

</application>

</system.runtime.remoting>

</configuration>

3.8. Объекты-сообщения

При удаленном взаимодействии исполняющая среда манипулирует не ассемблерным кодом вызова методов, а специальными объектами-сообщениями. Для поддержки сообщений предоставлено несколько стандартных интерфейсов. Базовым является интерфейс IMessage (пространство имен System.Runtime.Remoting.Messaging). Любое сообщение – это объект, реализующий данный интерфейс. Интерфейс IMessage устроен просто. Он содержит единственное свойство Properties типа IDictionary для помещения в сообщение любых данных и идентифицирующих их ключей. Для удобства в .NET Framework описаны еще несколько интерфейсов – наследников IMessage. Схема наследования представлена на рисунке 8.

Рис. 8. Схема наследования интерфейсов

В таблице 20 указано назначение интерфейсов и перечислены некоторые их элементы.

Таблица 20

Интерфейсы для сообщений и их элементы

Интерфейс или класс Имя элемента Описание
IMessage   Реализуется любым сообщением
IMethodMessage   Сообщения, описывающие работу с методами
Args Массив объектов, соответствующих аргументам метода
MethodName Имя метода (строка)
Uri Универсальный идентификатор (URI) объекта, которому направляется сообщение
TypeName Строка с полным именем типа объекта, к которому направляется сообщение
IMethodReturnMessage   Сообщение, описывающее результат метода
Exception Объект исключительной ситуации, если она сгенерирована удаленным объектом
OutArgs Массив объектов, представляющих выходные параметры метода
ReturnValue Объект, содержащий значение работы метода
IMethodCallMessage   Сообщение, соответствующее запуску метода
InArgs Массив объектов, представляющих входные параметры метода
IConstructionCall-Message   Сообщение является первым направляемым к удаленному объекту, и определяет свойства для создания объекта
ActivationType Тип удаленного объекта
Activator Свойство для работы с активаторами объекта
IConstructionReturnMessage   Сообщение, реализующее интерфейс, посылается как ответ на IConstructionCallMessage

3.9. Пользовательские канальные приемники

Одна из возможностей расширения .NET Remoting – написание собственного канального приемника. Канальный приемник (channel message sink) выступает в роли перехватчика сообщений или потока данных на стороне клиента или сервера. Укажем некоторые сценарии, требующие использования канальных приемников:



<== предыдущая лекция | следующая лекция ==>
ТЕхнология .NET Remoting 6 страница | ТЕхнология .NET Remoting 8 страница


Карта сайта Карта сайта укр


Уроки php mysql Программирование

Онлайн система счисления Калькулятор онлайн обычный Инженерный калькулятор онлайн Замена русских букв на английские для вебмастеров Замена русских букв на английские

Аппаратное и программное обеспечение Графика и компьютерная сфера Интегрированная геоинформационная система Интернет Компьютер Комплектующие компьютера Лекции Методы и средства измерений неэлектрических величин Обслуживание компьютерных и периферийных устройств Операционные системы Параллельное программирование Проектирование электронных средств Периферийные устройства Полезные ресурсы для программистов Программы для программистов Статьи для программистов Cтруктура и организация данных


 


Не нашли то, что искали? Google вам в помощь!

 
 

© life-prog.ru При использовании материалов прямая ссылка на сайт обязательна.

Генерация страницы за: 0.02 сек.