русс | укр

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

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

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

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


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

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


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


Рассмотрим основные элементы Remoting, показанные на рисунке 6.

Рис. 6. Основные элементы архитектуры Remoting

Первый элемент архитектуры Remoting – это объект-заместитель или прокси-объект (proxy object). Прокси-объект выполняет следующие задачи. Во-первых, для клиентского кода он выглядит так же, как и любой объект локального класса, что упрощает клиентский код. Во-вторых, все вызовы методов прокси-объект превращает в специальные объекты-сообщения. Сообщение служит для описания метода. Оно, в частности, содержит имя метода, коллекцию входных и выходных параметров. Для того чтобы исполняющая среда (CLR) могла правильно создать прокси-объект, удаленный класс должен быть наследником (прямым или косвенным) класса System.MarshalByRefObject. В дальнейшем подобные классы будем для краткости называть MBR-классами. Кроме этого, клиентскому коду требуется для работы метаданные удаленного класса. Обычно для этого в удаленном классе выделяют интерфейс, который разделяют между сервером и клиентом.

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

С каналом могут быть связаны канальные приемники, при помощи которых осуществляется перехват сообщений. Обязательным элементом канала является форматер (formatter). Задача форматера – сериализовать сообщение, то есть представить его в виде потока данных. В составе Remoting имеется бинарный форматер и SOAP-форматер[10]. HTTP-канал использует по умолчанию SOAP-форматер, TCP-канал – бинарный форматер. При необходимости можно реализовать и собственный форматер данных и канальные приемники. Так как форматер выполняет сериализацию объекта-сообщения, то типы, представляющие входные и выходные параметры метода, должны быть сериализуемыми.



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

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

3.3. Активация удаленных объектов и их время жизни

Перед доступом к удаленному объекту он должен быть создан и инициализирован. Данный процесс называется активацией. В Remoting удаленные объекты поддерживают два вида активации: серверную активацию и клиентскую активацию[11].

При серверной активации инфраструктура Remoting регистрирует тип на сервере и назначает ему универсальный идентификатор ресурсов (Uniform Resource Identifier, URI). Так как каждому типу назначен некий известный URI, то такие типы получили название общеизвестных типов (well-known types). Объекты общеизвестных типов далее будут обозначаться как SAOserver activated objects.

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

Следующий пример кода показывает конфигурирование типа на сервере в режиме Singleton:

RemotingConfiguration.RegisterWellKnownServiceType(

typeof(SomeMBRType),

"SomeURI",

WellKnownObjectMode.Singleton);

В коде используется класс System.Runtime.Remoting.RemotingConfiguration для регистрации типа с именем SomeMBRType. Клиент также должен сконфигурировать тип SomeMBRType как общеизвестный в режиме Singleton:

RemotingConfiguration.RegisterWellKnownClientType(

typeof(SomeMBRType),

"http://SomeWellKnownURL:Port/SomeURI");

Режим серверной активации SingleCall предназначен для реализации концепции объектов без сохранения состояния. Если некий тип сконфигурирован в режиме SingleCall, инфраструктура Remoting создает объект типа для каждого вызова метода типа. После вызова метода объект уничтожается. Следующий пример демонстрирует конфигурирование типа в режиме SingleCall:

RemotingConfiguration.RegisterWellKnownServiceType(

typeof(SomeMBRType),

"SomeURI",

WellKnownObjectMode.SingleCall);

С точностью до последнего параметра этот фрагмент кода идентичен коду для случая режима Singleton. Клиентский код регистрации полностью совпадает для двух режимов.

В некоторых программных сценариях требуется, чтобы каждый клиент работал со своей копией удаленного объекта. В этом случае следует использовать клиентскую активацию. Объекты типов с клиентской активацией (далее – CAO, client activated objects) сохраняют свое состояние между вызовами методов. Такие объекты имеют определенное время жизни, после которого автоматически уничтожаются.

Приведем пример кода, конфигурирующего тип на сервере как тип для CAO:

RemotingConfiguration.RegisterActivatedServiceType(

typeof(SomeMBRType));

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

RemotingConfiguration.RegisterActivatedClientType(

typeof(SomeMBRType), "http://SomeURL");

Более детально типы с клиентской активацией будут рассмотрены ниже.

Рассмотрим некоторые вопросы, связанные с отслеживанием временим жизни удаленных объектов. Эта проблема актуальна для CAO и SAO Singleton. В Remoting для управления временем жизни таких объектов используется механизм на основе лицензий и спонсоров.

