ИСПОЛЬЗОВАНИЕ АТРИБУТОВ ДЛЯ ИДЕНТИФИКАЦИИ И ОТБОРА ПОДКЛЮЧАЕМЫХ ВЫПОЛНЯЕМЫХ ФУНКЦИЙ Российский патент 2011 года по МПК G06F9/54 G06F17/00 

Предупреждение об Авторском Праве и Разрешение

Часть описания изобретения этого патентного документа может содержать материал, который подпадает под охрану авторского права. Обладатель авторского права не имеет возражений на факсимильное воспроизведение кем-либо патентного документа или описания изобретения к патенту, когда это появляется в файлах с данными о патентах или в документации Патентного ведомства, но во всем остальном полностью сохраняет все авторские права. К данному документу должно применяться следующее уведомление: © Корпорация Майкрософт (Microsoft Corp.), 2005. Все права защищены.

Уровень техники

Программное обеспечение для установления связи между информацией, людьми, системами и устройствами, например Microsoft.NET (.NET), обеспечивает функциональную совместимость на базе Расширяемого языка разметки (XML - Extensible Markup Language) и в настоящее время совместимо с клиентскими, серверными, служебными приложениями и инструментальными средствами. Например, такие продукты, как Microsoft Windows^®, и Microsoft Office^® будут использовать .NET для установления связи с другими системами и приложениями. Для разработчиков программного обеспечения .NET проявляется в виде модели программирования, поставляемой в продукте Microsoft^®.NET Framework. Эта интегрированная среда является встроенным компонентом Microsoft Windows^®, который позволяет разрабатывать и запускать следующее поколение приложений и услуг Всемирной Паутины (Сети). Оно включает в себя технологии для сетевых услуг и сетевых приложений, доступа к данным, интеллектуальных клиентских приложений и многого другого.

Сетевые услуги вызываются по сети Интернет при посредстве стандартизированных протоколов производственной вычислительной сети, включающих в себя Простой Протокол Доступа к Объектам (SOAP - Simple Object Access Protocol), XML и технологию Универсального Описания, Поиска и Взаимодействия (UDDI - Universal Description, Discovery, and Integration). Они определяются через общественные организации стандартизации, такие как Консорциум Всемирной Паутины. SOAP представляет собой основанную на XML технологию передачи сообщений, стандартизированную Консорциумом Всемирной Паутины, которая устанавливает все необходимые правила для поиска сетевых услуг, интеграции их в приложения и установления связи между ними. UDDI представляет собой открытый реестр, предоставляемый бесплатно, где можно опубликовывать и запрашивать информацию о сетевых услугах. .NET включает в себя использование программных модулей с самоописанием, семантическое выделение в самостоятельные элементы отдельных выполняемых функций, входящих в стандартные протоколы связи сети Интернет и доступных посредством этих протоколов, таких как XML и SOAP.

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

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

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

Раскрытие изобретения

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

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

Другие преимущества и признаки настоящего изобретения описаны ниже.

Краткое Описание чертежей

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

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

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

Фиг.3 является графическим представлением, иллюстрирующим последовательность выполнения в первом примере реализации производства/потребления в соответствии с программными модулями, которые объединяются друг с другом путем производства и потребления выполняемых функций, которые удовлетворяют общему определению;

Фиг.4 является графическим представлением, иллюстрирующим последовательность выполнения во втором примере реализации производства/потребления в соответствии с программными модулями, которые объединяются друг с другом путем производства и потребления выполняемых функций, которые удовлетворяют общему определению;

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

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

Осуществление изобретения

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

Обратимся к Фиг.1, изображена функциональная схема, представляющая иллюстративное вычислительное устройство, подходящее для реализации процессов, изложенных выше. Например, исполняемые компьютерные инструкции, которые выполняют процессы и способы, чтобы использовать атрибуты для идентификации и отбора подключаемых выполняемых функций, могут постоянно находиться и/или исполняться в такой вычислительной среде (оборудовании), как изображенная на Фиг.1. Вычислительная системная среда 220 представляет собой только один пример подходящей вычислительной среды и не подразумевает предположения какого-либо ограничения относительно области применения или функциональных возможностей настоящего изобретения. Вычислительная среда 220 не должна интерпретироваться как имеющая какую-либо зависимость или требование касательно любого компонента, изображенного в иллюстративной операционной среде 220, или их комбинации. Например, компьютерная игровая консоль также может включать в себя такие элементы, как описанные ниже, для реализации процессов, изложенных выше.

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

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

