В главе 17 были рассмотрены службы Web, которые позволяют вызывать объекты на удаленном сервере. Использование сервера Web и протокола SOAP не всегда достаточно эффективно для приложений интранет. Протокол SOAP означает большие накладные расходы при пересылке большого объема данных. Для быстрых решений интранет можно использовать просто сокеты, как это делалось в предыдущей главе. В "старом мире", как известно, программы писали с использованием DCOM. С помощью DCOM можно вызывать методы на объектах, выполняющихся на сервере. Программная модель всегда является одной и той же, если объекты применяются на сервере или на клиенте.

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

Заменой DCOM является .NET Remoting. В противоположность DCOM .NET Remoting может использоваться также в решениях Интернета, а для них DCOM недостаточно гибок и эффективен. С помощью .NET Remoting можно адаптировать и расширить любую часть архитектуры, поэтому подходит практически для любого удаленного сценария. В этой главе будут рассмотрены:

□ Архитектура .NET Remoting

□ Каналы, сообщения, приемники

□ Создание клиентов и серверов

□ Удаленные свойства с конфигурационными файлами

□ Возможности расширения рабочей среды

□ Использование возможностей удаленного управления в приложениях ASP.NET

Прежде всего выясним, что такое .NET Remoting.

Два выражения могут описать .NET Remoting: Web Services Anywhere и CLR Object Remoting. Рассмотрим, что это означает. 

Выражение Web Services Anywhere используется в .NET Remoting и означает, что с помощью .NET Remoting службы Web могут применяться в любом приложении с помощью любого транспорта, используя какое угодно кодирование полезной нагрузки. .NET Remoting является предельно гибкой архитектурой.

Совместное использование SOAP и HTTP — только способ вызова удаленных объектов. Транспортный канал является подключаемым и может заменяться. Мы получаем каналы HTTP и TCP, представленные классами

HttpChannel

TcpChannel

Кодирование полезной нагрузки также можно заменить. Компания Microsoft предоставляет SOAP и механизмы двоичного кодирования. Можно использовать средство форматирования (форматтер) SOAP с помощью канала НТTР, но и использовать HTTP, применяя двоичный форматтер. Конечно оба эти форматтера можно использоватъ также с каналом TCP.

.NET Remoting не только делает возможным использование служб Web в каждом приложении .NET, но позволяет также предложить возможности службы Web в каждом приложении. Не имеет значения, создается ли консольное приложение или приложение для Windows, Windows Service или компонент COM+ — службы Web могут использоваться везде.

Термин подключаемый (pluggable) часто используется в .NET Remoting.

Подключаемый означает, что определенная часть проекта разработана так, что она может заменяться специальной реализацией.

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

.NET Remoting может использоваться для доступа к объектам в домене другого приложения независимо от того, находятся ли два объекта внутри одного процесса, в разных процессах или на разных системах.

Удаленные сборки можно сконфигурировать для локальной работы в домене приложения или как часть удаленного приложения. Если сборка является частью удаленного приложения, то клиент получает для общения прокси вместо реального объекта. Прокси посылает сообщение в канал.

Приложения .NET работают внутри домена приложения. Домен приложения можно рассматривать как подпроцесс внутри процесса, Традиционно процессы используются как изолирующая граница. Приложение, выполняющееся в одном процессе, не может получить доступ и разрушить память в другом процессе. Чтобы приложения общались друг с другом, требуется межпроцессная коммуникация. При использовании .NET домен приложения выступает новой границей безопасности внутри процесса, так как код CIL является проверяемым и обеспечивает безопасность типов данных. Различные приложения могут выполняться внутри одного процесса, но внутри различных доменов приложений. Объекты внутри одного домена приложений могут взаимодействовать напрямую. Чтобы получить доступ к объектам в другом домене приложений, требуется прокси.

Больше о доменах приложений можно узнать в главе 8.

Прежде чем перейти к внутренней функциональности .NET Remoting, давайте рассмотрим основные элементы архитектуры:

□ Удаленный объект является объектом, который выполняется на сервере. Клиент не вызывает методы на этом объекте напрямую, а использует для этого прокси. С помощью .NET легко отличить удаленные объекты от локальных: каждый класс, производный из

MarshalByValueObject

□ Канал используется для коммуникации между клиентом и сервером. Существует клиентская и серверная часть канала. С помощью .NET Framework мы получаем два типа каналов, которые общаются через TCP или HTTP. Можно также создать специальный канал, который поддерживает связь с помощью другого протокола.

□ Сообщения посылаются в канал. Они создаются для коммуникации между клиентом и сервером и хранят информацию об удаленных объектах, именах вызванных методов и всех аргументах.

□ Форматтер определяет, как сообщения передаются в канал. Вместе с .NET Framework мы получаем форматтеры SOAP и двоичный. Форматтер SOAP можно использовать для коммуникации со службами Web, которые не основываются на .NET Framework. Двоичные форматтеры действуют значительно быстрее и могут эффективно использоваться в среде интранет. Конечно, имеется возможность создать специальный форматтер.

□ Провайдер форматтера используется для соединения форматтера с каналом. Создавая канал, можно выбрать провайдер форматтера, и этот выбор в свою очередь, определяет форматтер, который будет использоваться для передачи данных в канал.

□ Клиент вызывает методы на прокси, а не на удаленном объекте. Существует два типа прокси: прозрачный прокси и реальный прокси. Прозрачный прокси выглядит для клиента как удаленный объект. Клиент может вызывать методы, реализуемые удаленным объектом на прозрачном прокси. В свою очередь, прозрачный прокси вызывает метод

Invoke()

Invoke()

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

□ Клиент может использовать активатор для создания удаленного объекта на сервере или для получения прокси активированного сервером объекта.

□ 

RemotingConfiguration

□ 

ChannelServices

Чтобы получить представление о функциональности, давайте рассмотрим концептуально, как элементы сочетаются друг с другом.

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

Прозрачный прокси, в свою очередь, вызывает реальный прокси. Реальный прокси отвечает за отправку сообщения в канал. Реальный прокси является подключаемым, можно заменить его с помощью специальной реализации, которая применяется для записи журнала для другого способа поиска канала и т.д. Используемая по умолчанию реализация реального прокси находит совокупность (или цепочку) уполномоченных приемников и передает сообщение в первый уполномоченный приемник. Уполномоченный приемник может перехватить и изменить сообщение. Примерами таких приемников являются приемники отладки, системы безопасности, синхронизации. Последний уполномоченный приемник досылает сообщение в канал. Как сообщение передается по линиям связи, зависит от форматтера. Ранее уже упоминалось, что имеются SOAP и двоичный форматтеры, которые также являются подключаемыми. Канал отвечает либо за соединение с принимающим сокетом на сервере, либо за отправку форматированных данных. Со специальным каналом можно производить различные действия, необходимые для передачи данных на другую сторону.

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

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

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