Лицензия (lease) – это объект, инкапсулирующий несколько значений типа TimeSpan[12]. В Remoting для описания лицензий используется интерфейс ILease (пространство имен System.Runtime.Remoting.Lifetime). Интерфейс ILease определяет несколько свойств, связанных с расчетом времени жизни объекта:

· InitialLeaseTime

· RenewOnCallTime

· SponsorshipTimeout

· CurrentLeaseTime

Свойство только для чтения CurrentLeaseTime содержит время, оставшееся до истечения срока действия лицензии. Свойство InitialLeaseTime указывает на первоначальный срок лицензии. При выдаче лицензии CurrentLeaseTime устанавливается равным InitialLeaseTime. Если InitialLeaseTime равно 0, то срок лицензии никогда не заканчивается. При вызове клиентом метода удаленного объекта инфраструктура Remoting определяет время, оставшееся до истечения лицензии. Если это время меньше, чем RenewOnCallTime, то лицензия продлевается на интервал, равный RenewOnCallTime. Свойство SponsorshipTimeout определяет, как долго инфраструктура Remoting будет ожидать ответа спонсора лицензии. Все перечисленные свойства имеют тип TimeSpan.

Когда создается объект с клиентской активацией или объект с серверной активацией в режиме Singleton, исполняющая среда запрашивает у объекта лицензию, вызвав его метод InitializeLifetimeServices(). Это виртуальный метод класса MarshalByRefObject. Для реализации лицензии с нестандартными параметрами метод можно перекрыть.

В каждом домене приложения имеется специальный диспетчер лицензий, который управляет лицензиями экземпляров типов, зарегистрированных в домене[13]. После активации удаленного объекта связанная с ним лицензия передается диспетчеру. Диспетчер содержит таблицу, в которой сопоставлены лицензии и момент окончания их действия. Диспетчер периодически просматривает данную таблицу[14]. Если момент окончания действия лицензии наступил, лицензия уведомляется об этом.

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

Спонсор – это объект, который может продлить лицензию. Класс спонсора должен реализовывать System.Runtime.Remoting.Lifetime.ISponsor. Спонсоры могут размещаться как на клиенте, так и на сервере, а значит, класс спонсора должен быть MBR-типом. Созданного спонсора разрешается связать с лицензией, вызвав метод ILease.Register(). У лицензии может быть несколько спонсоров.

Рис. 7. Спонсоры и лицензии

В пространстве имен System.Runtime.Remoting.Lifetime содержится класс ClientSponsor. Это MBR-тип и он реализует интерфейс ISponsor. Класс ClientSponsor позволяет регистрировать ссылки на удаленные объекты, которые предполагается спонсировать. Когда методу ClientSponsor.Register() передается ссылка на удаленный объект, этот метод регистрирует экземпляр ClientSponsor в качестве спонсора лицензии удаленного объекта и запоминает ссылку на лицензию удаленного объекта во внутренней хэш-таблице. Интервал времени, на который спонсор продлит лицензию, задается свойством ClientSponsor.RenewalTime. Ниже показан пример использования ClientSponsor:

ClientSponsor cp = new ClientSponsor(TimeSpan.FromMinutes(5));

cp.Register(someMBR);

3.4. Программная настройка Remoting

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

namespace BSUIR {

public interface ICalc {

double Add(double x, double y);

double Sub(double x, double y);

double Mult(double x, double y);

double Div(double x, double y);

}

}

Скомпилируем интерфейс в динамическую библиотеку ICalc.dll.

В качестве непосредственной реализации интерфейса BSUIR.ICalc рассмотрим класс BSUIR.Calculator:

using System;

namespace BSUIR {

public class Calculator: ICalc {

public Calculator() {

log("Calculator constructor");

}

public double Add(double x, double y) {

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

return x+y;

}

public double Sub(double x, double y) {

log("Sub " + x + " - " + y);

return x-y;

}

public double Mult(double x, double y) {

log("Mult " + x + " * " + y);

return x*y;

}

public double Div(double x, double y) {

log("Div " + x + " / " + y);

return x/y;

}

public static void log(string s) {

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

AppDomain.CurrentDomain.FriendlyName, s);

}

}

}

Класс Calculator скомпилирован в динамическую библиотеку с именем calc.dll. Для компиляции класса необходимо установить ссылку на сборку ICalc.dll.

Итак, на данном этапе у нас имеются:

1. интерфейс BSUIR.ICalc, размещенный в отдельной динамической библиотеке ICalc.dll;