Иллюстративная система для реализации аспектов настоящего изобретения включает в себя вычислительное устройство общего назначения в виде компьютера 241. Компоненты компьютера 241 могут включать в себя, но не ограничиваются этим, обрабатывающее устройство 259, системную память 222 и системную шину 221, которая соединяет различные системные компоненты, в том числе системную память и обрабатывающее устройство 259. Системная шина 221 может быть любого из нескольких типов шинных структур, включающих в себя шину памяти или устройство управления памятью, шину периферийных устройств и локальную шину, использующую любую из множества шинных архитектур. В качестве примера, но не ограничиваясь этим, такие архитектуры включают в себя шину архитектуры промышленного стандарта (ISA - Industry Standard Architecture), шину микроканальной архитектуры (MCA - Micro Channel Architecture), шину расширенной архитектуры промышленного стандарта (EISA - Enhanced ISA), локальную шину стандарта Ассоциации по стандартам в области видеоэлектроники (VESA - Video Electronics Standards Association) и шину соединения периферийных устройств (PCI - Peripheral Component Interconnect), также известную как шина расширения.

Компьютер 241 обычно включает в себя множество компьютерочитаемых носителей. Компьютерочитаемые носители могут быть любыми имеющимися в распоряжении носителями, к которым может получить доступ компьютер 241, и включают в себя и энергозависимые, и энергонезависимые носители, и съемные, и несъемные носители. В качестве примера, но не ограничиваясь этим, компьютерочитаемые носители могут содержать компьютерные запоминающие носители и носители передачи данных. Компьютерные запоминающие носители включают в себя и энергозависимые, и энергонезависимые, и съемные, и несъемные носители, реализованные любым способом или технологией хранения информации, такой как компьютерочитаемые инструкции, структуры данных, программные модули или другие данные. Компьютерные запоминающие носители включают в себя, но не ограничиваются этим, ОЗУ, ПЗУ, ЭСППЗУ, флэш-память или другую технологию памяти, компакт-диски (CD-ROM), цифровые диски универсального назначения (DVD) или другое запоминающее устройство на оптическом диске, магнитные кассеты, магнитную ленту, запоминающее устройство на магнитных дисках, или другие магнитные устройства хранения, или любой другой носитель, который может использоваться для хранения необходимой информации и к которому может получить доступ компьютер 241. Носители передачи данных обычно воплощают компьютерочитаемые инструкции, структуры данных, программные модули или другие данные в модулированном сигнале передачи данных, таком как несущая волна или другой транспортный механизм, и включают в себя любые носители для доставки информации. Термин "модулированный сигнал передачи данных" обозначает сигнал, у которого одна или более из его характеристик установлены или изменены таким образом, чтобы закодировать информацию в сигнале. В качестве примера, но не ограничиваясь этим, носители передачи данных включают в себя носители проводной среды, такой как проводная сеть или прямое проводное соединение, и носители беспроводной среды, такие как звуковые волны, радиочастоты, инфракрасное излучение и другие беспроводные среды. Комбинации любого из вышеупомянутого также должны входить в понятие компьютерочитаемых носителей.

Системная память 222 включает в себя компьютерный запоминающий носитель в виде энергозависимой и/или энергонезависимой памяти, такой как постоянное запоминающее устройство (ПЗУ) 223 и оперативное запоминающее устройство (ОЗУ) 260. Базовая система 224 ввода/вывода (БСВВ), содержащая основные процедуры, которые помогают передавать информацию между элементами внутри компьютера 241, например, во время запуска, обычно хранится в ПЗУ 223. ОЗУ 260 обычно содержит данные и/или программные модули, к которым обрабатывающее устройство 259 получает непосредственный доступ и/или которыми оно в настоящий момент оперирует. В качестве примера, но не ограничиваясь этим, Фиг.1 иллюстрирует операционную систему 225, прикладные программы 226, другие программные модули 227 и программные данные 228.