При создании компонентов COM+ использовались контексты COM+. Контексты в .NET являются очень похожими. Как уже было сказано, один процесс может иметь несколько доменов приложений. Домен приложения является чем-то типа подпроцесса с границами безопасности и может иметь различные контексты. Контекст используется для группирования объектов с аналогичными требованиями выполнения. Контексты состоят из множества свойств и используются для перехватывания: когда к ограниченному контекстом объекту обращаются из другого контекста, перехватчик может сделать некоторую работу, прежде чем вызов достигнет объекта.

Класс, который выводится из

MarsnalByRefObject

ContextBoundObject

Чтобы понять контексты, необходимо знать некоторые термины:

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

□ Атрибуты контекста могут присваиваться классам, производным из

ContextBoundObject

IContextAttribute

SynchronizationAttribute

ThreadAffinityAttribute

□ Атрибуты контекста определяют свойства контекста, необходимые объекту. Класс свойства контекста реализует интерфейс

IContextProperty

ContextAttribute

IContextProperty

IContextAttribute

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

Новый контекст создается, если экземпляру создаваемого класса требуется контекст, отличный от вызывающего контекста. Классы атрибутов, которые ассоциируются с целевым классом, запрашиваются в том случае, если все свойства текущего контекста в порядке. Если один из этих классов атрибутов присылает

false

IContributeXXXSink

Класс атрибута контекста является прежде всего атрибутом. Более подробно можно прочитать об этом в главе 6. Классы атрибутов контекста должны реализовать интерфейс

IContextAttribute

ContextAttribute

В .NET Framework содержатся два класса атрибутов контекста:

System.Runtime.Remoting.Contexts.SynchronizationAttribute

System.Runtime.Remoting.Contexts.ThreadAffinityAttribute

ThreadAffinity

Synchronization

С помощью этих атрибутов в конструкторе задаются четыре значения:

□ 

NOT_SUPPORTED

□

REQUIRED

□

REQUIRES_NEW

□

SUPPORTED

Как же происходит коммуникация между контекстами? Клиент использует вместо реального объекта прокси. Оно создает сообщение, которое передается в канал, и приемники могут выполнить перехват. Тот же самый механизм используется для коммуникации между различными доменами приложения или различными системами. Канал TCP или HTTP не требуется для коммуникации между контекстами, но канал здесь, конечно же, есть. Класс

CrossContextChannel

Прежде чем перейти к рассмотрению деталей архитектуры .NET Remoting, давайте рассмотрим кратко удаленный объект и очень маленькое простое клиентское серверное приложение, которое использует этот удаленный объект. Затем мы обсудим более подробно все необходимые шаги и параметры.

Реализуемый удаленный объект называется

Hello

HelloServer

HelloClient

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

System.MarshalByRefObject.MarshalByRefObject

Удаленный объект имеет распределенную идентичность. В связи с этим ссылка на объект может передаваться другим клиентам, и они также будут получать доступ к тому же объекту. Прокси знает об идентичности удаленного объекта.

Класс

MarshalByRefObject

Object

Чтобы увидеть .NET Remoting в действии, создается простая библиотека классов для удаленного объекта. Класс

Hello

System.MarshalByRefObject

Greeting()

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

RemoteHello.dll

Hello

namespace Wrox.ProfessionalCSharp {

 using System;

 /// <summary>

 /// Краткое описание Class1

 /// </summary>

 public class Hello: System.MarshalByRefObject {

  public Hello() {

   Console.WriteLine("Constructor called");

  }

  ~Hello() {

   Console.WriteLine("Destructor called");

  }

  public string Greeting(string name) {

   Console.WriteLine("Greeting called");

   return "Hello, " + name;

  }

 }

}

Для сервера используется консольное приложение C#. Для применения класса

TcpServerChannel

System.Runtime.Remoting.dll

RemoteHello.dll

В методе

Main()

System.Runtime.Remoting.Channel.Тcр.TcpServerChannel

System.Runtime.Remoting.Channels.ChannelServices

System.Runtime.Remoting.RemotingConfiguration.RegisterWellKnownServiceType

WellKnownObject.SingleCall

После регистрации удаленного объекта продолжим выполнение сервера, пока не будет нажата клавиша:

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Tcp;

namespace Wrox.ProfessionalCSharp {

 /// <summary>

 /// Краткое описание Class1

 /// </summary>

 public class HelloServer {

  public static void Main(string[] args) {

   TcpServerChannel channel = new TcpServerChannel(8086);

   ChannelServices.RegisterChannel(channel);

   RemotingConfiguration.RegisterWellKnownServiceType(

    typeof(Hello), "Hi", WellKnownObjectMode.SingleCall);

   System.Console.WriteLine("hit to exit");

   System.Console.ReadLine();

  }

 }

}

Клиент также является консольным приложением C#. И здесь делается ссылка на сборку

System.Runtime.Remoting.dll

TcpClientChannel

RemoteHello.dll

В клиентской программе создается объект

TcpClientChannel

ChannelServices

TcpChannel

Activator

System.Runtime.Remoting.Proxies._TransparentProxy

using System;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Tcp;

namespace Wrox.ProfessionalCSharp {

 /// <summary>

 /// Краткое описание Class1.

 /// </summary>

 public class HelloClient {

  public static void Main(string[] args) {

   ChannelServices.RegisterChannel(new TcpClientChannel());

   Hello obj = (Hello)Activator.GetObject(typeof(Hello), "tcp://localhost:8086/Hi");

   if (obj == null) {

    Console.WriteLine("could not locate server"); return;

   }

   for (int i = 0; i < 5; i++) {

    Console.WriteLine(obj.Greeting("Christian"));

   }

  }

 }

}

Когда запустятся сервер и клиентская программа Hello, Christian появится пять раз на клиентской консоли. В консольном окне серверного приложения можно будет увидеть вывод, аналогичный следующему:

Первый конструктор вызывается во время регистрации удаленного объекта. Как утверждалось ранее, метод

RemotingConfiguration.RegisterWellKnownServiceType()

WellKnownObjectMode.SingleCall

Показав в действии простой клиент, сервер и изучив архитектуру .NET, перейдем к деталям. На основе созданных ранее программ будут рассмотрены механизмы архитектуры и способы расширения.

Канал используется для коммуникации между клиентом .NET и сервером. Среда .NET поставляется с классами каналов, которые общаются с помощью TCP или HTTP. Можно создать специальные каналы для других протоколов.

Канал HTTP применяется большинством служб Web. Он использует для коммуникации протокол HTTP, так как брандмауэры обычно имеют открытым порт 80, чтобы клиенты могли получить доступ к серверам и службам Web. Прием на порту 80 также находится в распоряжении этих клиентов.

В Интернете используется и канал TCP, но здесь брандмауэры должны специально конфигурироваться, чтобы клиенты получали доступ к указанному порту канала TCP. Канал TCP по сравнению с HTTP может применяется для коммуникации более эффективно в интранет.

Когда выполняется вызов метода на удаленном объекте, объект клиентского канала посылает сообщение удаленному объекту канала.

Как серверное, так и клиентское приложения, должны создавать канал. Следующий код показывает, как можно создать

