InfoCity
InfoCity - виртуальный город компьютерной документации
Реклама на сайте







Размещение сквозной ссылки

 

Объектно-ориентированная разработка ПО стала проще благодаря сервисам COM+


Мэри Кертлэнд


Мэри Кертлэнд: программный менеджер группы разработчиков Microsoft COM. В настоящее время работает над книгой, посвященной COM+, которая будет выпущена Microsoft Press в 1998 году.

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

Данная статья предполагает знакомство с COM


Скоро создание компонентно-ориентированного ПО существенно упростится благодаря новому расширению COM (Component Object Model - компонентная модель объектов), пока называемому COM+. COM+ предназначена для радикального упрощения создания и использования программных компонентов. COM+ обеспечивает среду выполнения (runtime) и сервисы, которые готовы к использованию из любого языка программирования или инструмента, и обеспечивает тесное взаимодействие компонентов, независимо от того, как они были реализованы. В этой статье мы остановимся на основных проблемах объектно-ориентированной разработки и обсудим, как COM+ помогает их решить. Будущие статьи будут посвящены модели программирования COM+ и сервисам, предоставляемым COM+. На момент опубликования этой статьи механизмы и сроки поставки COM+ еще не были объявлены, и еще не было даже альфа-версии, так что некоторые детали могут измениться.

Содержание


Обзор
Почему COM+?
Разработка становится еще проще
Архитектура COM+
Основные преимущества архитектуры COM+
Эволюция, а не революция
MICROSOFT DEVELOPER NETWORK ONLINE

Обзор


Основная идея объектно-ориентированного ПО заключается в том, что пользовательские задачи выражаются в терминах объектов и операций, которые можно выполнять над этими объектами. В первом приближении объекты - это вещи, понятные пользователю. Например, в системе бронирования билетов на самолет, пассажир, рейс и место - это типы объектов, понятные агенту туристического бюро. По мере реализации будут определены дополнительные типы объектов, которые будут более понятны разработчику. Концептуально, вы всегда думаете об объектах. Класс - это тип объекта, заданный с точки зрения его состояния и поведения. Состояние определяется набором свойств. Значения этих свойств задают состояние объекта, но сам набор свойств одинаков для всех объектов данного класса. Поведение определяется общедоступными методами, которые клиенты могут вызывать для изменения состояния объекта. Клиенты могут взаимодействовать с объектом только через его свойства и через методы. Обратите внимание, что понятия свойств и методов не подразумевают никаких знаний о том, как данный класс реализован, и в идеале, клиент вообще не должен ничего знать о конкретной реализации. По мере создания классов вы можете обнаружить, что определенные группы методов используются более, чем одним классом. Исходя из этого, вы можете построить общую схему поведения, определив интерфейсы. Интерфейс - это просто определение связанного набора свойств и методов без реализации. Интерфейсы реализуются классами и являются мощным инструментом для повторного использования. Допустим, есть два класса, А и Б, которые реализуют интерфейс IAddress. Так как взаимодействие с объектами происходит через общедоступные интерфейсы, клиенту, имеющему указатель на IAddress, не нужно знать, обращается он к классу А или к классу Б, или даже что А и Б вообще существуют! Более того, А и Б могут абсолютно не подозревать о существовании друг друга. Возможность работать с несколькими классами объектов так, как будто они одного типа, известна как полиморфизм.

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

[Приводимая здесь информация основана на предварительной версии ПО и публикуется без подтверждения со стороны Microsoft Corporation. Microsoft Corporation не дает никаких гарантий относительно точности или полноты этой информации. Поскольку любая информация может измениться, предлагаем читателям использовать ее на свой страх и риск.]