Кроме того, компьютер 241 может включать в себя другие съемные/несъемные энергозависимые/энергонезависимые компьютерные запоминающие носители. Только в качестве примера Фиг.1 иллюстрирует накопитель 238 на жестком диске, который осуществляет считывание или запись на несъемные, энергонезависимые магнитные носители, накопитель 239 на магнитном диске, который осуществляет считывание или запись на съемный, энергонезависимый магнитный диск 254 и накопитель 240 на оптическом диске, который осуществляет считывание или запись на съемный энергонезависимый оптический диск 253, такой как CD-ROM или другие оптические носители. Другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные запоминающие носители, которые могут использоваться в иллюстративном операционном окружении, включают в себя, но не ограничиваются этим, кассеты с магнитной лентой, платы флэш-памяти, цифровые диски универсального назначения, ленту с цифровой видеозаписью, твердотельное ОЗУ, твердотельное ПЗУ и тому подобное. Накопитель 238 на жестком диске обычно подсоединяется к системной шине 221 при помощи интерфейса несъемного запоминающего устройства, такого как интерфейс 234, а накопитель 239 на магнитном диске и накопитель 240 на оптическом диске обычно подсоединяются к системной шине 221 посредством интерфейса съемного запоминающего устройства, такого как интерфейс 235.

Накопители и связанные с ними компьютерные запоминающие носители, обсуждаемые выше и проиллюстрированные на Фиг.1, обеспечивают хранение компьютерочитаемых инструкций, структур данных, программных модулей и других данных для компьютера 241. На Фиг.1, например, накопитель 238 на жестком диске проиллюстрирован как хранящий операционную систему 258, прикладные программы 257, другие программные модули 256 и программные данные 255. Заметим, что эти компоненты могут или совпадать, или отличаться от операционной системы 225, прикладных программ 226, других программных модулей 227 и программных данных 228. Операционной системе 258, прикладным программам 257, другим программным модулям 256 и программным данным 255 в данном описании присвоены другие ссылочные значения, чтобы пояснить, что, как минимум, они являются другими копиями. Пользователь может вводить команды и информацию в компьютер 241 при помощи устройств ввода, таких как клавиатура 251 и координатно-указательное устройство 252, обычно именуемое как мышь, шаровой манипулятор или сенсорная панель. Другие устройства ввода (не показаны) могут включать в себя микрофон, рычажный указатель, игровой планшет, антенну спутниковой связи, сканирующее устройство или тому подобное. Эти и другие устройства ввода часто соединяются с обрабатывающим устройством 259 при помощи интерфейса 236 пользовательского ввода, который подсоединяется к системной шине, но могут соединяться посредством других интерфейса и шинных структур, таких как параллельный порт, игровой порт или универсальная последовательная шина (USB - universal serial bus). Монитор 242 или другой тип устройства отображения также соединяется с системной шиной 221 через интерфейс, такой как видеоинтерфейс 232. В дополнение к монитору компьютеры могут также включать в себя другие периферийные устройства вывода, такие как динамики 244 и устройство 243 печати, которые могут быть подсоединены при помощи интерфейса 233 периферийных устройств вывода.

Компьютер 241 функционирует в сетевом окружении, используя логические соединения с одним или более удаленными компьютерами, такими как удаленный компьютер 246. Удаленный компьютер 246 может быть персональным компьютером, переносным устройством, обслуживающим компьютером, маршрутизатором, сетевым ПК, равноправным устройством или другим публичным сетевым узлом и, как правило, включает в себя многие или все элементы, описанные выше касательно компьютера 241, несмотря на то, что на Фиг.1 проиллюстрировано только запоминающее устройство 247 хранения. Логические соединения, изображенные на Фиг.1, включают в себя локальную вычислительную сеть (ЛВС) 245 и глобальную вычислительную сеть (ГВС) 249, но могут также включать в себя другие сети. Такие сетевые окружения являются обычными в офисах, корпоративных вычислительных сетях, внутренних сетях и глобальной сети на базе технологии Интернет.

При использовании в сетевом окружении ЛВС компьютер 241 соединяется с ЛВС 245 при помощи сетевого интерфейса или адаптера (сопрягающего устройства) 237. При использовании в сетевом окружении ГВС компьютер 241, как правило, включает в себя модем 250 или другое средство для установления связи по ГВС 249, такой как Интернет. Модем 250, который может быть внутренним или внешним, может подсоединяться к системной шине 221 через интерфейс 236 пользовательского ввода или по другой подходящей схеме. В сетевом окружении программные модули, изображенные касательно компьютера 241, или их части могут храниться на удаленном запоминающем устройстве хранения. В качестве примера, но не ограничиваясь этим, Фиг.1 иллюстрирует удаленные прикладные программы 248 как постоянно хранящиеся на устройстве 247 хранения. Нужно понимать, что показанные сетевые соединения являются иллюстративными и может использоваться другое средство установления соединения между компьютерами.