TcpServerChannel

using System.Runtime.Remoting.Channels.Tcp;

// ...

TcpServerChannel channel = new TcpServerChannel(8086);

Порт, который слушает сокет TCP, определяется аргументом конструктора. Серверный канал должен определить общеизвестный порт, а клиент использует его порт при доступе к серверу. Однако для создания

TcpClientChannel

TcpClientChannel

Создание нового экземпляра канала немедленно включает сокет на прослушивание состояния, которое можно проверить, вводя в командной строке

netstat -а

Каналы HTTP используются аналогично каналам TCP. Определяется порт, где сервер может создать слушающий сокет. У нас также есть конструктор, в котором можно задать, передавая

Boolean

Сервер способен слушать несколько каналов. Здесь создаются каналы как HTTP, так и TCP:

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Tcp;

using System.Runtime.Remoting.Channels.Http;

namespace Wrox.ProfessionalCSharp {

 /// <summary>

 /// Краткое описание Class1.

 /// </summary>

 public class HelloServer {

  public static void Main(string[] args) {

   TcpServerChannel tcpChannel = new TcpServerChannel(8086);

   HttpServerChannel httpChannel = new HttpServerChannel (8085);

   // ...

Класс канала должен реализовать интерфейс

IChannel

IChannel

□

ChannelIName

□

ChannelPriority

В зависимости от того, является ли канал клиентским каналом или серверным каналом, реализуются дополнительные интерфейсы. Серверные версии каналов реализуют интерфейс

IChannelReceiver

IChannelSender

Классы

HttpChannel

TcpChannel

IChannelSender

IChannelReceiver

IChannel

IChannelSender

IChannel

CreateMessageSink()

IMessageSink

IMessageSink

IChannelReceiver

StartListening()

StopListening()

Информацию о конфигурации обоих каналов получают с помощью свойств классов каналов

ChannelName

ChannelPriority

ChannelData

ChannelData

ChannelDataStore

HttpChannel

Scheme

ShowChannelProperties()

protected static void ShowChannelProperties(IChannelReceiver channel) {

 Console.WriteLine("Name; " + channel.ChannelName");

 Console.WriteLine("Priority: " + channel.ChannelPriority);

 if (channel is HttpChannel) {

  HttpChannel httpChannel = channel as HttpChannel;

  Console.WriteLine("Scheme: " + httpChannel.ChannelScheme);

 }

 ChannelDataStore data = (ChannelDataStore)channel.ChannelData;

 foreach (string uri in data.ChannelUris) {

  Console.WriteLine("URI: " + uri);

 }

 Console.WriteLine();

}

После создания каналов вызывается метод

ShowChannelProperties()

TcpServerChannel tcpChannel = new TcpServerChannel(8086);

ShowChannelProperties(tcpChannel);

HttpServerChannel httpChannel = new HttpServerChannel(8085);

ShowChannelProperties(httpChannel);

С помощью каналов TCP и HTTP будет получена следующая информация:

Как можно видеть, именем по умолчанию для

TcpServerChannel

tcp

http

CNagel

Можно задать все свойства канала в списке с помощью конструктора

TcpServerChannel(IDictionary, IServerChannelSinkProvider)

ListDictionary

IDictionary

Name

Priority

Port

Для использования класса

ListDictionary

System.Collections.Specialized

IDictionary

IServerChannelSinkProvider

SoapServerFormatterSinkProvider

BinaryServerFormatterSinkProvider

TCPServerChannel

SoapServerFormatterSinkProvider

SoapServerFormatterSink

SoapFormatter

ListDictionary properties = new ListDictionary();

properties.Add("Name", "TCP Channel with a SOAP Formatter");

properties.Add("Priority", "20");

properties.Add("Port", "8086");

SoapServerFormatterSinkProvider sinkProvider =

 new SoapServerFormatterSinkProvider();

TcpServerChannel tcpChannel =

 new TcpServerChannel(properties.sinkProvider);

ShowChannelProperties(tcpChannel);

Вывод, который будет получен из запускаемого на сервере кода, показывает новые свойства канала TCP:

Можно создать специальный канал для отправки сообщений с помощью транспортного протокола, отличного от HTTP или TCP, или расширить существующие каналы:

□ Посылающая часть должна реализовать интерфейс

IChannelSender

CreateMessageSink()

□ Получающая часть должна реализовать интерфейс

IChannelReceiver

ChannelData

ChannelServices.SyncDispatchMessage()

.NET Framework предоставляет два класса форматтера:

□

System.Runtime.Serialization.Formatters.Binary.BinaryFormatter

□

System.Runtime.Serialization.Formatters.Soap.SoapFormatter

Форматтер ассоциируется с каналом из-за наличия объектов приемников форматтера и провайдеров источников форматтера.

Оба эти класса форматтера реализуют интерфейс

System.Runtime.Remoting.Messaging.IRemotingFormatter

Serialize()

Deserialize()

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

SoapServerFormatterSinkProvider

IServerChannelSinkProvider

IClientChannelSinkProvider

CreateSink()

SoapServerFormatterSinkProvider

SoapServerFormatterSink

SoapClientFormatterSink

SyncProcessMessage()

AsyncProcessMessage()

SoapFormatter

SoapServerFormatterSink

SoapFormatter

Все эти классы приемника и провайдера способны расширяться и заменяться собственными реализациями.

Служебный класс

ChannelServices

Канал регистрируется с помощью статического метода

ChannelServices.RegisterChannel()

Здесь представлен серверный код для регистрации каналов HTTP и TCP:

TcpChannel tcpChannel = new TcpChannel(8086);

HttpChannel httpChannel = new HttpChannel(8085);

Channel Services.RegisterChannel(tcpChannel);

СhannelServices.RegisterChannel(httpChannel);

Служебный класс

ChannelServices

RegisteredChannels

IChannel

GetChannel()

ChannelServices

HttpServerChannel channel =

 (HttpServerChannel)ChannelServices.GetChannel("http");

channel.StorListening(null);

Класс

RemotingConfiguration

Remoting

ObjRef

ObjRef

RemotingServices

Вот серверный код для регистрации хорошо известного типа удаленного объекта в

RemotingServices

RemotingConfiguration.RegisterWellKnownServiceType(

 typeof(Hello),                   // Тип

 "Hi",                            // URI

 WellKnownObjectMode.SingleCall); // Режим

Первый аргумент метода

RegisterWellKnownServiceType()

Wrox.ProfessionalCSharp.Hello

Hi

WellKhownObjectMode

SingleCall

Singleton

□ 

SingleCall

SingleCall

RemotingConfiguration.RegisterWellKnownServiceТуре()

WellKnownObjectMode.SingleCall

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

Singleton

RemotingConfiguration.RegisterWellKnownServiceType()

WellKnownObjectMode.Singleton

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

Вместо вызова

RemotingConfiguration.RegisterWellKnownType()

RemotingServices.RegisterActivatedServiceType()

RemotingConfiguration.ApplicationName

RemotingConfiguration.ApplicationName = "HelloServer";

RemotingConfiguration.RegisterActivatedServiceType(typeof (Hello));

Для клиентов возможно использование и создание удаленных объектов с помощью класса

Activator

GetObject()

CreateInstance()

Вместо класса

Activator

RemotingConfiguration

Во всех сценариях активации необходимо определять URL удаленного объекта. Этот URL является тем же самым, что и в браузере Web. Первая часть определяет протокол, за которым следует имя сервера или адрес IP, номер порта и URI, определенный при регистрации удаленного объекта на сервере в таком виде:

protocol://server:port/URI

Мы все время используем в нашем коде два примера URL: определяем протокол

http

tcp

localhost

URI

Hi

http://localhost:8085/Hi

tcp://localhost:8086/Hi

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Tcp;

/// ...

TcpClientChannel channel = new TcpClientChannel();

ChannelServices.RegisterChannel(channel);

Hello obj = (Hello)Activator.GetObject(

 typeof(Hello), "tcp://localhost:8086/Hi");

GetObject()

System.Activator

RemotingServices.Connect()

tcp://localhost:8086/Hello

tcp

localhost:8086

Hello

RemotingConfiguration.RegisterWellKnownServiceType()

Вместо

Activator.GetObject()

RemotingServices.Connect()

Hello obj =

 (Hello)RemotingServices.Connect(typeof(Hello), "tcp://localhost:8086/Hi");

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

RemotingConfiguration.RegisterWellKnownClientType()

Activator.GetObject()

WellKnownObjectMode.SingleCall

RemotingConfiguration.RegisterWellKnownClientType(

 typeof(Hello), "tcp://localhost:8086/Hi");

Hello obj = new Hello();

Удаленные объекты могут хранить состояние для клиента.

Activator.CreateInstance()

Activator.GetObject()

Activator.CreateInstance()

CreateInstance()

Некоторые из перезагруженных методов

Activator.CreateInstance()

activationAttributes

UrlAttribute

UrlAttribute

System.Runtime.Remoting.Activation

object [] attrs = { new UrlAttribute("tcp://localhost:8086/Hello") };

ObjectHandle handle =

 Activator.CreateInstance("RemoteHello",

 "Wrox.ProfessionalCSharp.Hello", attrs);

if (handle == null) {

 Console.WriteLine("could not locate server");

 return 0;

}

Hello obj = (Hello)handle.Unwrap();

Console.WriteLine(obj.Greeting("Christian"));

Конечно, для активизированных клиентом объектов также возможно использование оператора

new

Activator

RemotingConfiguration.RegisterActivatedClientType()

RemotingConfiguration.RegisterActivatedClientType(

 typeof (Hello), "tcp://localhost:8086/HelloServer");

Hello obj = new Hello();

Методы

Activator.GetObject()

Activator.CreateInstance()

Invoke()

С помощью

RemotingServices.IsTransparentProxy()

RemotingServices.GetRealProxy()

ChannelServices.RegisterChannel(new TCPChannel());

Hello obj =

 (Hello)Activator.GetObject(typeof(Hello), "tcp://localhost:8086/Hi");

if (obj == null) {

 Console.WriteLine("could not locate server");

 return 0;

}

if (RemotingServices.IsTransparentProxy(Obj)) {

 Console.WriteLine("Using a transparent proxy");

 RealProxy proxy = RemotingServices.GetRealProxy(obj);

 // proxy.Invoke(message);

}

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

System.Runtime.Remoting.RealProxy

RealProxy

ChannelServices

IChannelSender.CreateMessageSink()

Invoke()

Invoke()

Прокси посылает сообщение в канал. На серверной стороне будет сделан вызов метода после анализа сообщения, поэтому давайте рассмотрим сообщения.

Имеется несколько классов сообщений для вызова методов, ответов, возврата сообщений и т.д. Все классы сообщений должны реализовывать интерфейс

IMessage

Properties

URI

MethodName

MethodSignature

TypeName

Args

CallContext

Ниже представлена иерархия классов и интерфейсов сообщений:

Посылаемое реальному прокси сообщение является

MethodCall

IMethodCallMessage

IMethodMessage

IMessage

IDictionary

URI

ReturnMessage

Метод

Activator.GetObject()

RemotingServicesConnect()

Connect()

Unmarshal()

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

IMessageSink

□ Свойство

NextSink

□ Для синхронных сообщений вызывается метод

SyncProcessMessage()

IMessage

□ Для асинхронных сообщений вызывается метод

AsyncProcessMessage()

AsyncProcessMessage()

Рассмотрим три доступных для использования приемника сообщения.

Можно получить цепочку уполномоченных приемников с помощью интерфейса

IEnvoyInfo

ObjRef

EnvoyInfo

IEnvoyInfo

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

Объектный приемник ассоциируется с определенным объектом. Если объектный класс определяет атрибуты определенного контекста, то для объекта создаются приемники контекста.

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

□ Классы, маршализуемые по значению, обычно сериализуются через канал. Классы, которые должны быть маршализованы, либо реализуют интерфейс

ISerializable

[Serializable]

□ Классы, маршализуемые по ссылке, имеют удаленную идентичность. Объекты не передаются по линиям связи, а вместо этого возвращается прокси. Класс, который маршализуется по ссылке, должен выводиться из

MarshalByRefObject

MarshalByRefObject

MarshalByRefObject

ContextBoundObject

ContextBoundObject

MarshalByRefObject

ContextBoundObject

□ Классы, которые не являются сериализуемыми и не выводятся из

MarshalByRefObject

Чтобы увидеть маршализацию в действии, изменим удаленный объект для пересылки двух объектов клиенту: пусть класс

MySerialized

MyRemote

MySerilized

MyRemote

using System;

namespace Wrox.ProfessionalCSharp {

 [Serilizable]

 public сlass MySerilized {

  public MySerilized(int val) {

   a = val;

  }

  public void Foo() {

   Console.WriteLine("MySerialized.Foo called");

  }

  public int A {

   get {

    Console.WriteLine("MySerialized A called");

    return a;

   }

   set {

    a = value;

   }

  }

  protected int a;

 }

 public class MyRemote : System.MarshalByRefObject {

  public MyRemote(int val) {

   a = val;

  }

  public void Foo() {

   Console.WriteLine("MyRemote.Foo called");

  }

  public int A {

   get

    Сonsole.WriteLine("MyRemote.A called");

    return a;

   }

   set {

    a = value;

   }

  }

  protected int a;

 }

 /// <summary>

 /// Краткое описание Class1

 /// </summary>

 public class Hello : System.MarshalByRefObject {

  public Hello() {

   Console.WriteLine("Constructor called");

  }

  ~Hello() {

   Console.WriteLine("Destructor called");

  }

  public string Greeting(string name) {

   Console.WriteLine("Greeting called");

   return "Hello, " + name;

  }

  public MySerialized GetMySerilized() {

   return new MySerialized(4711);

  }

  public MyRemote GetMyRemote() {

   return new MyRemote(4712);

  }

 }

}

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

GetMySerialized()

GetMyRemote()

ChannelServices.RegisterChannel(new TcpChannel());

Hello obj =

 (Hello)Activator.GetObject(typeof(Hello),

 "tcp://localhost:8086/Hi");

if (obj == null) {

 Console.WriteLine("could not locate server");

 return;

}

MySerialized ser = obj.GetMySerialized();

if (!RemotingServices.IsTransparentProxy(ser)) {

 Console.WriteLine("ser is not a transparent proxy");

}

ser.Foo();

MyRemote rem = obj.GetMyRemote();

if (RemotingServices.IsTransparentProxy(rem)) {

 Console.WriteLine("rem is a transparent proxy");

}

rem.Foo();

В консольном окне клиента видно, что объект

ser

rem

В серверном выводе можно видеть, что метод

Foo()

MyRemote

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

[in]

[out]

[in, out]

В C# существуют аналогичные атрибуты как часть языка: параметры методов

ref

out

ref

out

ref

out

Как клиент и сервер определяют, какая возникла проблема и что при этом другая сторона более недоступна?

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

System.Runtime.Remoting.RemotingException

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

Этот механизм был эффективен в LAN, но не подходит для Интернета. Подумайте о тысячах или миллионах клиентов, посылающих ping-информацию на сервер. .NET Remoting использует существенно лучшее масштабируемое решение для управления временем жизни — LDGC (Leasing Distributed Garbage Collector — Сборщик мусора распределенной аренды. 

Это управление временем жизни активно только для активизированных клиентом объектов. Объекты

SingleCall

Для управления временем жизни можно сконфигурировать следующие значения:

□

LeaseTime

□ 

RenewOnCallTime

□ Если спонсор недоступен в течение

SponsorshipTimeout

□

LeaseManagerPollTime

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

□ Неявное обновление делается автоматически, когда клиент вызывает метод на удаленном объекте. Если текущее время аренды меньше, чем значение

RenewOnCallTime

RenewOnCallTime

□ При явном обновлении клиент определяет новое время аренды. Это делается с помощью метода

Renew()

ILease

ILease

GetLifetimeService()

□ Третьей возможностью обновления аренды является спонсорство. Клиент может создать спонсора, который реализует интерфейс

ISponsor

Register()

ILease

ClientSponsor

ISponsor

ILease

LeaseState

LifetimeServices

В этом небольшом примере кода доступ к информации аренды осуществляется с помощью вызова метода

GetLifetimeService()

ILease

System.Runtime.Remoting.Lifetime

Помните, что эти действия годятся только для активизированных клиентом объектов. Экземпляры объектов

SingleCall

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

ILease lease = (ILease)obj.GetLifetimeService();

if (lease != null) {

 Console.WriteLine("Lease Configuration:");

 Console.WriteLine(

  "InitialLeaseTime: " + lease.InitialLeaseTime);

 Console.WriteLine(

  "RenewOnCallTime: " + lease.RenewOnCallTime);

 Console.WriteLine(

  "SponsorshipTimeout: " + lease.SponsorshipTimeout);

 Console.WriteLine(lease.CurrentLeaseTime);

}

В результате получается следующий вывод в окне клиентской консоли:

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

System.Runtime.Remoting.Lifetime.LifetimeServices

LifetimeServices.LeaseTime = TimeSpan.FromMinutes(10);

LifetimeServices.RenewOnCallTime = TimeSpan.FromMinutes(2);

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

InitializeLifetimeService()

MarshalByRefObject

public class Hello : System.MarshalByRefObject {

 public Hello() {

  Console.WriteLine("Constructor called");

 }

 ~Hello() {

  Console.WriteLine("Destructor called");

 }

 public override Object InitializeLifetimeService() {

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

  lеase.InitialLeaseTime = TimeSpan.FromMinutes(10);

  lease.RenewOnCallTime = TimeSpan.FromSeconds(40);

  return lease;

 }

}

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

Вместо записи конфигурации канала и объекта в исходном коде, можно использовать конфигурационные файлы. Таким способом реконфигурируют канал, добавляют дополнительные каналы и т.д., не изменяя исходный код. Для этого, как и для всех других конфигурационных файлов на платформе .NET. используется XML на основе тех же самых приложений, о которых было написано в главе 10. В те же самые файлы в главе 25 будет добавлена конфигурация системы безопасности. В .NET Remoting имеются атрибуты и элементы XML для конфигурирования канала и удаленных объектов. Файл должен иметь то же самое имя, что и исполнимый файл, за которым следует

.config

HelloServer.exe

HelloServer.exe.config

clientactivated.config

wellknown.config

wellknownhttp.config

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

<configuration>

 <system.runtime.remoting>

  <application name="Hello">

   <service>

    <wellknown mode="SingleCall" type="Wrox.ProfessionalCSharp.Hello, RemoteHello" objectUri="Hi" />

   </service>

   <channels>

    <channel type="System.Runtime.Remoting.Channels.Tcp.TcpChannel, System.Runtime.Remoting" port="6791" />

    <channel type="System.Runtime.Remoting.Channels.Http.HttpChannel, System.Runtime.Remoting" port="6792" />

   </channels>

  </application>

 </system.runtime.remoting>

</configuration>

<configuration>

<system.runtime.remoting>

<application>

<system.runtime.remoting>

Посмотрим на основные элементы и атрибуты в

<system.runtime.remoting>

□ В элементе

<application>

name

<application name="Hellо">

Hello

□ На сервере элемент

<service>

<wellknown>

<activated>

□ Клиентской частью элемента

<service>

<client>

<service>

<wellknown>

<activated>

□ 

<wellknown>

<wellknown mode="SingleCall" type="Wrox.ProfessionalCSharp.Hello, RemoteHello" objectURI="Hi" />

□ В то время как атрибут

mode

SingleCall

Singleton

type

Wrox.ProfessionalCSharp.Hello

RemoteHello

objectURI

type

mode

objectURI

url

<wellknown type="Wrox.ProfessionalCSharp.Hello, RemoteHello" url="tcp://localhost:6791/Hello/Hi" />

□ Элемент

<activated>

type

<activated type="Wrox.ProfessionalCSharp.Hello, RemoteHello" />

□ Для определения канала, используется элемент

<channel>

<channels>

type

port

<channels>

 <channel type = "System.Runtime.Remoting.Channels.Tcp.TcpChannel, System.Runtime.Remoting" port="6791" />

 <channel type = "System.Runtime.Remoting.Channels.Http.HttpChannel, System.Runtime.Remoting" port="6792" />

</channels>

Этот пример файла

wellknown.config

Hello

Name

Wrox.ProfessionalCSharp.Hello

RemoteHello.dll

Hi

SingleCall

<configuration>

 <system.runtime.remoting>

  <application name="Hello">

   <service>

    <wellknown mode="SingleCall" type="Wrox.ProfessionalCSharp.Hello, RemoteHello" objectUri ="Hi" />

   </service>

   <channels>

    <channel type="System.Runtime.Remoting.Channels.Tcp.TcpChannel, System.Runtime.Remoting" port="6791" />

    <channel type="System.Runtime.Remoting.Channels.Http.HttpChannel, System.Runtime.Remoting" port="6792" />

   </channels>

  </application>

 </system.runtime.remoting>

</configuration>

Для хорошо известных объектов в клиентском конфигурационном файле

wellknown.config

RemoteHello.dll

Hi

Wrox.ProfessionalCSharp.Hello

tcp://localhost:6791/Hi

<configuration>

 <system.runtime.remoting>

  <application name="Client">

   <client url="tcp:/localhost:6791/Hello">

    <wellknown type = "Wrox.ProfessionalCSharp.Hello, RemoteHello" url="tcp://localhost:6791/Hello/Hi" />

   </client>

   <channels>

    <channel type="System.Runtime.Remoting.Channels.Tcp.TcpChannel, System.Runtime.Remoting" />

   </channels>

  </application>

 </system.runtime.remoting>

</configuration>

Внесем небольшое изменение в конфигурационный файл и можем использовать канал HTTP (как видно в

wellknownhttp.config

<client url="http://localhost:6792/Hello">

 <wellknown type="Wrox.ProfessionalCSharp.Hello, RemoteHello" url="http://localhost:6792/Hello/Hi" />

</client>

<channels>

 <channel type="System.Runtime.Remoting.Channels.Http.HttpChannel, System.Runtime.Remoting" />

</channels>

Преобразуя только конфигурационный файл (который находится в

clientactivated.config

<activated>

<service>

type

name

application

<configuration>

 <system.runtime.remoting>

  <application name="HelloServer">

   <service>

    <activated type="Wrox.ProfessionalCSharp.Hello, RemoteHello" />

   </service>

   <channels>

    <channel type="System.Runtime.Remoting.Channels.Http.HttpChannel, System.Runtime.Remoting" ports="6788" />

    <channel type="System.Runtime.Remoting.Channels.Tcp.TcpChannel, System.Runtime.Remoting" ports="6789" /»

   </channels>

  </application>

 </system.runtime.remoting>

</configuration>

Файл

clientactivated.config

url

<client>

type

<activated>

<configuration>

 <system.runtime.remoting>

  <application>

   <client url="http://localhost:6788/HelloServer" >

    <activated type="Wrox.ProfessionalCSharp.Hello, RemoteHello" />

   </client>

   <channels>

    <channel type="System.Runtime.Remoting.Channels.Http.HttpChannel, System.Runtime.Remoting" />

    <channel type="System.Runtime.Remoting.Channels.Tcp.TcpChannel, System.Runtime.Remoting" />

   </channels>

  </application>

 </system.runtime.remoting>

</configuration>

В серверном коде необходимо сконфигурировать удаленное использование статического метода

Configure()

RemotingConfiguration

ShowActivatedServiceTypes()

ShowWellKnovmServiceTypes()

public static void Main(string[] args) {

 RemotingConfiguration.Configure("HelloServer.exe.config");

 Console.WriteLine(

  "Application: " + RemotingConfiguration.ApplicationName);

 ShowActivatedServiceTypes();

 ShowWellKnownServiceTypes();

 System.Console.WriteLine("hit to exit");

 System.Console.ReadLine();

 return;

}

Эти две функции показывают данные конфигурации хорошо известных и активированных клиентом типов:

public static void ShowWellKnownServiceTypes() {

 WellKnownServiceTypeEntry[] entries =

  RemotingConfiguration.GetRegisteredWellKnownServiceTypes();

 foreach (WellKnownServiceTypeEntry entry in entries) {

  Console.WriteLine("Assembly: " + entry.AssemblyName);

  Console.WriteLine("Mode: " + entry.Mode);

  Console.WriteLine("URI " + entry.ObjectUri);

  Console.WriteLine("Type: " + entry.TypeName);

 }

}

public static void ShowActivatedServiceTypes() {

 ActivatedServiceTypeEntry[] entries =

  RemotingConfiguration.GetRegisteredActivatedServiceTypes();

 foreach(ActivatedServiceTypeEntry entry in entries) {

  Console.WriteLine("Assembly: " + entry.AssemblyName);

  Console.WriteLine("Type: " + entry.TypeName);

 }

}

В клиентском коде с помощью конфигурационного файла

client.exe.config

Remote

new

SingleCall

Singleton

RemotingConfiguration.Configure("HelloClient.exe.config");

Hello obj = new Hello();

if (obj == null) {

 Console.WriteLine("could not locate server");

 return 0;

}

for (int i=0; i < 5; i++) {

 Console.WriteLine(obj.Greeting("Christian"));

}

Аренда конфигурации для удаленных серверов также может делаться с помощью конфигурационных файлов приложений. Элемент

<lifetime>

leaseTime

sponsorshipTimeOut

renewOnCallTime

pollTime

<configuration>

 <system.runtime.remoting>

  <application>

   <lifetime leaseTime="15M" sponsorshipTimeOut="4M" renewOnCallTime="3M" pollTime="30s" />

  </application>

 </system.runtime.remoting>

</configuration>

Используя конфигурационные файлы, можно изменить удаленную конфигурацию, редактируя файлы вместо работы с исходным кодом. Легко изменить канал для использования HTTP вместо TCP, изменить порт, имя канала, и т. д. С помощью добавления одной строки сервер может слушать два канала вместо одного.

Не обязательно начинать создавать конфигурационный файл XML для .NET Remoting с чистого листа. Для этого существует несколько инструментов:

□ При использовании версии .NET Remoting Beta 1 можно найти пример

convertconfig.exe

□ С помощью примера

configfilegen.exe

configfilegen -ia:RemoteHello.dll -ос:HelloServer.exe.config -s -a

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

mmc mecorcfg.msc

При помощи этой утилиты можно изменить значения времени жизни, URI удаленных объектов и свойства канала.

До этого момента все примеры серверов выполнялись на автономных (self-hosted) серверах .NET. Автономный сервер должен запускаться вручную. Удаленный сервер .NET может запускаться во множестве других типов приложений. В службе Windows сервер автоматически запускается во время старта, и кроме того, процесс может выполняться с полномочиями системной учетной записи. Создание служб Windows описано в главе 24.

B ASP.NET существует специальная поддержка для серверов .NET Remoting. ASP.NET может использоваться для автоматического запуска удаленных серверов. В противоположность приложениям exe, ASP.NET Remoting использует для конфигурации другой файл.

Для того чтобы использовать инфраструктуру Информационного сервера Интернета (IIS) и ASP.NET, необходимо создать класс, произвольный из

System.MarshalByRefObject

web.config

bin

Чтобы сконфигурировать виртуальный каталог на сервере Web, воспользуйтесь Информационными службами ММС. Выберите Default Web Site и, открыв меню Action, создайте новый виртуальный каталог.

Конфигурационный файл

web.config

<configuration>

 <system.runtime.remoting>

  <application>

   <service>

    <wellknown mode="SingleCall" type="Wrox.ProfessionalCSharp.Hello, RemoteHello" objectUri = "HelloService.soap" />

   </service>

  </application>

 </system.runtime.remoting>

</configuration>

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

RemoteHello

HelloService.soap

web.config

<configuration>

 <system.runtime.remoting>

  <application>

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

    <wellknown type="Wrox.ProfessionalCSharp.Hello, RemoteHello" url="http://localhost/RemoteHello/HelloService.soap" />

   </client>

   <channels>

    <channel type="System.Runtime.Remoting.Channels.Http.HttpChannel, System.Runtime.Remoting" />

   </channels>

  </application>

 </system.runtime.remoting>

</configuration>

Хостинг удаленных объектов в ASF.NET поддерживает только хорошо известные объекты.

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

SoapSuds.exe

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

1. Определить интерфейс, который будет помещен в сборку.

2. Реализовать интерфейс в классе удаленного объекта. Чтобы сделать это, необходимо сослаться на сборку интерфейса.

3. На серверной стороне не требуется больше никаких изменений. Сервер можно программировать и конфигурировать обычным образом.

4. На клиентской стороне сошлитесь на сборку интерфейса вместо сборки удаленного объекта.

5. Клиент может теперь использовать интерфейс удаленного объекта, а не класс удаленного объекта. Объект можно создать с помощью класса

Activator

new

Интерфейс определяет контракт между клиентом и сервером. Два приложения могут теперь разрабатываться независимо друг от друга. Если при этом придерживаться старых правил COM об интерфейсах (что интерфейсы никогда не должны меняться), то не будет никаких проблем с версиями.

Можно также использовать утилиту

soapsuds

soapsuds

Следующая команда преобразует тип

Hello

RemoteHello.dll

HelloWrapper.dll

soapsuds -types:Wrox.ProfessionalCSharp.Hello, RemoteHello -oa:HelloWrapper.dll

С помощью

soapsuds

soapsuds -url:http://localhost:6792/hi -oa:HelloWrapper.dll

На клиенте теперь можно ссылаться вместо исходной сборки на созданную soapsuds сборку. Некоторые из возможностей перечислены в таблице.

Отладку и поиск неисправностей в приложениях, использующих .NET, можно проводить через службы удаленного отслеживания. Класс

System.Runtime.Remoting.Services.TrackingService

□ С помощью служебного класса

TrackingServices

ITrackingHandler

□ Интерфейс

ITrackingHandler

MarshaledObject()

UnmarshaledObject()

DisconnectedObject()

Чтобы увидеть службы слежения в действии на клиенте и на сервере, создадим новую библиотеку классов

TrackingHandler

TrackingHandler

ITrackingHandler

ObjRef

ObjRef

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Services;

namespace Wrox.ProfessionalCSharp (

 public class TrackingHandler : ITrackingHandler {

  public TrackingHandler() {

  }

  public void MarshaledObject(object obj, ObjRef or) {

   Console.WriteLine("--- Marshaled Object " + obj.GetType() + " ---");

   Console.WriteLine("Object URI: " + or.URI);

   object[] ChannelData = or.ChannelInfo.ChannelData;

   foreach(object data in ChannelData) {

    ChannelDataStore dataStore = data as ChannelDataStore;

    if (dataStore != null) {

     foreach (string uri in dataStore.ChannelUris) {

      Console.WriteLine("Channel URI: " + uri);

     }

    }

}

   Console.WriteLine("---------");

   Console.WriteLine();

  }

  public void UnmarshaledObject(object obj, ObjRef or) {

   Console.WriteLine("Unmarshal");

   public void DisconnectedObject(Object obj) {

   Console.WriteLine("Disconnect");

  }

 }

}

Серверная программа изменяется, чтобы регистрировать

TrackingHandler

using System.Runtime.Remoting.Services;

// ...

public static void Main(string[] args) {

 TrackingServices.RegisterTrackingHandler(new TrackingHandler());

 TCPChannel channel = new TCPChannel(8086);

 // ...

При запуске сервера первый экземпляр создается во время регистрации хорошо известного типа, и мы получаем следующий вывод. Вызывается

MarshaledObject()

Wrox.ProfessionalCSharp.Hello

Cnagel

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

Чтобы сделать асинхронный метод, создается делегат

GreetingDelegate

Greeting()

Greeting()

Greeting()

BeginInvoke()

BeginInvoke()

AsyncCallback

НеlloClient.Callback()

Callback()

EndInvoke()

using System;

using System.Runtime.Remoting;

namespace Wrox.ProfessionalCSharp {

 public class HelloClient {

  private delegate String GreetingDelegate(String name);

  private statiс string greeting; public static old Main(string[] args) {

   RemotingConfiguration.Configure("HelloClient.exe.config");

   Hello obj = new Hello();

   if (obj == null) {

    Console.WriteLine("could not locate server");

    return 0;

   }

   // синхронная версия

   // string greeting = obj.Greeting("Christian");

   // асинхронная версия

   GreetingDelegate d = new GreetingDelegate(obj.Greeting);

   IAsyncResult ar = d.BeginInvoke("Christian", null, null);

   // выполнить некоторую работу и затем ждать

   ar.AsyncWaitHandle.WaitOne();

   if (ar.IsCompleted) {

    greeting = d.EndInvoke(ar);

   }

   Console. WriteLine(greeting);

  }

 }

}

О событиях, делегатах и асинхронных методах можно прочитать в главе 6.

Метод, который возвращает

void

OneWay

OneWay

TakeAWhile()

RemoteHello

[OneWay]

public Void TakeAWhile(int ms) {

 Console.WriteLine("TakeAWhile started");

 System.Threading.Thread.Sleep(ms);

 Console.WriteLine("TakeAWhile finished");

}

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

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

□ Удаленный объект на сервере должен объявить внешнюю функцию (делегата) с сигнатурой метода, который клиент будет реализовывать в обработчике.

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

□ Удаленный объект должен также объявить экземпляр функции делегата, модифицированный ключевым словом event. Клиент будет использовать его для регистрации обработчика.

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

Чтобы понять это, рассмотрим пример. Создадим пять классов для всех частей обработки событий в .NET Remoting. Класс

Server

Server

RemoteObject

StatusEventArgs

StatusEventArgs

Класс

Client

EventSink

StatusHandler()

EventSink

RemoteClass

Класс удаленного объекта реализуется в файле

RemoteObject.cs

MarshalByRefObject

delegate

StatusEvent()

sender

StatusEventArgs

Метод, который реализуется на стороне клиента, требует строгих ограничений. Он может иметь только входные параметры, возвращаемые типы, при этом параметры

ref

out

[Serializable]

MarshalByRefObject

public delegate void StatusEvent(object sender, StatusEventArgs e);

public class RemoteObject : MarshalByRefObject {

Внутри класса

RemoteObject

Status

event

Status

public class RemoteObject : MarshalByRefObject {

 public RemoteObject() {

  Console.WriteLine("RemoteObject constructor called");

 }

 public event StatusEvent Status;

В методе

LongWorking()

Status(this, е)

Thread.Sleep()

Sleep

 public void LongWorking(int ms) {

  Console.WriteLine("RemoteObject: LongWorking() Started");

  StatusEventArgs e = new StatusEventArgs("Message for Client: LongWorking() Started");

  // породить событие

  if (Status != null) {

   Console.WriteLine("RemoteObject: Firing Starting Event");

   Status(this, e);

  }

  System.Threading.Thread.Sleep(ms);

  e.Message = "Message for Client: LongWorking() Ending"; // породить событие окончания

  if (Status != null) {

   Console.WriteLine("RemoteObject: Firing Ending Event");

   Status(this, e);

  }

  Console.WriteLine("RemoteObject: LongWorking() Ending");

 }

}

Мы видели в классе

RemoteObject

StatusEventArgs

[Serializable]

[Serializable]

public class StatusEventArgs {

 public StatusEventArgs(string m) {

  message = m;

 }

 public string Message {

  get {

   return message;

  }

  set {

   message = value;

  }

 }

 private string message;

}

Сервер реализуется внутри консольного приложения. Мы ожидаем только, чтобы пользователь завершил работу сервера после чтения конфигурационного файла и настройки канала и удаленного объекта:

using System;

using System.Runtime.Remoting;

namespace Wrox.ProfessionalCSharp {

 class Server {

  static void Main(string[] args) {

   RemotingConfiguration.Configure("Server.exe.config");

   Console.WriteLine("Hit to exit");

   Console.ReadLine();

  }

 }

}

Способ создания конфигурационного файла сервера

Server.exe.config

SingleCall

RemoteObject

<configuration>

 <system.runtime.remoting>

  <application name="CallbackSample">

   <service>

    <activated type="Wrox.ProfessionalCSharp.RemoteObject, RemoteObject" />

   </service>

   <channels>

    <channel type="System.Runtime.Remoting.Channels.Http.HttpChannel, System.Runtime.Remoting" port="6791" />

   </channels>

  </application>

 </system.runtime.remoting>

</configuration>

Приемник событий реализует обработчик

StatusHandler()

void

[OneWay]

StatusHandler()

EventSink

MarshalByRefObject

using System;

using System.Runtime.Remoting.Messaging;

namespace Wrox.ProfessionalCSharp; {

 public class EventSink MarshalByRefObject {

  public EventSink() { }

  [OneWay]

  public void StatusHandler(object sender, StatusEventArgs e) {

   Сonsole.WriteLine("EventSink: Event occurred: " + e.Message);

  }

 }

}

Клиент читает конфигурационный файл клиента с помощью класса

RemotingConfiguration

EventSink

using System;

using System.Runtime.Remoting;

namespace Wrox.ProfessionalCSharp {

 class Client {

  static void Main(string[] args) {

   RemotingConfiguration.Configure("Client.exe.config");

Различие начинается здесь. Мы должны создать локально экземпляр удаленного класса приемника

EventSink

<client>

RemoteObject

<client>

   EventSink sink = new EventSink();

   RemoteObject obj = new RemoteObject();

Теперь можно зарегистрировать метод обработчика объекта

EventSink

StatusEvent

StatusHandler()

StatusEvent

Вызывая метод

LongWorking()

StatusHandler()

   // зарегистрировать клиентский приемник на сервере — подписаться

   // на событие

   obj.Status += new StatusEvent(sink.StatusHandler);

   obj.LongWorking(5000);

Теперь мы более не заинтересованы в получении событий с сервера и отменяем подписку на событие. Следующий раз при вызове

LongWorking()

   // отменить подписку на событие

   obj.Status -= new StatusEvent(sink.StatusHandler);

   obj.LongWorking(5000);

   Console.WriteLine("Hit to exit");

   Console.ReadLine();

  }

 }

}

Конфигурационный файл для клиента —

client.exe.config

<channel>

<service>

EventSink

<configuration>

 <system.runtime.remoting>

  <application name="Client">

   <client url="http://localhost:6791/CallbackSample">

    <activated type="Wrox.ProfessionalCSharp.RemoteObject, RemoteObject" />

   </client>

   <channels>

    <channel type="System.Runtime.Remoting.Channels.Http.HttpChannel, System.Runtime.Remoting" port="777" />

   <channels>

  </application>

 </system.runtime.remoting>

</configuration>

Мы видим результирующий вывод на сервере: конструктор удаленного объекта вызывается один раз, так как имеется активированный клиентом объект. Затем происходит вызов метода

LongWorking()

LongWorking()

В выводе клиента видно, что события достигают его по сети:

Активированные клиентом объекты могут сохранять состояние для определенного клиента. Для активированных клиентом объектов на сервере требуются ресурсы. Для активированных сервером объектов

SingleCall

Контекст вызова перемещается вместе с логическим потоком выполнения и передается с каждым вызовом метода. Логический поток выполнения запускается из вызывающего потока выполнения и перемещается через все вызовы методов, которые запускаются из вызывающего потока выполнения и передаются через различные контексты, различные домены приложений и различные процессы.

Можно присвоить данные контексту вызова с помощью метода

CallContext.SetData()

SetData()

ILogicalThreadAffinative

CallContext.GetData()

Для данных контекста вызова здесь создается новая библиотека классов C# с вновь созданным классом

CallContextData

System.Runtime.Remoting.Messaging.ILogicalThreadAffinative

CallContextData

Serializable

using System;

using System.Runtime.Remoting.Messaging

namespace Wrox.ProfessionalCSharp {

 [Serializable]

 public class CallContextData : ILogicalThreadAffinative {

  public CallContextData() { }

  public string Data {

   get {

    return data;

   }

   set {

    data = value;

   }

  }

  protected string data;

 }

}

В классе

Hello

Greeting()

CallContextData

CallContextData.dll

CallContext

System.Runtime.Remoting.Messaging

public string Greeting(string name) {

 Console.WriteLine("Greeting started");

 CallContextData cookie = (CallContextData)CallContext.GetData("mycookie");

 if (cookie ! = null) {

  Console.WriteLine("Cookie: " + cookie.Data);

 }

 Console.WriteLine("Greeting finished");

 return "Hello, " + name;

}

В клиентском коде передается информация контекста вызова:

CallContextData cookie = new CallContextData();

cookie.Data = "information for the server";

CallContext.SetData("mycookie", cookie);

for (int i=0; i< 5; i++) {

 Console.WriteLine(obj.Greeting("Christian"));

}

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

В этой главе мы видели, что .NET Remoting использовать очень легко. Удаленный объект должен просто наследовать из объекта

MarshalByRefObject

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

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

delegate

event

Таким образом, использование .NET Remoting является очень простым, архитектура достаточно гибкой и по желанию расширяемой. Можно использовать каналы HTTP и TCP, которые также расширяются, или написать новые каналы с самого начала. Существуют форматтер SOAP и двоичный форматтер, но легко можно использовать свой собственный. Также имеется много точек перехвата, где возможно добавление в классы специальной функциональности, которая доставляется с помощью .NET Framework.