Шрифт:
Первой задачей этой главы является рассмотрение низкоуровневых возможностей, используемых средой CLR для передачи информации за границы доменов приложений. При обсуждении проблем удаленного взаимодействия .NET используется множество специальных терминов, таких так агент (т.е. proxy-модуль), канал, маршалинг по ссылке (который противопоставляется маршалингу по значению), серверная активизация объектов (в противоположность клиентской активизации) и т.д… После выяснения сути этих базовых терминов будет предложено несколько примеров программного кода, иллюстрирующих процесс построения распределенных систем в рамках платформы .NET.
Понятие удаленного взаимодействия .NET
Вы должны помнить из главы 13, что домен приложения [AppDomain] задает логические границы выполнения компоновочного блока .NET в рамках процесса Win32. Понимание этого очень важно для дальнейшего обсуждения распределенных приложений .NET, поскольку удаленное взаимодействие означает здесь не более чем взаимодействие двух объектов, сообщающихся через границы доменов. Соответствующие домены приложений могут физически находиться в следующих условиях.
• Два домена приложения определены в рамках одного и того же процесса (и поэтому на одной и той же машине).
• Два домена приложения определены в разных процессах на одной и той же машине.
• Два домена приложения определены в разных процессах на разных машинах.
С учетом этих трех возможностей становится ясно, что удаленное взаимодействие не обязательно предполагает наличие соединенных в сеть компьютеров. На самом деле все примеры, представленные в этой главе, могут вполне успешно выполняться на одной автономной машине. Независимо от расстояния между объектами, в отношении взаимодействующих агентов используются термины "клиент" и "сервер". Упрощенно говоря, клиент – это сущность, пытающаяся взаимодействовать с удаленными объектами, а сервер – это программный агент, содержащий удаленные объекты.
Пространства имен удаленного взаимодействия .NET
Перед тем как углубиться в детали процесса удаленного взаимодействия .NET. мы должны выяснить, какие функциональные возможности предлагают пространства имен, обеспечивающие удаленное взаимодействие. Библиотеки базовых классов .NET содержат очень много пространств имен, позволяющих строить распределенные приложения. Большинство типов, содержащихся в этих пространствах имен, находятся в mscorlib.dll, но дополнения и расширения базовых пространств имен вынесены в отдельный компоновочный блок System.Runtime.Remoting.dll. В табл. 18.1 предлагаются краткие описания пространств имен удаленного взаимодействия .NET 2.0.
Таблица 18.1. Пространства имен .NET для поддержки возможностей удаленного взаимодействия
| Пространство имен | Описание |
|---|---|
| System.Runtime.Remoting | Базовое пространство имен, которое должно использоваться при построении любого распределенного приложения .NET |
| System.Runtime.Remoting.Activation | Относительно малое пространство имен, в котором определяются несколько типов, обеспечивающих тонкую настройку процесса активизации удаленного объекта |
| System.Runtime.Remoting.Channels | Содержит типы, представляющие каналы и приемники каналов |
| Systern.Runtime.Remoting.Channels.Http | Содержит типы, использующие протокол HTTP для транспорта сообщений и объектов в удаленную точку и обратно |
| System.Runtime.Remoting.Channels.Ipc | Пространство имен, которое появилось в .NET 2.0 и содержит типы, использующие архитектуру IPC Win32. Архитектура IPC (Interprocess Communication – взаимодействие процессов) обеспечивает быстрое взаимодействие доменов приложений, существующих на одной физической машине |
| System.Runtime.Remoting | Базовое пространство имен, которое должно использоваться при построении любого распределенного приложения .NET |
| System.Runtime.Remoting.Activation | Относительно малое пространство имен, в котором определяются несколько типов, обеспечивающих тонкую настройку процесса активизации удаленного объекта |
| System.Runtime.Remoting.Channels | Содержит типы, представляющие каналы и приемники каналов |
| System.Runtime.Remoting.Channels.Http | Содержит типы, использующие протокол HTTP для транспорта сообщений и объектов в удаленную точку и обратно |
| System.Runtime.Remoting.Channels.Ipc | Пространство имен, которое появилось в .NET 2.0 и содержит типы, использующие архитектуру IPC Win32. Архитектура IPC (Interprocess Communication – взаимодействие процессов) обеспечивает быстрое взаимодействий доменов приложений, существующих на одной физической машине |
| System.Runtime.Remoting.Channels.Tcp | Содержит типы, использующие протокол TCP для транспорта сообщений и объектов в удаленную точку и обратно |
| System.Runtime.Remoting.Contexts | Позволяет конфигурировать параметры объектного контекста |
| System.Runtime.Remoting.Lifetime | Содержит типы, управляющие циклом существования удаленных объектов |
| System.Runtime.Remoting.Messaging | Содержит типы, используемые для создания и передачи объектов сообщений |
| System.Runtime.Remoting.Metadata | Содержит типы, используемые для настройки параметров генерированиям форматирования сообщений SOAP |
| System.Runtime.Remoting.Metadata.W3cXsd2001 | Содержит типы, представляющие формат XSD (XML Schema Definition – определение схемы XML) в соответствии со стандартами Консорциума W3C, принятыми в 2001 году |
| System.Runtime.Remoting.MetadataServices | Содержит типы, используемые средством командной строки soapsuds.exe при конвертировании метаданных удаленной инфраструктуры .NET в XML-схемы (и обратно) |
| System.Runtime.Remoting.Proxies | Содержит типы, обеспечивающие функциональные возможности для объектов, выполняющих задачи агента (proxy) |
| System.Runtime.Remoting.Services | Определяет ряд общих базовых классов (и интерфейсов), которые обычно используются только внутренними агентами удаленного взаимодействия |
Каркас удаленного взаимодействия .NET
Когда клиенты и серверы обмениваются информацией через границы приложений, среда CLR вынуждена использовать низкоуровневые примитивы, обеспечивающие настолько "прозрачное" взаимодействие сторон, насколько это возможно. Это значит, что вам, как программисту .NET, не нужно создавать огромные по объему блоки программного кода поддержки сетевого соединения, чтобы вызвать метод удаленного объекта. Также и серверному процессу не нужно "вручную" извлекать сетевой пакет из очереди и преобразовывать сообщение в формат, понятный удаленному объекту. Вы вправе ожидать, что среда CLR позаботится о таких деталях сама, используя свой стандартный набор примитивов удаленного взаимодействия (хотя, при желании, вы тоже можете принять участие в установке параметров соответствующего процесса).
В сущности, слой удаленного взаимодействия .NET обеспечивает аккуратную совместную работу следующих четырех ключевых элементов:
• агенты;
• сообщения;
• каналы;
• форматтеры.
Давайте рассмотрим каждый из указанных элементов по очереди и выясним, как их комбинация позволяет осуществлять удаленные вызовы методов.
Агенты и сообщения
Клиенты и объекты сервера взаимодействуют не напрямую, а через посредника, обычно называемого агентом (или proxy-модулем). Роль агента .NET заключается в создании для клиента иллюзии того, что он взаимодействует с запрошенным удаленным объектом в одном домене приложения. Чтобы создать такую иллюзию, агент предлагает интерфейс (члены, свойства, поля и т.д.), идентичный интерфейсу удаленного типа. С точки зрения клиента данный агент и является удаленным объектом. Однако "за кулисами" агент переправляет вызовы удаленному объекту.
Формально такой агент, вызываемый клиентом непосредственно, называется прозрачным агентом (transparent proxy). Этот объект, генерируемый средой CLR автоматически, несет ответственность за проверку того, что при вызове удаленного метода клиент получит нужное число параметров (и они будут нужного типа). Поэтому прозрачный агент можно интерпретировать, как фиксированный слой взаимодействия, который нельзя программно изменить или расширить.
В предположении о том, что прозрачный агент может выполнять проверку входных аргументов, соответствующая информация упаковывается в другой генерируемый средой CLR тип, который называется объектом сообщения. По определению все объекты сообщений реализуют интерфейс System.Runtime.Remoting.Messaging.IMessage.