Нужно понимать, что различные технологии, изложенные в настоящем описании, могут быть реализованы посредством аппаратного обеспечения или программного обеспечения или, когда это целесообразно, их комбинации. Таким образом, способы и устройство настоящего изобретения или некоторые их аспекты или части могут принимать форму программного кода (т.е. инструкций), воплощенного в материальных носителях, таких как гибкие диски, CD-ROM, жесткие диски или любой другой машиночитаемый носитель данных, причем, когда программный код загружается и исполняется на машине, например на компьютере, машина становится устройством для осуществления на практике настоящего изобретения. В случае исполнения программного кода на программируемых компьютерах компьютер обычно включает в себя обрабатывающее устройство, носитель данных, читаемый с помощью обрабатывающего устройства (в том числе энергозависимая и энергонезависимая память и/или запоминающие элементы), по меньшей мере, одно устройство ввода и, по меньшей мере, одно устройства вывода. Одна или более программ могут реализовать или использовать процессы, изложенные в отношении настоящего изобретения, например, с помощью использования ПИП (Программный Интерфейс Приложения), элементов управления многократного использования или т.п. Предпочтительно, чтобы такие программы были реализованы на процедурном или объектно-ориентированном языке программирования высокого уровня для связи с компьютерной системой. Однако при необходимости программа(ы) может быть реализована на языке ассемблера или на машинном языке. В любом случае язык может быть транслируемым или интерпретируемым языком и объединенным с аппаратной реализацией.

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

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

Интегрированная среда, система и процессы предоставляются и описываются в настоящем описании на основе идеи использования атрибутов Microsoft®.NET (.NET) для информирования о точках интегрирования и телах программного кода, которые соответствуют им. Однако использование атрибутов Microsoft.NET предусматривается в настоящем описании как часть примерного варианта осуществления и, следовательно, другие системы, интегрированные среды и/или платформы, которые обеспечивают атрибуты, до некоторой степени подобно тому, как в программном обеспечении Microsoft.NET, могут использоваться таким же образом.

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

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

Обратимся далее к Фиг.2, изображено графическое представление, иллюстрирующее, как при использовании атрибутов для идентификации и отбора подключаемых выполняемых функций программные модули объединяются друг с другом путем производства и потребления выполняемых функций, которые удовлетворяют общему определению. Концепция является частью композиционной модели для крупных расширяемых приложений. В этой модели приложения создаются модульным способом. Модули 262, 264, 268 объединяются друг с другом, производя и потребляя выполняемые функции, которые удовлетворяют общему определению, через прямые зависимости 272 в модуле 262 определения. Модули 268 производителя и модули 264 потребителя остаются независимыми друг от друга и связываются вместе косвенно 270 через модуль 262 определения, как показано на Фиг.2.

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

Ниже описывается механизм, с помощью которого загрузчик выполняет эти задачи. Атрибуты .NET используются для идентификации различных кодовых артефактов (таких, как классы, методы, свойства и т.д.) как являющихся определениями, производствами и/или потреблениями выполняемых функций. Эти атрибуты исследуются загрузчиком модуля и используются для создания взаимосвязей между установленными по отдельности модулем 268 производителя и модулем 264 потребителя. Ниже описаны два примера реализации.

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

Служебные определения присутствуют в модулях 262 определения и идентифицируются загрузчиком 304 модуля через отражение, обнаруживая определения класса атрибутов, которые удовлетворяют вышеупомянутым критериям (снабженные определенным ключом вследствие существования атрибута, который идентифицирует тип служебного объекта). Затем модули 268 производителя обеспечивают реализации типа служебного объекта ("служебные объекты") через свойства, которые статически подставляются из классов, которые несут системный атрибут, идентифицирующий их как классы 308 "служебного производителя", возвращают экземпляры типа служебного объекта и несут служебный атрибут, поставляя соответствующие данные для свойств этого атрибута, который описывает эту продукцию.