Объектно-ориентированные языки программирования, такие как C++ и Java(tm), предлагают средства, позволяющие реализовывать классы и интерфейсы. Каждый язык в той или иной степени ограничивает доступ к объектам для общедоступных интерфейсов и имеет свое, несколько отличное, представление об интерфейсах. Однако описанные здесь основы универсальны. Обычно языки объектно-ориентированного программирования направлены на создание приложения с использованием одного процесса, одного языка. Но писать весь код приложения на одном языке не всегда рационально. Например, вы можете захотеть создать пользовательский интерфейс с помощью RAD-инструментов, но код, обрабатывающий инструментальные данные, нужно написать на C++, чтобы можно было воспользоваться библиотекой математических функций. Вам придется изучить механизмы взаимодействия между процессами или между машинами, чтобы приложение могло работать с разными машинами. Большинство языков «подталкивают» к наследованию реализации, а это может вызвать проблемы, если придется изменять базовые классы.

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

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

Взятые вместе, COM и объектно-ориентированные языки программирования обеспечивают мощные средства упрощения процесса разработки. Вы можете сконструировать системы взаимодействующих COM-объектов и написать компоненты COM, используя объектно-ориентированные языки. Но хотя модель программирования COM выглядит просто, создать компоненты и основанные на них приложения гораздо труднее, чем кажется. Одна из проблем состоит в несовпадении представлений об объекте в COM и в инструментах и языках, что усложняет изучение компонентной разработки. Это также очень усложняет разработку компонентов и системных сервисов, которыми реально могут воспользоваться другие языки или инструменты. Например, многие инструментальные средства и языки поддерживают только частичный набор возможностей COM, в результате общедоступные компоненты ограничиваются рамками набора, поддерживаемого инструментами (например, Автоматизация - Automation) или должны реализовывать функциональность несколькими способами. В идеале COM должна давать однозначное представление о доступных объектах, совместимое с понятиями объектов в современных объектно-ориентированных языках и инструментах. Она также должна гарантировать, что новые API и сервисы можно будет легко вызвать из любого компилируемого или интерпретируемого языка без дополнительной разработки, тестирования или изучения документации. И что все объекты, независимо от их происхождения, будут взаимодействовать между собой.

Если вы взглянете на типичный компонент или приложение, написанные на С++, то заметите, что основная часть кода не занимается решением поставленной задачи. Есть код для инициализации сервисов, код для взаимодействия с операционной системой, код для «проталкивания» системной информации - много кода. Большая часть кода копируется из приложения в приложение и из компонента в компонент. Такие инструменты, как Visual Basic, поступают более мудро, помещая такие распространенные участки кода в специфичный для инструмента сервис периода выполнения (tool-specific runtime) и позволяя разработчикам сконцентрировать свое внимание на коде, который решает бизнес-проблемы. Чтобы предоставить такой же сервис программистам на С++, были разработаны многочисленные объектные библиотеки (frameworks) и генераторы приложений. У специфичных для инструмента сервисов периода выполнения и объектных библиотек есть недостатки: вы ограничены рамками возможностей, поддерживаемых конкретным средством. Большинство инструментов начинают поддерживать возможности новой операционной системы с заметным опозданием. Однако если операционная система предоставляет сервис периода выполнения, новые возможности могут без задержки использоваться всеми инструментами разработки. Кроме того, если вы работаете с компонентами, написанными с помощью нескольких средств, то в память вероятно будет загружено много таких сервисов, при этом объем используемой приложением памяти не обязательно возрастет. В конечном счете, наверное, единственным необходимым сервисом периода выполнения является сервис, предоставляемый системой. Что касается специфичных для инструмента сервисов выполнения, вам нужно удостовериться, что они установлены везде, где используются опирающиеся на них компоненты. Предоставляемый системой сервис периода выполнения практически всегда устанавливается автоматически.

В добавок к упрощению создания компонентов во многие инструменты введены новшества, упрощающие разработку приложений, поддерживающих COM. Некоторые из этих новых возможностей правильнее будет отнести к системному уровню. Например, в библиотеке Active Template Library (ATL) введен использующий сценарии механизм, упрощающий регистрацию компонентов. Visual Basic предлагает простой доступ к данным через управляющие элементы с возможностью связи с данными (data-bound controls). Эти две черты нужны многим компонентам. В Microsoft Transaction Server (MTS) введено много возможностей, упрощающих написание масштабируемых, распределенных приложений. Помимо поддержки транзакций, MTS обеспечивает среду периода выполнения с сервисами управления потоками и объектами. Разработчики могут создавать компоненты, исходя из того, что только один клиент в каждый момент времени будет иметь доступ к их объектам - MTS сделает все остальное. Это существенно упрощает разработку компонентов.