2. класс BSUIR.Calculator, который реализует интерфейс BSUIR.ICalc и размещается в динамической библиотеке calc.dll.

Что дает подобное разделение на интерфейс и реализующий его класс? Преимущества подхода заключаются в следующем: для клиентов необходим только интерфейс BSUIR.ICalc, без его реализации. Мы можем менять на серверной части нашего распределенного приложения класс BSUIR.Calculator совершенно «прозрачно» для клиентов, пока класс поддерживает интерфейс BSUIR.ICalc. Если бы разделение не выполнялось, то клиенту понадобился бы класс BSUIR.Calculator на локальной машине, хотя и предполагалось бы удаленное использование объектов данного класса.

Построим сервер для нашего распределенного приложения. Прежде всего, нам необходимо внести некоторые изменения в класс BSUIR.Calculator.

using System;

namespace BSUIR {

public class Calculator: MarshalByRefObject, ICalc {

// далее по коду изменений нет

. . .

}

}

Напомним, что наследование от MarshalByRefObject – это обязательное условие для удаленных типов.

Код настройки сервера будет размещаться в методе Main() консольного приложения (собственно, данное приложение и будет сервером[15]). Во-первых, необходимо создать объект, описывающий канал. Воспользуемся классом HttpChannel (пространство имен System.Runtime.Remoting.Channels.Http) для создания стандартного канала на основе протокола HTTP:

HttpChannel chan = new HttpChannel(6000);

Параметром конструктора является номер порта, с которым связан канал (канал прослушивает данный порт).

Созданный канал должен быть зарегистрирован в инфраструктуре. Для этого используется статический метод RegisterChannel() класса ChannelServices из пространства имен System.Runtime.Remoting.Channels:

ChannelServices.RegisterChannel(chan);

После создания и регистрации канала требуется зарегистрировать класс, объекты которого предполагается использовать удаленно. Для регистрации класса используются статические методы класса RemotingConfiguration. В нашем примере будут использоваться объекты с серверной активацией в режиме SingleCall:

RemotingConfiguration.RegisterWellKnownServiceType(

typeof(Calculator),

"theEndPoint",

WellKnownObjectMode.SingleCall);

Параметры метода: тип регистрируемого класса; строка, представляющая концевую точку для типа; элемент перечисления WellKnownObjectMode, указывающий на режим использования серверных объектов (Singleton или SingleCall).

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

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Http;

using BSUIR;

 

class CalcServer {

public static void Main() {

HttpChannel chan = new HttpChannel(6000);

ChannelServices.RegisterChannel(chan);

RemotingConfiguration.RegisterWellKnownServiceType(

typeof(Calculator),

"theEndPoint",

WellKnownObjectMode.SingleCall);

Console.WriteLine("Press [enter] to exit...");

Console.ReadLine();

}

}

При компиляции сервера необходимо установить ссылку на сборку calc.dll и сборку ICalc.dll.

Приступим к написанию клиента. Как и сервер, клиент будет консольным приложением, логика работы которого сосредоточена в методе Main().

Клиент должен зарегистрировать канал. При вызове конструктора канала на клиенте можно использовать 0 в качестве параметра или применить конструктор без параметров. В последнем случае клиент не сможет принимать вызовы сервера. Это не всегда приемлемо (например, при работе со спонсорами, асинхронных вызовов методов и т. п.).

HttpChannel chan = new HttpChannel(0);

ChannelServices.RegisterChannel(chan);

Для соединения с сервером и получения ссылки на удаленный объект можно использовать статический метод Connect() класса RemotingServices. В качестве параметров методу передается тип запрашиваемого объекта и универсальный идентификатор ресурсов, указывающий на концевую точку, связанную с серверным объектом. Типом запрашиваемого объекта в нашем случае будет интерфейс ICalc, так как работа будет вестись через этот интерфейс:

object obj = RemotingServices.Connect(typeof(ICalc),

"http://localhost:6000/theEndPoint");

Получить ссылку на удаленный объект можно при помощи метода Activator.GetObject(). Использование данного метода понятно из примера:

object obj = Activator.GetObject(typeof(ICalc),

"http://localhost:6000/theEndPoint");

После запроса полученную ссылку требуется привести к типу ICalc, а затем можно вызывать методы удаленного объекта:

ICalc calc = (ICalc)obj;

calc.Add(3, 4);

Полный листинг клиента приведен ниже:

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Http;

using BSUIR;