Загрузчик 304 модуля выявляет такие свойства через отражение, обнаруживая присутствие служебного атрибута в свойстве служебного класса производителя. Экземпляр служебного атрибута, который сопутствует каждому такому свойству, становится доступным потребителям этих служебных объектов, а также используется загрузчиком 304 модуля для сравнения при соответствии зависимостям, объявленным потребителями. Модули 264 потребителя указывают свое желание использовать служебные объекты, определяя классы ("служебные фабрики") 306, которые обеспечивают доступ к служебным объектам. Эти классы 306, которые обеспечивают доступ к служебным объектам, наследуют от системного базового класса, который параметризуется типом служебного атрибута и типом служебного объекта и при желании дополнен служебным атрибутом. Служебный атрибут объявляет зависимость от производителей, чьи экземпляры служебных атрибутов соответствуют тем, которые задаются служебной фабрикой 306.

Потребитель 264 создает экземпляр служебной фабрики 306, который подставляет свойство, которое возвращает экземпляр служебного атрибута, описывающего производителя 268, а также метод, который задействует служебное свойство продукции производителя. Реализация этого метода встроена в системный основной фабричный класс, который использует загрузчик 304 модуля, принимая к сведению установленные модули, чтобы знать, какой модуль 268 производителя загружать и вызывать для создания служебного объекта. Выбор модуля 268 производителя определяется, исходя из значения экземпляра служебного атрибута, заданного фабрикой. Точно так же потребитель может создать фабрику мультипроизводителя ("служебный брокер"), которая работает точно так же, как служебная фабрика 306, за исключением того, что она представляет продукции одного и того же типа служебного объекта.

Обратимся далее к Фиг.4, где изображено графическое представление, иллюстрирующее последовательность выполнения во втором примере реализации производства/потребления в соответствии с программными модулями, которые объединяются друг с другом путем производства и потребления выполняемых функций, которые удовлетворяют общему определению. Выполняемые функции, которые будут произведены/потреблены, определяются в этой второй реализации с помощью класса, называемого "порт" (Port) 403. Компоненты выполняемых функций, которые удовлетворяют определениям порта, называют "содействиями" 407. Содействие 407 содержит статический метод, которому сопутствуют метаданные 412. Эти метаданные, по меньшей мере, содержат идентификацию типа порта, который определяет содействие 409. Порт 403 является определением класса который наследует от системного базового класса 404, дополняется системным атрибутом, идентифицирующим его как определение 411 порта, наряду с нулем или большим количеством системных атрибутов 408, которые могут использоваться для установления соответствия метаданных с соответствующими содействиями, и содержит метод ("сигнатурный метод") (signature method) 413. Сигнатурный метод вызывает метод содействия через выполняемые функции из базового класса и определяет сигнатуру метода для содействий, определенных этим портом. Содействие 407 содержит метод, который соответствует сигнатурному методу 413 класса 403 порта и метаданным 412, связанным с этим методом, объявленным с использованием атрибутов 408, идентифицированных классом 403 порта.

Экземпляр класса 403 порта представляет ровно одно содействие 407, удовлетворяющее определению этого порта 403. Потребители получают экземпляры класса 403 порта от загрузчика 304 модуля с использованием системных объектов-распределителей (Dispenser), хранящихся в определенных атрибутивных полях. Загрузчик 304 модуля наполняет эти объекты-распределители во время загрузки экземплярами порта, которые соответствуют информации зависимости, объявленной в атрибутах, помещенных в полях. Потребители могут выполнять итерации по экземплярам порта из распределителей, исследовать метаданные из каждого содействия и вызывать метод содействия.

Фиг.4 иллюстрирует последовательность выполнения, задействованную в типичной продукции/потреблении, используя данный второй пример реализации. Фиг.4 показывает "единственный распределитель" 410, причем число возможных соответствий содействий ограничено единицей, исходя из метаданных, задаваемых на распределителе 410. В частности, этот распределитель 410 запрашивает, как пример, содействие "GizmoCreator" 402, для которого название марки (Brand Name) определено как "X" 412 415. Содействия с другими названиями марки не представлены, и это является ошибкой конфигурации, если присутствует больше чем одно содействие с названием марки, равным "X".

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

Пример реализации в контексте композиционной модели для крупных расширяемых приложений