Основанные на ролях (role-based) службы безопасности MTS предлагают как декларативный, так и программный доступ. Основанная на ролях защита весьма интересна (что будет показано чуть ниже), многие службы могли бы использовать декларативный доступ к сервисам. Разве не проще вместо того, чтобы писать код для передачи данных функциям инициализации системных служб, просто установить значение атрибута и позволить системе самой разобраться, как передать это значение службе? Другим преимуществом декларативного доступа является то, что он позволяет отложить полную инициализацию значений атрибутов до внедрения приложения. Например, если вы применяете основанную на ролях защиту, то вы просто говорите, какая роль отводится определенному компоненту. Позже администратор определяет реальные пользовательские записи для каждой роли. MTS наглядно демонстрирует одно ограничение существующей архитектуры COM: отсутствие стандартного механизма для добавления внешних служб к COM. Конечно, всегда можно задать интерфейсы и написать компоненты. Но что если вы захотите «прицепиться» к процессу активизации объекта, или отследить вызовы методов? MTS изменяет реестр так, чтобы вызываться всякий раз при создании объекта и создавать «оболочку» (wrapper), которая располагается между клиентами и реальным объектом. Это отлично работает с MTS, но что будет, если появиться вторая служба, которая захочет сделать то же самое?

Почему COM+?


COM - вполне успешная объектная модель, поддерживающая широкий спектр инструментов и дающая сторонним фирмам простор для деятельности на рынке компонентов. И все же, как объяснялось выше, существуют детали, которые можно было бы улучшить. COM+ пытается сделать это. Основными задачами COM+ являются:

  • Упростить построение компонентов COM
  • Решить ключевые проблемы в разработке и внедрения приложений, основанных на COM
  • Предоставить новые сервисы для COM-разработчиков
  • Обеспечить стандартный механизм расширения для включения новых возможностей

Две первые задачи решаются сервисом периода выполнения COM+. Как показано на рис. 1, этот сервис явился результатом выполненной в Microsoft работы по упрощению написания COM-объектов на определенных языках. Выполнением двух последних задач занимаются службы, построенные на сервисе периода выполнения COM+, которые эволюционировали из более ранних разработок, использовавшихся в COM и MTS. Сервис периода выполнения и службы вместе составляют COM+.

Разработка становится еще проще


Сегодня разработчик объектов на основе COM (или создатель набора инструментов для COM-разработки) должны заботиться о многих вещах, на первый взгляд не имеющих отношения к реальной функциональности ваших компонентов (см. рис. 2). Каждый компонент должен обеспечить реализацию интерфейса IUnknown для поддержки подсчета ссылок и сервисы QueryInterface. Клиенты объекта должны корректно использовать счетчик ссылок для управления временем жизни объекта и обращаться к QueryInterface для получения доступа к возможностям этого объекта. Кроме того, для каждого компонента требуется фабрика классов, которая «знает», как создавать объекты определенного типа, и код упаковки, необходимый для правильной инициализации компонента в системе во время выполнения. Далее, компоненты должны обеспечить регистрационную информацию. Следует описать новые интерфейсы через IDL (язык описания интерфейсов), который генерирует динамически подключаемые библиотеки (DLL) заместителей/заглушек и библиотеки типов. Если нужно обеспечить доступ к компоненту из языков сценариев, необходимо реализовать поддержку Автоматизации через интерфейс IDispatch и другие интерфейсы. Компоненты, которые будут запускать события, и клиенты, которые будут принимать события, должны реализовывать интерфейсы IConnectionPoint. Вам также нужно обратить внимание на то, поддерживает ли используемый вами набор инструментов двоичный стандарт COM для размещения объектов в памяти. Большая часть кода, реализующего IUnknown, IDispatch, события, фабрики классов и упаковку компонентов, почти идентична для всех компонентов. Таким образом, первая цель COM+ - предоставить сервис периода выполнения, обеспечивающий реализацию по умолчанию для решения всех перечисленных задач в наиболее распространенных сценариях (см. рис 2). Разработчики лишь реализуют классы для поддержки логики приложений и предоставляют информацию, описывающую характеристики классов - остальное делает сервис времени выполнения COM+. Не требуется специального кода для регистрации класса, описания его функциональных возможностей для клиентов, создания фабрик классов для построения объектов, управления временем жизни объектов или для чего-нибудь еще, что не имеет прямого отношения к бизнес-логике, инкапсулируемой этим компонентом. Если реализация сервиса периода выполнения не отвечает вашим потребностям, вы всегда можете использовать традиционную COM-технологию для обеспечения своей собственной реализации.

