Добавлен: 28.03.2023
Просмотров: 46
Скачиваний: 2
Поскольку клиент отвечает за использование фабрики классов и за управление сервером, сервер отвечает за реализацию фабрики классов, реализацию класса объектов, производимых фабрикой, выставление фабрики классов на COM и обеспечение выгрузки сервера под правильные условия. Диаграмма, иллюстрирующая, что существует внутри серверного модуля (EXE или DLL), показана на рисунке 2-4.
Рисунок 2-4: Общая структура COM-сервера.
То, как сервер выполняет эти требования, зависит от того, реализован ли сервер в виде DLL или EXE, но не зависит от того, находится ли сервер на том же компьютере, что и клиент, или на удаленном компьютере. Таким образом, удаленные серверы такие же, как локальные серверы, но они были зарегистрированы, чтобы быть видимыми для удаленных клиентов. В главе 6 рассматриваются все необходимые подробности об этих реализациях, а также о том, как сервер публикует свое существование в COM в регистрационной базе данных.
Специальный тип сервера называется «обработчиком пользовательских объектов», который работает совместно с локальным сервером, чтобы обеспечить частичную реализацию класса объекта в процессе. (Строго говоря, «обработчик» является просто представителем удаленного объекта, который находится в клиентском процессе и который внутренне содержит удаленное соединение. Таким образом, всегда существует обработчик, когда выполняется удаленное взаимодействие, хотя очень часто обработчик является тривиальный, который просто перенаправляет все вызовы. В этом смысле «обработчик» является синонимом терминов «объект прокси» или «прокси объекта». На практике термин «обработчик» имеет тенденцию использоваться чаще, когда на самом деле тривиальный обработчик, с «прокси», обычно используемым, когда обработчик фактически тривиален.) Поскольку внутрипроцессный код обычно загружается намного быстрее, внутрипроцессные вызовы чрезвычайно быстры, и некоторые ресурсы могут совместно использоваться только в пределах одного пространства процесса Обработчики могут помочь улучшить производительность общих операций с объектами, а также качество операций, таких как печать. Обработчик объекта архитектурно похож на внутрипроцессный сервер, но имеет более специализированную семантику для его использования. Хотя клиент может контролировать загрузку обработчиков, ему не нужно выполнять какую-либо специальную работу для работы с ними. Наличие обработчика ничего не меняет для клиентов.
Глава 3. COM технология во встраиваемых системах
По большей части, компонентные технологии выросли из промышленности, а не из научных кругов, и развивались в нескольких направлениях. В области предприятия распределенная вычислительная среда (DCE) Open Group была разработана в начале 1990-х годов и обеспечивала инфраструктуру для создания распределенных приложений. Это было первое решение, которое использовало формализованный язык описания интерфейса. IDL-диалект DCE использовался для автоматической генерации прокси на стороне клиента и на стороне сервера, скрывая низкоуровневое оборудование, используемое для межпроцессного и межмашинного взаимодействия, и, таким образом, значительно упрощая реализацию распределенных вычислений (Open Software Foundation 1995; Hludzinski 1998). DCE предоставляется только для удаленных вызовов процедур без семантики объекта. Это было исправлено с помощью общей архитектуры брокера запросов объектов (OMBA CORBA), которая помогла гетерогенным объектно-ориентированным системам взаимодействовать.
Усилия Microsoft начались на настольных компьютерах и стали результатом усилий, направленных на то, чтобы повысить эффективность взаимодействия ее офисных приложений. Технология, получившая название Object Linking and Embedding (OLE), позволяла документам, созданным в одном приложении, связывать или встраивать документы, созданные в других приложениях. OLE позволила, скажем, слайду презентации содержать встроенную электронную таблицу, которую можно редактировать «на месте», дважды щелкнув по ней (не выходя из программного обеспечения для презентации). Результатом технологии компонентов стала объектная модель компонентов (COM), более поздние воплощения которой конкурировали с CORBA в корпоративном пространстве. Другие организации также разработали технологию объединения различных видов носителей в одном документе (такие документы известны как составные документы). Apple основывала свою (ныне упраздненную) конкурирующую технологию OpenDoc на Системной объектной модели International Business Machines (SOM IBM) (Alger 1994).
Снова на настольном компьютере Microsoft получила ранний успех с Visual Basic и ее поддержкой стороннего программного обеспечения, доступной как «пользовательские элементы управления». Позже Visual Basic основывал свою компонентную технологию на COM. Delphi-продукт Borland был совместим с компонентами, созданными для Visual Basic, но также имел собственные объектные и компонентные модели и полностью скомпилированный язык со строгой типизацией.
Многие из наиболее популярных современных моделей компонентов для настольных компьютеров и предприятий построены на платформах, основанных на функциональных виртуальных машинах, что значительно упрощает технологию компонентов. Java-технология Sun, а также преемник Microsoft .NET относятся к этой категории.
Компонентная объектная модель (COM) возникла в результате усилий Microsoft, направленных на совместную работу различных частей ее пакета производительности Office. Первая версия технологии связывания и вложения объектов (OLE) позволяла одному приложению, такому как Microsoft Word, встраивать содержимое другого, например Microsoft Excel, таким образом реализовывая составные документы. Во второй версии OLE добавлены такие вещи, как редактирование на месте и перетаскивание. В то время как OLE 1.0 была автономной технологией, Microsoft решила отделить объектную и компонентную модели от OLE при создании OLE 2.0, поскольку поняла, что технология, созданная для OLE, может быть полезна и в других контекстах. Тони Уильямс, один из архитекторов COM в Microsoft, говорит об этом так: «Мы решили укусить пулю и сделать гораздо более формализованную модель того, что является объектом, что значит иметь интерфейсы, что значит вести переговоры над ними - и [...] которые стали COM »(Microsoft 2006). Хотя COM и OLE были созданы одной и той же командой, Microsoft сохранила четкое различие между ними. OLE 2.0 был многоуровневым поверх COM и состоял из большого количества интерфейсов и небольшой системы времени выполнения.
С тех пор COM значительно изменился. Система времени выполнения COM поставляется со всеми современными версиями Windows, а доступ к большому количеству служб Windows осуществляется через интерфейсы COM. COM также зарекомендовал себя как средство реализации компонентных технологий для сторонних разработчиков. Богатая экосистема, которая выросла вокруг компонентов ActiveX, основанных на COM, является тому примером (Szyperski et al. 2002: 26). COM может использоваться для реализации распределенных вычислений с помощью Distributed COM (DCOM) и корпоративных сервисов (таких как перечисленные в разделе 1.7) через COM + (Bukovics 2006).
COM оказал глубокое влияние на отрасль. Хотя исходная система времени выполнения поддерживает большое количество приложений и сервисов на платформе Windows, именно идеи, лежащие в основе COM, оказали наибольшее влияние. Многие компонентные модели являются более или менее точными копиями COM. Несмотря на Windows-ориентированную природу COM 1, технология широко доступна на других платформах, и ее поставщики, кроме Microsoft, реализуют ее заново. Продукты Mozilla, такие как веб-браузер Firefox, используют COM-совместимую технологию, известную как XPCOM («XP» означает «кроссплатформенный») (Turner and Oeschger 2003). Компонентная модель UNO для включения OLE-подобных функций, таких как встраивание, активация на месте и создание сценариев с использованием языка BASIC (Sun Microsystems 2007).
Во встроенной области многие модели компонентов находятся под сильным влиянием COM. Универсальный домашний API (UHAPI) от Philips и Samsung для бытовой электроники сильно заимствует у COM с его технологией uhCOM. Операционная система Symbian для мобильных телефонов использует COM-модель под названием ECom (Symbian Foundation 2008). АББ использует COM-подобную технологию для своих программируемых контроллеров, чтобы увеличить модульность своей кодовой базы (Lüders et al. 2005).
COM - это и объектная модель, и модель компонентов - компоненты инкапсулируют инстанцируемые классы, которые реализуют интерфейсы, через которые взаимодействуют объекты. Как бинарный стандарт, он стандартизирует аспекты компонентов и объектов, которые важны для правильного функционирования COM. Он не зависит от языка реализации, используемого для написания классов, при условии соблюдения двоичного стандарта.
С помощью своего двоичного стандарта COM стандартизирует механизм доступа к объектам, предписывая конкретную схему памяти, соглашение о вызовах и систему типов. Поскольку интерфейсы являются единственным средством доступа к COM-объектам, COM считается двоичным стандартом для интерфейсов. Компоновка памяти, предписанная COM, особенно совместима с чисто виртуальными классами C ++, созданными собственным компилятором C ++ от Microsoft. В результате COM идет по пути стандартизации двоичного интерфейса приложения C ++ (ABI) на платформе Windows, что позволяет создавать код другими совместимыми компиляторами C ++, по крайней мере, в том, что касается COM2. Поставщики компиляторов для языков, отличных от C ++, должны также придерживаться стандарта, если их язык должен быть совместим с COM. Интегрированная среда разработки Embarcadero Delphi, чей язык программирования Delphi является разновидностью Object Pascal, полностью соответствует двоичному стандарту COM, создавая COM-совместимые объекты (Calvert 1999: 381). Таким образом, COM успешно создает стандарт, который позволяет разнородным объектно-ориентированным языкам взаимодействовать без потери их семантики объекта, и делает это только путем стандартизации абсолютного минимума, необходимого для обеспечения двоичной совместимости.
Схема памяти COM-интерфейсов
Двоичный стандарт COM аналогичен, но не идентичен, двоичному стандарту, разработанному в главе 4. Как и этот двоичный стандарт, COM не поддерживает наследование реализации, которое можно рассматривать как функцию (как описано в разделе 4.3.2). Клиентская переменная указывает на область памяти, первый элемент которой указывает на таблицу диспетчеризации, поля которой указывают на фактическую реализацию (Szyperski et al. 2002: 330). Рисунок 5.1 показывает это визуально. Первым аргументом функции, которая служит реализацией операции COM, должен быть указатель this, что опять же согласуется с главой 4. Это позволяет COM демонстрировать истинные характеристики объекта.
Класс COM может реализовывать любое количество интерфейсов. Все интерфейсы напрямую происходят от одного другого интерфейса, кроме IUnknown, корня иерархии наследования интерфейса (по соглашению, все имена интерфейсов во время компиляции начинаются с «I»). IUnknown для большинства намерений и целей идентичен интерфейсу Fundamental, представленному в главе 4. COM-эквивалентом операции Fundamental :: SwitchInterface () являются IUnknown :: QueryInterface (), а также Fundamental :: AddReference () и Fundamental :: RemoveReference () соответствуют IUnknown :: AddRef () и IUnknown :: Release () соответственно.
COM использует подсчет ссылок для управления памятью. Объекты не должны быть подсчитаны по всей их полноте - каждый интерфейс, реализованный объектом, может быть подсчитан по отдельности. Эта функция известна как отрывные интерфейсы и может использоваться объектом для инициализации и уничтожения ресурсов для каждого интерфейса, что позволяет экономить ресурсы (Szyperski et al. 2002: 334).
Имена времени выполнения должны быть назначены большому количеству различных объектов COM, включая классы и интерфейсы. Для этой цели COM использует универсальные уникальные идентификаторы (UUID), также называемые глобальными уникальными идентификаторами (GUID). UUID - это 128-битное число, которое имеет очень высокую вероятность быть глобально уникальным. Текстовое представление UUID может выглядеть следующим образом: «7a3fc5d3-f79a-4de5-827d-d0f5619a4c99». Реестр Windows служит хранилищем данных, которое отображает UUID в компоненты (общие библиотеки для объектов, которые выполняются в процессе, и исполняемые файлы для объектов, которые выполняются вне процесса). (Последние версии Windows поддерживают внутрипроцессные COM-компоненты, которые не доступны глобально, и, следовательно, их не нужно хранить в реестре (Templin 2005).)
Ожидается, что операции в интерфейсах COM предоставят информацию об ошибке в виде целочисленных возвращаемых значений, известных как HRESULT. Истинные возвращаемые значения предоставляются в качестве выходных аргументов. Значение HRESULT - это 32-разрядное целочисленное значение, разделенное на несколько полей.
В той мере, в которой COM поддерживает управление версиями, он делает это путем избегания. Интерфейсный UUID идентифицирует не только интерфейс, но и его версию, таким образом, требуя, чтобы интерфейсы после публикации никогда не менялись. Класс может легко поддерживать несколько версий интерфейса, реализуя все интерфейсы, соответствующие различным версиям. Более новые клиенты используют IUnknown :: QueryInterface () для запроса более новой версии, в то время как более старые клиенты запрашивают более старую версию.