Модульность признается важным аспектом разработки больших систем. Надежное проектирование расширяемых приложений подразумевает не только разделение выполняемых функций на модули, но и также требует простого, непротиворечивого и открытого шаблона взаимодействия, который специально разработан, чтобы способствовать полной расширяемости. Композиционная модель предписывает и приводит в исполнение такую модульность и шаблоны взаимодействия. Модульность, изложенная в настоящем описании, не создает границ для локализации типов или обращения к задачам управления версиями. Напротив, она является способом создания модульного, расширяемого кода там, где иначе пришлось бы формировать единый код. Модель находится на уровне типов CLR (Common Language Runtime - общеязыковая исполняющая среда), взаимодействующих через методы и свойства в пределах отдельного домена приложения. Она обеспечивает больший уровень абстракции, чем уровень типов, и является открытой, значит, внешние разработанные модули могут расширить систему, используя те же самые механизмы, которые выполняются основными системными модулями.

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

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

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

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

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

Для того чтобы знать, как программная система работает, необходимо различать ее логические части и понимать зависимости и взаимодействия между ними. В объектно-ориентированной системе этими частями обычно являются объекты (или их типы). Это работает хорошо, но не увеличивается неограниченно. Способность разработчиком осмысливать систему на уровне типов начинает быстро сокращаться, как только число типов в такой системе становится существенным, как, например, для современного объема продукта Visual Studio. Системы следующего поколения будут даже более сложными.

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

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

Расширяемость широко распространена в проектировании композиционной модели. Это не ограничивается возможностью приложений предоставлять "расширяемую модель" конечным пользователям. Сами приложения строятся на тех же механизмах расширяемости, которые раскрываются после внедрения. Личная мотивация должна повысить производительность больших групп, давая возможность им работать вместе над сложными системами более эффективно, производя и потребляя выполняемые функции, которые интегрируются с использованием модулей.

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

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

Непосредственная привязка к другим модулям ограничивает возможность многократного использования. Лучше привязываться к модулю, который содержит только публичное определение некоторых выполняемых функций, фактическая реализация которых обеспечивается неизвестным модулем. Таким образом, этот модуль может использоваться в другой конфигурации приложения, которая содержит то же самое публичное определение выполняемых функций, но совершенно другую реализацию, которая больше подходит для этого конкретного приложения. Такая косвенность свойственна проектированию этой модели. Это не только предусматривает возможность многократного использования, но и является ключевым аспектом того, чтобы быть открытой и подключаемой, такой, чтобы любой разработчик модуля мог производить выполняемые функции, которые соответствуют публичному определению, таким образом, расширяя систему. Это также обеспечивает превосходное средство установления явного разграничения между публично потребляемым API (Application Programming Interface - интерфейс прикладного программирования) и деталями частной реализации, представленной в системе.

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

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

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

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

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

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

Существуют три области, в которых эта модель играет роль в композиции приложения: компоновка, связывание и время прогона. Существуют определенные шаблоны программирования и технологии, которые используются в модели, и предусмотрены инструментальные средства контроля для проверки и обеспечения строгого соблюдения этих правил во время компоновки. Зависимости между модулями являются косвенными, но композиция приложения остается статической в этой модели. Собственно, есть связующая стадия, которая соединяет производителей и потребителей. Эта стадия концептуально происходит непосредственно перед временем прогона. Есть время прогона части системы, именуемой как "ядро", которая обрабатывает загрузку и активацию сборок, запросы на передачу от потребителей соответствующим производителям выполняемых функций и обеспечивает доступ к их сопутствующим метаданным. Однако однажды сконструированное и связанное вместе приложение обычно исполняется с очень небольшим участием ядра. Точки взаимодействия между сборками описываются статически в этой модели. В настоящем примере выполняемая функция перетасовки карт помещена в другую сборку (или, возможно, была предоставлена автору Poker.dll в виде другой сборки). Сборка покер может использовать код перетасовывания, просто добавляя ссылку на CardGameUtilities.dll и напрямую обращаясь к статическому методу. Взаимодействие между сборками в композиционной модели очень похоже на обращение к статическим методам. Ключевым различием является то, что имеется степень косвенности между производителем и потребителем требуемых выполняемых функций. Можно представить эту косвенность как 'интерфейс', который 'реализуется' статическим методом, точно так же, как класс реализует интерфейс. Вызывающая метод программа знает только форму метода, но не знает или не интересуется, из какой сборки он исходит.