Если вы используете такие средства, как Visual Basic, вы наверное удивлены - о чем, собственно, здесь идет речь? Ведь Visual Basic уже решает все эти вопросы для разработчика компонентов и клиента компонентов. Преимущество системного сервиса времени выполнения заключается в том, что один и тот же сервис периода выполнения могут использовать любые компоненты, независимо от языка разработки. Это обеспечивает выигрыш в производительности и более устойчивое поведение компонентов. Но настоящее преимущество COM+ перед Visual Basic - это механизмы расширения и службы, которые будут описаны ниже.

Вторая цель COM+ - решить ключевые вопросы разработки и развертывания приложений, основанных на COM. Некоторые трудности вы, вероятно, испытали на себе, если создание компонентов было связано с определением новых интерфейсов через IDL. В COM+ интерфейсы определены с помощью стандартных языков программирования; вам не нужно возиться с IDL или с отдельными файлами, задающими интерфейсы. Чтобы спродуцировать метаданные, определяющие интерфейсы, инструменты используют сервис периода выполнения COM+. Этих метаданных достаточно для автоматической генерации заместителей (proxies) и заглушек (stubs), что, конечно, упрощает процесс построения и установки компонентов.

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

Кроме того, COM+ определяет более простую, более рациональную модель регистрации, установки и отслеживания версий компонентов. В эту модель вошло все самое лучшее из служб загрузки кода Win32, пакетов MTS, хранилища классов Windows NT и административных средств COM. И все это скомбинировано в надежную, простую в использовании службу.

Пакет (package) - это один развертываемый блок кода, содержащий один или несколько классов. Пакет может также олицетворять какое-то понятие, такое как «пользователь» или «машина». Информация о пакетах хранится в хорошо известном месте на каждой машине. Системные администраторы или средства разработчика могут поддерживать эту информацию. Для создания регистрационной информации нет необходимости писать код. Служба регистрации предоставляет механизм для обновления версий класса, связанных с каким-либо пакетом. Это помогает решить одну из наиболее неприятных проблем компонентных приложений. Приведем пример. Допустим, приложение А использует версию 1.0 компонента С и работает прекрасно. Приложение Б поставляет версию 2.0 компонента С и работает прекрасно, но приложение А останавливается. Используя сервис периода выполнения COM+, можно использовать обе версии компонента С: версию 1.0 для приложения А и версию 2.0 для приложения Б. Разработчики могут без труда применять эти службы. Вы просто напишете классы для нового компонента и предоставите атрибуты классов - а остальное пусть делают сервисы периоды выполнения COM+. Основная часть работы по перемещению компонентов сведется к удалению кода. Результирующие компоненты являются компонентами COM и будут работать с любым инструментом, который может использовать COM-компоненты. Но их проще написать и установить, чем стандартные компоненты COM.

Новые сервисы периода выполнения


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

Во-первых, COM+ позволяет вам использовать классы напрямую, а не только через интерфейсы классов. Клиентам не нужно беспокоиться об указателях на интерфейсы, счетчиках ссылок или QueryInterface. Доступ к объектам будет предоставляться через ссылки на объекты. Объекты по-прежнему являются COM-объектами с подсчетом ссылок, но этими убийственными деталями уже ведает сервис периода выполнения. Звучит заманчиво, не правда ли? Да, конечно, но чтобы этим воспользоваться, инструменты должны «понять», что собой представляют ссылки на объекты, и должен быть изменен существующий клиентский код.