class CalcClient {

public static void Main() {

HttpChannel chan = new HttpChannel(0);

ChannelServices.RegisterChannel(chan);

object obj = RemotingServices.Connect(typeof(ICalc),

"http://localhost:6000/theEndPoint");

ICalc calc = (ICalc)obj;

calc.Add(3, 4);

}

}

Для программной настройки инфраструктуры Remoting применялся класс RemotingConfiguration. Подробное описание свойств и методов этого класса приведено в таблице. Все свойств и методы являются статическими.

Таблица 18

Статические элементы класса RemotingConfiguration

Имя элемента Описание
ApplicationId Строка, содержащая GUID для приложения
ApplicationName Строка с именем приложения. Является частью URI удаленного CAO-типа для клиентов
Configure Метод используется в случае, когда настройки Remoting хранятся в конфигурационном файле
GetRegisteredActivatedClientTypes GetRegisteredActivatedServiceTypes GetRegisteredWellKnownClientTypes GetRegisteredWellKnownServiceTypes Набор методов, позволяющих получить все зарегистрированные типы в виде массива
IsActivationAllowed Метод проверяет на сервере, является ли тип, указанный в качестве параметра, типом с клиентской активацией
IsRemotelyActivatedClientType Метод проверяет на клиенте, является ли тип, указанный в качестве параметра, типом с клиентской активацией
IsWellKnownClientType Метод проверяет на клиенте, является ли тип, указанный в качестве параметра, типом с серверной активацией
ProcessId Строка, содержащая уникальный GUID текущего процесса
RegisterActivatedClientType RegisterActivatedServiceType RegisterWellKnownClientType RegisterWellKnownServiceType Набор методов для регистрации типов различных видов на клиенте и на сервере

3.5. УДАЛЕННЫЕ Объекты с клиентской активацией

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

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

Начнем решение задачи с разработки класса для представления удаленного объекта. Первая «заготовка» класса может выглядеть следующим образом (сборка RemoteCAO.dll):

using System;

namespace RemoteCAO {

public class UserCalculator: MarshalByRefObject {

private bool Registered = false;

public double CachedValue;

public bool Register(string Name, string Pass) {

Registered = (Name == "user") && (Pass == "pass");

if (Registered)

Console.WriteLine("User {0} registered", Name);

else

Console.WriteLine("Access denied");

return Registered;

}

public double Add(double x, double y) {

if (Registered) {

CachedValue = x + y;

return CachedValue;

}

else throw new Exception("Not registered!");

}

}

}

Обратите внимание на следующие моменты. Класс UserCalculator способен генерировать исключительные ситуации[16]. Клиент сможет корректно обработать исключительную ситуацию, которая возникла в удаленном объекте. В процессе работы с удаленным объектом мы будем совершенно свободно манипулировать его полем (не используя методы). В реальном приложении процесс авторизации обычно подразумевает работу с базой данных, в нашем случае применен упрощенный подход.

Класс UserCalculator, как и любой удаленный тип, является наследником класса MarshalByRefObject. В таблице 19 приведено описание методов класса MarshalByRefObject.

Таблица 19

Методы класса MarshalByRefObject

Имя метода Описание
CreateObjRef() Виртуальный метод, возвращающий объект класса System.Runtime.Remoting.ObjRef. Такой объект необходим клиентскому приложению, чтобы настроить прокси-объект. Метод можно переписать, если требуется собственная реализация ObjRef.
GetLifetimeService() Функция возвращает объект, реализующий интерфейс ILease, то есть лицензию, связанную с объектом.
InitializeLifetimeService() Данный виртуальный метод вызывается инфраструктурой Remoting при создании объекта и должен возвращать лицензию объекта. При необходимости метод можно переписать.

В нашем примере мы собираемся использовать нестандартные времена для лицензии объектов класса UserCalculator. Следовательно, нам требуется переписать виртуальный метод InitializeLifetimeService():

namespace RemoteCAO {

public class UserCalculator: MarshalByRefObject {

. . .

public override object InitializeLifetimeService() {

ILease lease = (ILease)base.InitializeLifetimeService();

if (lease.CurrentState == LeaseState.Initial) {

lease.InitialLeaseTime = TimeSpan.FromMinutes(4);

lease.SponsorshipTimeout = TimeSpan.FromMinutes(1);

lease.RenewOnCallTime = TimeSpan.FromMinutes(3);

}

return lease;

}

}

}

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

Перейдем к реализации сервера. Как и в примере из предыдущего параграфа, будем использовать в качестве сервера консольное приложение:

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Http;