Обратимся далее к Фиг.5, где изображено графическое представление, иллюстрирующее степень косвенности между производителем и потребителем требуемых выполняемых функций в соответствии с программными модулями, которые объединяются друг с другом путем производства и потребления выполняемых функций, которые удовлетворяют общему определению. Эта косвенность проиллюстрирована с вымышленным синтаксисом C# на Фиг.5. Как показано на Фиг.5, фактический код перетасовывания находится в неизвестной для Poker.dll 502 сборке. Это "реализует" метод "интерфейс", определенный в классе Shuffler 504, о котором вызывающая программа знает. Вызов от класса Poker 506 направлен на реализацию в классе MyCardShuffler 508. В зависимости от конфигурации приложения вызов мог бы быть направлен на совершенно другую реализацию перетасовывания, без изменения вызываемой сборки.

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

Набор из трех сборок 502, 504, 508, показанных на Фиг.5, является характерным для структуры из трех элементов, именуемых как определение, производитель и сборки потребителя, такие как описанные выше со ссылкой на Фиг.2-4, например. Термины сборка производителя и сборка потребителя обычно используются только в контексте единственного определения, такого как метод 510 ShuffleDeck, показанный на Фиг.5. Как правило, сборка производителя для одного определения взаимодействия является также сборкой потребителя для другого. Поэтому при отсылке к таким трансляциям используется термин сборка реализации, чтобы отличать их от сборок определения.

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

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

Сборки производителя добавляют ценность системе в виде содействий, которые являются статическими методами с некоторыми сопроводительными метаданными. Форма метода и метаданных определяется портом содействия (или портом). Порт является классом, который однозначно идентифицирует точку контакта между производителями и потребителями выполняемых функций. Экземпляр класса порта представляет единственное содействие, определенное этим портом, и обеспечивает доступ к метаданным, а также способ, чтобы задействовать метод этого содействия. Потребители получают экземпляры порта от специальных объектов, называемых распределители, которые хранятся в персональных полях, которые также несут объявление(я) зависимостей потребителя для соответствия содействиям. Эти поля, так же как методы содействия, являются членами статических классов, называемых брокеры (Broker). Брокеры "покупают и продают" (потребляют и производят) содействия, которые являются взаимосвязанными, чтобы формировать особый блок отклонения. Брокеры получают отклонение, когда они производят содействия, которые находятся в противоречии с другими, или зависят от содействий, которые не доступны.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модель Программирования

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

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

Типичный Сценарий

Для демонстрации модели программирования используется следующий сценарий взаимодействия. Предположим, что существует определение интерфейса, который представляет интерес для сборки потребителя. Детали того, что интерфейс делает, незначительны. Этот интерфейс называется, например, IGizmo. Сборка потребителя заинтересована в создании экземпляров этих штуковин (gizmos) открытым способом (это значит, что требуется дать возможность экземплярам поступать от любой сборки, возможно установленной как дополнение к приложению после внедрения).

При этом сценарии имеет смысл определить точку взаимодействия между этим потребителем и производителями как "фабрику штуковин" (gizmo factory). Может существовать любое число содействий этого типа "фабрики штуковин", но каждое содействие обладает одинаковой базовой линией поведения, которая состоит в том, чтобы создавать и возвращать экземпляр IGizmo.

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

Определение Порта

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

В дополнение к этому, чтобы наследовать от базового класса ContributionPort, определения порта должны также нести метаданные. Как минимум, определение порта должно быть дополнено атрибутом PortDefinition.

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

Учитывая эти требования, определение порта для настоящего типичного сценария выглядело бы следующим образом:

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

Производство Содействий