COM+ также поддерживает наследование реализации. Если вы решите использовать классы напрямую, вы также будете иметь возможность сделать ваши классы наследуемыми или сами создать подклассы существующих классов. COM+ не решает всех вопросов, связанных с наследованием реализации: по-прежнему остаются проблемы «хрупкого» базового класса и контроля версий. Вычисление, когда подкласс должен вызвать замененные методы базового класса, не намного лучше (у вас, скорее всего, не будет исходных текстов базового класса). А ведь мы еще даже не заикнулись о влиянии на клиентов... Но в определенных обстоятельствах наследование реализации может быть полезно - и COM+ позволит вам прибегнуть к ней в случае необходимости. COM+ помогает предотвратить «утечку» памяти путем «сборки мусора» (garbage collection). Как вы можете себе представить, «сборка мусора» может иметь радикальные последствия как для вашего класса, так и для его клиентов. Вам не нужно беспокоиться о подсчете ссылок и вы можете спокойно работать с циклическими ссылками без какого бы то ни было механизма для прерывания цикла. Но это означает, что ваши объекты, возможно, будут иметь непредсказуемое время жизни. В зависимости от того, как реализована «сборка мусора», объекты могут не уничтожиться, когда счетчик ссылок дойдет до нуля; они уничтожатся, когда «сборщик мусора» решит их уничтожить. Такая проблема особенно актуальна, если ваш объект зависит от «дорогих», или ограниченных ресурсов. Вдобавок к этому, определенные языковые возможности, которые вы считаете незыблемыми, могут быть несовместимы со «сборкой мусора» (например, библиотека периода выполнения С). Детали того, как такие возможности будут реализованы, еще пока не определены.

Наиболее сложным аспектом COM для большинства разработчиков является защищенный доступ к компонентам. Поэтому сервис COM+ периода выполнения предоставляет модель защиты, которая комбинирует и расширяет модели защиты, предлагаемые COM, MTS, Microsoft Java Virtual Machine (VM) и Authenticode. Это обеспечивает многоуровневую защиту пользователя и кода и в то же время упрощает разработку и развертывание компонентов, которые нужно обезопасить. Проверки доступа основаны на двух ключевых абстракциях: роли и привилегии. Роль - это абстрактная группа пользователей. Привилегии обеспечивают доступ к ресурсам.

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

Защита кода также обеспечивается на основе Authenticode и зон защиты. Технология Authenticode - это механизм, помечающий код и гарантирующий, что полученный вами код абсолютно идентичен коду, который вам предоставил провайдер, и что вам известен провайдер. Она применяется при загрузке кода по сети и установке. Концепция зон была введена в Microsoft Internet Explorer 4.0. Зона - это группа источников кода, обладающая определенными привилегиями. Трастовая защита работает вместе с защитой доступа. Когда выполняются проверки прав доступа, не только пользователь должен быть членом требуемой роли и иметь необходимые привилегии, но и сам компонент должен принадлежать зоне с требуемыми привилегиями.

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

Сервисы для распределенных приложений


Возможности, которые мы обсуждали до сих пор, упрощают создание компонентов. Но мы еще не говорили о решении проблем, связанных с написанием компонентных распределенных приложений. Вот здесь COM+ действительно предстает во всей красе. COM+ содержит общий механизм расширения, называемый перехватом (interception). Расширения COM+ -перехватчики - могут получать и обрабатывать события, связанные с созданием, вызовами, возвратами, ошибками и удалением. COM+ использует перехватчики для предоставления доступа к данным и распределенных служб.

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

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

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

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