using RemoteCAO;

class CalcServer {

public static void Main() {

HttpChannel chan = new HttpChannel(6000);

ChannelServices.RegisterChannel(chan);

RemotingConfiguration.ApplicationName = "MyServer";

RemotingConfiguration.RegisterActivatedServiceType(

typeof(UserCalculator));

Console.WriteLine("Press [enter] to exit...");

Console.ReadLine();

}

}

В сервере регистрируется канал и удаленный тип с клиентской активацией. Задается имя приложения ("MyServer"). Оно будет являться частью URL при доступе к удаленному объекту[17].

Приступим к написанию приложения-клиента:

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Http;

using RemoteCAO;

class CalcClient {

public static void Main() {

HttpChannel chan = new HttpChannel(0);

ChannelServices.RegisterChannel(chan);

RemotingConfiguration.RegisterActivatedClientType(

typeof(RemoteCAO.UserCalculator),

"http://localhost:60000/MyServer");

UserCalculator calc = new UserCalculator();

Console.Write("Input name: ");

string name = Console.ReadLine();

Console.Write("Input password: ");

string pass = Console.ReadLine();

if (calc.Register(name, pass))

Console.WriteLine("Successful logon");

else Console.WriteLine("Failed....");

try {

double res = calc.Add(2, 3);

Console.WriteLine(res);

}

catch(Exception e) {

Console.WriteLine(e.Message);

}

Console.WriteLine("Cached value {0}",

calc.CachedValue);

Console.ReadLine();

}

}

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

Реализуем спонсора, который сможет продлить время жизни удаленного объекта. Будем использовать клиентский спонсор, то есть объект-спонсор разместим на клиенте. Напомним, что класс для спонсоров должен реализовывать интерфейс ISponsor, а также быть MBR-типом:

using System.Runtime.Remoting.Lifetime;

. . .

public class FatSponsor: MarshalByRefObject, ISponsor {

public TimeSpan Renewal(ILease lease) {

Console.WriteLine("Renewal called....");

return TimeSpan.FromMinutes(1);

}

}

 

class CalcClient {. . .}

Наш спонсор прост. Он реализует метод ISponsor.Renewal(), который возвращает (независимо от лицензии) время, на которое продлевается лицензия объекта (1 минута).

Объект-спонсор требуется создать и зарегистрировать. Для этого у удаленного объекта запрашивается лицензия (методом GetLifetimeService()), а затем при помощи метода ILease.Register() регистрируется спонсор:

// Код в теле метода Main()

// Создаем спонсора

ISponsor s = new FatSponsor();

// Запрашиваем у удаленного объекта лицензию

ILease currLease = (ILease)calc.GetLifetimeService();

Console.WriteLine(currLease.SponsorshipTimeout);

// Регистрируем спонсора

currLease.Register(s);

Метод ILease.Unregister() используется для отмены регистрации определенного спонсора.

Приведенный код имеет следующую особенность. Он работает только с Microsoft Framework 1.0. В версии 1.1 и выше данный код работать не будет. В целях безопасности в этих версиях форматерам запрещено передавать вызовы от сервера клиенту без дополнительных настроек. Если проводится настройка Remoting с помощью конфигурационных файлов, то в параметрах форматера (и на клиенте, и на сервере) требуется поместить такой текст (выделен жирным шрифтом):

<channels>

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

<serverProviders>

<formatter ref="soap" typeFilterLevel="Full" />

<formatter ref="binary" typeFilterLevel="Full" />

</serverProviders>

</channel>

</channels>

3.6. Настройка Remoting при помощи конфигурационных файлов

В предыдущих примерах с использованием Remoting применялось программное конфигурирование инфраструктуры. Такой подход не всегда удобен, особенно если настройки требуется часто изменять. Наряду с программным конфигурированием Remoting допускает настройку с использованием стандартных конфигурационных файлов. Вместо написания такого кода на сервере

HttpChannel chnl = new HttpChannel(1234);

ChannelServices.RegisterChannel(chnl);

RemotingConfiguration.RegisterWellKnownServiceType(

typeof(CustomerManager),

"CustomerManager.soap",

WellKnownObjectMode.Singleton);

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

<configuration>

<system.runtime.remoting>

<application>

<channels>

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

</channels>

<service>

<wellknown mode="Singleton"

type="Server.CustomerManager, Server"

objectUri="CustomerManager.soap" />



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


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


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

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

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


 


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

 
 

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

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