Теперь, когда порт определен, рассматривается, как сборка производителя предоставляет содействие фабрики штуковин. Содействия являются статическими методами с метаданными, и поэтому эти способы являются членами классов брокеров. Классы брокеры принадлежат сборкам реализаций и поэтому не являются публичными. Обычно они определяются как статические классы (если написаны на C#), потому что им никогда не приписываются значения, и они содержат только статические члены. Кроме того, они должны объявляться с атрибутом Broker, который идентифицирует их как классы брокеры.

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

Детали фактического приписывания значения объекту штуковины опускаются. Важными аспектами этого типичного кода является то, что атрибут производства идентифицирует CreateTurboGizmo как метод содействия для порта GizmoFactory и что метод является закрытым и статическим и имеет другое название, но в других отношениях соответствует сигнатурному методу порта. Это соответствует правилам согласования для методов содействия.

Потребление Содействий

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

Существуют два вида распределителей, один, называемый SingleDispenser (одиночный распределитель), и другой, называемый MultiDispenser (мультираспределитель). Как указывают их названия, они распределяют единственный экземпляр порта или набор экземпляров порта. Тип порта предоставляется в качестве параметра типа.

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

Ключевым здесь является поле d типа MultiDispenser<GizmoFactory>. Это поле распознается (посредством атрибута Consumption) и автоматически заполняется ядром, когда этот брокер загружен. Все содействия типа GizmoFactory представляются в распределителе, каждый с помощью экземпляра GizmoFactory. Как правило, это поле помечается как закрытое, и есть соответствующее свойство открытого доступа, которое раскрывает совокупность экземпляров порта для остальной части кода в сборке. Типом этого свойства является IList<> вместо MultiDispenser<>, просто потому что потребители этого свойства не нуждаются или не хотят знать, что это распределитель, с которым они имеют дело; они содержат информацию, фиксирующую, что у них есть список экземпляров порта. Фактически MultiDispenser<> не раскрывает никакие другие члены, кроме требующихся для осуществления интерфейса IList<>.

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

Последовательность Выполнения

Обратимся далее к Фиг.6, где изображено графическое представление, иллюстрирующее последовательность выполнения посредством настоящего сценария, от потребителя до отдельного производителя. Показана последовательность выполнения между сборкой 602 потребителя, сборкой 604 определения, ядром 606 и сборкой 608 производителя.

Добавление Метаданных

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

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

В новом типичном сценарии часть метаданных идентифицируется как связанная с содействиями фабрики штуковин: название марки. Первый этап должен определить атрибут, представляющий название марки, который понятен и поэтому опускается в настоящем описании. Предположим, что название этого атрибута - Brand, он объявляется как AllowMultiple=false и имеет однострочное свойство, именуемое Name. Для установления соответствия атрибута с портом используют атрибут ContributionMetadataType таким образом:

Этот атрибут разрешает присваивать атрибут Brand содействиям типа GizmoFactory. Фактически требуется, чтобы содействия были дополнены атрибутом Brand, и значение этого атрибута должно быть уникально для всех содействий GizmoFactory.

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

Доставка Метаданных с Содействиями

Теперь, когда определение порта было изменено, содействие тоже должно быть изменено, как показано ниже:

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

Потребление Метаданных

Доступ к метаданным, предоставленным содействиями, обеспечивается базовым классом ContributionPort обычным способом, посредством свойства, называемого Metadata, тип которого ContributionMetadata. Это, в сущности, совокупность атрибутов с универсальными удобными методами, называемых FindAttribute<> и FindAttributes<>, которые находят и возвращают экземпляры заданного типа атрибута.

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

Заметим, что считается 'безопасным' предположить, что вызов FindAttribute будет успешным, поскольку в определении порта объявлено, что атрибут Brand должен сопровождать все содействия.

Объявление Зависимостей

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

Требование, по меньшей мере, Одного Содействия

Как показано в вышеприведенном коде, код потребителя не объявляет никакой зависимости от содействий типа GizmoFactory. Самая простая форма объявления зависимости устанавливает потребность, по меньшей мере, в одном содействии. Это делается с помощью установления параметра Required в значение true на атрибуте Consumption, следующим образом:

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

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

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

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

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

Изобретение относится к сетевым технологиям, в частности к области подключаемых выполняемых функций, расширяемых клиентских приложений. Техническим результатом является обеспечение функциональной совместимости подключаемых выполняемых функций. Способ включает: обнаружение программного модуля потребителя, сконфигурированного для потребления упомянутых функциональных возможностей, обнаружение модуля определения, причем модуль определения сконфигурирован для определения программного интерфейса для упомянутых функциональных возможностей и атрибута для объявления определения функциональных возможностей, которое соответствует упомянутым функциональным возможностям, обнаружение программного модуля производителя. Устанавливают связь между программным модулем потребителя и программным модулем производителя, чтобы программный модуль потребителя потреблял функциональные возможности, созданные программным модулем производителя. 4 н. и 16 з.п. ф-лы, 6 ил.

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

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

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

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

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

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

7. Способ по п.6, в котором экземпляр класса служебной фабрики сконфигурирован возвращать экземпляр служебного атрибута, содержащий метаданные, ассоциированные с программным модулем производителя.

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

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

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

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

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

13. Система по п.12, в котором класс порта дополнительно содержит:
сигнатурный метод, определяющий содействие, ассоциированное с классом порта, и
атрибут ассоциации метаданных для ассоциирования метаданных с содействием, которое соответствует упомянутому классу порта.

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

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

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

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

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

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

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