COM+ также будет включать новые, простые в использовании сервисы, основанные на возможностях, впервые появившихся в средствах, поддерживающих COM - таких как Visual Basic. Ключевой сервис - декларативное связывание с данными. Он очень похож на связывание данными в формах, предлагаемое сейчас Visual Basic. В Visual Basic вы «бросаете» на форму управляющие элементы источника данных и компоненты, связываемые с данными, привязываете управляющий элемент источника данных к базе данных, а компонент, отображающий данные- к определенным полям базы данных. В COM+ к классам добавлен атрибут базы данных для связи с последней. Класс содержит одно или более полей источников данных, у которых также некоторые из этих свойств определены, например, оператор SQL для выполнения. Поля связи с данными ассоциированы с полем источника данных и результатами запроса. Когда бы ни обновлялся источник данных, все поля связи с данными обновляются значениями, которые соответствуют связанными с ними запросам. Связывание данных функционирует благодаря ядру связывания , которое является перехватчиком времени выполнения всех единиц классов, поддерживающих связывание с данными. При активизации модуля ядро связывания гарантирует, что будет получена и ассоциирована правильная связь с источником данных.

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

Архитектура COM+


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

Первый набор служб, предоставляемый сервисом периода выполнения COM+, - это интерфейсы для задания и использования определений классов, интерфейсов и библиотек. Как показано на рис. 4, класс задается путем написания исходного кода. Используемый язык будет определять механизм, помечающий, что этот класс следует открывать через COM. Чтобы создать метаданные, описывающие этот класс, компилятор или интерпретатор языка помимо обычной двоичной формы кода класса использует сервисы времени выполнения компилятора COM+. Сервисы компилятора также используются для импорта метаданных, описывающих другие классы, интерфейсы или библиотеки, к которым обращается исходный код. Вызовы других служб времени выполнения будут вставлены компилятором или интерпретатором в двоичный код класса на основе зарезервированных слов (keywords) и атрибутов, заданных в исходном коде. Из двоичного кода класса и метаданных компоновщик генерирует пакеты классов, пригодные для многократного использования, которые обычно представляют собой DLL в формате Windows PE.

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

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

Во время выполнения приложения для загрузки классов и создания объектов используются интерфейсы времени выполнения (см. рис. 5). При создании клиентского приложения в приложении автоматически встраивается код запуска для инициализации этого сервиса. Функции инициализации вызывают загрузчик сервиса периода выполнения для загрузки классов, определенных в приложении, и классов, на которые имеются ссылки. Загрузчик строит глобальную таблицу классов (global class table, GCT) и создает для каждого класса представление в памяти. Представление в памяти интересно тем, как COM+ в реализации по умолчанию вызываются стандартные COM-интерфейсы. Когда клиент хочет создать новый объект, посылается запрос сервису периода выполнения COM+. Этот сервис обращается к GCT, чтобы найти представление в памяти нужного класса и вычисляет, сколько памяти должно быть выделено для этого объекта. Затем, прежде чем передать обратно клиенту ссылку на объект, сервис выделяет память и инициализирует объект так, чтобы он выглядел как объект COM.

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

Основные преимущества архитектуры COM+


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

Возможность поддержки нескольких представлений на диске очень важна. Сегодня компоненты упаковываются в виде DLL или EXE-файлов, или в виде .class-файлов в Java. В будущем, вероятно, будет введены дополнительные механизмы упаковки компонентов. Не будем вдаваться в детали хранения компонентов на диске, скажем только, что сервис времени выполнения COM+ может поддерживать взаимодействие между различными типами компонентов. Также важна и гибкость представления в памяти. COM определяет двоичное представление в памяти (называемое vtable layout). Компиляторы и инструменты должны заносить объекты в память в этом формате. Это требование может стать узким местом, если со временем понадобится изменить представление об объектах.

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

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

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

Эволюция, а не революция


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

COM+ построена на основе COM и развивает ее. Существующие компоненты COM, включая управляющие элементы ActiveX(tm), можно использовать наряду с компонентами, используемыми сервисами COM+. Для того чтобы компоненты и клиенты могли при необходимости использовать сервисы COM+, потребуются минимальные изменения в классах, реализующих бизнес-логику. Так как COM+ предоставляет дополнительные сервисы инфраструктуры, можно убрать код, управляющий этой инфраструктурой, из отдельных компонентов и клиентов. COM+ не вынуждает изучать новый язык, новый набор API или новый способ написания кода. Вы можете использовать те языки, высокоуровневые RAD-средства, API и структуры, к которым вы привыкли. Одно из основных новшеств COM+ - предоставление понятного отображения специфичных для языка объектных моделей на системную объектную модель через компиляторы и объектные сервисы времени выполнения. COM+ вобрала в себя опыт, полученный при адаптации COM и других компонентных технологий. Это эволюционный шаг к более простой, более продуктивной разработке компонентных приложений следующего поколения. В следующей статье будет рассмотрена модель программирования COM+, показано на основе чего она построена, объяснено как она усовершенствует модель программирования COM и как она соотносится с моделями программирования, специфичными для конкретного языка.

Чтобы получить полные листинги кода-источника, посетите Web-узел MSJ по адресу http://www.microsoft.com/train_cert/mcp/certstep/mcse.htm.

MICROSOFT DEVELOPER NETWORK ONLINE


Чтобы получить дополнительную информацию по данной теме смотрите The Component Object Model: A Technical Overview, http//premium.microsoft.com/msdn/library/techart/F365/F36C/F380/D390/S8B5B.HTM. Также смотрите ежедневные обновления по программам, ресурсам и событиям для разработчиков по http//premium.microsoft.com/msdn

Рисунки:

Сервисы компонентов			Распределенные сервисы
COM+ (1998)
Более развитые сервисы времени выполнения и сервисы для всех языков

Java VM (1997)				IIS 4.0/MTS 2.0 (1997)
«Прозрачная» COM для Java		Транзакционная Web, возможность взаимодействия

ATL (1996)				MTS (1996)
«Прозрачная» COM для C++		Транзакции, слежение

Visual Basic 4.0 (1995)			DCOM (1996)
«Прозрачная» COM для Visual Basic	Удаленный доступ, защита

	COM (1992)

Рис. 1. Эволюция COM

С COM

Фабрика классов
Реестр DLL
Подсчет ссылок
Query Interface
IDispatch
Точки соединения
Информация о типе
Методы

С COM+

Фабрика классов
Реестр DLL
Подсчет ссылок
Query Interface
IDispatch
Точки соединения
Метаданные
Методы

Красный шрифт - пишите вы	Синий - система обеспечивает реализации. по умолчанию

Рис. 2. Создание компонентов

     Клиенты                           Компоненты
                Связки языка/объектные библиотеки
Перехватчик 1	Перехватчик 2
(сторонний)     (сторонний)

{вертикальная колонка:}
Системный перехватчик
Связывание данных
Транзакции

{горизонтальные столбцы:}
Сервис периода выполнения COM+
Загрузчик классов
Объектная среда выполнения
Служба регистрации
API компилятора


COM
Операционная система
{бледно-зеленое} Сервисы COM+	{темно-зеленое} сервисы времени выполнения COM+

Рис. 3. Архитектура COM+

Исходный текст		Компилятор (C++, Visual Basic и т.д.)
CO Class Foo {
.
.
.
}
		Интерфейсы компилятора	Метаданные класса Foo	Двоичный класс Foo
									Компоновщик
									Пакет Foo

Файл	Инструмент	сервис времени выполнения COM+

Рис. 4. Создание компонента

Клиент

Запуск
X=conew Foo;
Таблица классов
Метаданные

сервис времени выполнения COM+

CorInitialize
CorLoad
GCT	Класс
CoNew
Объект
Переходник
  1. Код запуска инициализирует сервис периода выполнения
  2. Загрузка классов
  3. Загрузчик использует клиентскую таблицу классов для загрузки определений классов
  4. Строится глобальная таблица классов (GCT) для описания классов
  5. Клиенты запрашивают сервисы периода выполнения для создания объекта
  6. Сервис периода выполнения ищет в GCT описание класса
  7. Сервис периода выполнения устанавливает местонахождение объекта и инициализирует его
  8. Обратно клиенту передается ссылка на объект
      Рис. 5. Загрузка классов и создание объектов


Реклама на InfoCity

Яндекс цитирования



Финансы: форекс для тебя








1999-2009 © InfoCity.kiev.ua