Концепция компонентной технологии
Тенденция последних лет - повышение гибкости объектов, стандартизация интерфейсов, быстрая компоновка мелких объектов вместо интегрированных приложений. Все это нашло отражение в технологии COM (и в частности, ActiveX) и Java и соответствует парадигме будущего: сборочному программированию.
ОО-технология в основном нацелена на разработку больших программ – либо «с нуля», либо с повторным использованием классов объектов, разработанных данным производителем. Распространение библиотек классов между производителями не имеет значительных масштабов. Компонентная технология имеет целью такую сборку любых программ из готовых частей, которая исключает специфически программистсткие операции – (пере)компиляцию и (пере)компоновку. Степень готовности таких компонентов к выполнению гораздо выше, чем у библиотечных модулей или классов; они могут задействоваться через сеть или выкачиваться из Интернета для немедленного выполнения. Таким образом, появляется возможность глобального повторного использования компонентов непосредственно пользователями, а не программистами. Лидируют две такие технологии: OLE/COM/ActiveX и Java. Первая представляется более универсальной: многоязыковая и ориентированная не только на Интернет. Java имеет свои преимущества: открытость и кросс-платформенность, правда пока с трудом достигаемую.
В СОМ (Component Object Model) любая часть программного продукта реализует свои сервисы как один или несколько объектов СОМ, каждый из которых поддерживает один или несколько интерфейсов (в этом – одно из отличий от объектов С++), состоящих из методов.
Интерфейс
Интерфейс
Интерфейс
Сервер
Объект COM
Рис. 7-1 Объект СОМ
Множественность интерфейсов увеличивают гибкость объектов:
Возможность определять дифференцированный доступ для разных клиентов
Совместимость сверху вниз при расширениях: доступ к новому сервису определяется через новый интерфейс
Класс в СОМ понимается как конкретная реализация набора интерфейсов; различные реализации одного и того же набора интерфейсов означают полиморфизм. Что касается наследования, то СОМ-объекты поддерживают только наследование интерфейса, поскольку наследование реализации считается потенциально опасным способом повторного использования, нарушающим инкапсуляцию родителя. Всякий СОМ-объект - экземпляр некоторого класса; каждому классу присваивается CLSid. На компьютере должна иметься библиотека СОМ, реализующая базовые сервисы; она поддерживает Registry-таблицы CLSid в местоположении кода сервера. С точки зрения программиста, вызов метода аналогичен вызову локальной функции, но на самом деле выполняемый код может быть частью или библиотеки, или отдельного процесса, или ОС или даже располагаться на другом компьютере - доступ ко всему осуществляется единообразно (фактически по модели RPC) - см. рис. 7-2. Вопросы 7 - 9.
Интерфейсы СОМ идентифицируются именем, начинающимся с I (напр., IspellChecker) + глобально уникальным идентификатором GUID: 16 байтов, включая метку времени и сетевой адрес компьютера. Таким образом, есть возможность именовать интерфейсы во всемирном масштабе (то же и для классов СОМ). Вопрос 10.
СОМ включает в себя несколько технологий, в частности
OLE (Object Linking & Embedding) - поддержка составных документов
Вопросы 11, 12.
UDT (Uniform Data Transfer) - стандартный способ обмена данными
Структурированное хранилище - дисковый файл для хранения данных объектов, пока они не активны
Автоматизация - доступ к сервисам диалоговых программ из других программ
Управляющие элементы ActiveX - развитие OLE для локальных и глобальных сетей.
Приложение
Библиотека
Приложение
Операционная система
Операционная система
Приложение
С
ОМ делает единообразными следующие традиционные способы вызова сервисов:
Вызовы
библиотечных подпрограмм
Межпроцессная
коммункация
Системные
вызовы
Сетевые
коммуникации
Рис.7-2. Унификация способов доступа к сервисам в СОМ
Окно просмотра
Рамка IEXPLORE.EXE
Сервер документов ActiveX (напр.,
Excel)
Сервер документов ActiveX (напр.,
Word)
Сервер просмотра HTML
Объект Web browser – контейнер документов ActiveX
Рис. 7-3. MS Internet Explorer 3.0 построен из отдельных компонентов, объединенных с помощью СОМ
Управляющий элемент ActiveX - это программный компонент, выполняющий общие операции стандартным способом. Путем установления стандартных интерфейсов и правил создания контейнеров управляющих элементов (клиентских программ) спецификация управляющих элементов ActiveX представляет общую схему, каркас для построения мощных многофункциональных компонентов как в сетевом, так и в изолированном (standalone) окружении. Часто в качестве контейнера управляющих элементов используется MS Visual Basic или Internet Explorer (см. рис. 7-3).
Здесь общие функции браузера (как переход по ссылке), реализованные в процессе "Рамка", отделены от функций загрузки, отображения и редактирования информации различных типов: обычных web-страниц, документов Word, трехмерной графики и т.д. Например, web-страница может содержать таблицу Excel; тогда автоматически загружается MS Excel или (что важно!) более простое средство просмотра Excel-таблиц, оформленное как один или несколько управляющих элементов ActiveX.
Управляющих элементы реализуются как DLL и выполняются целиком внутри адресного пространства своего контейнера, что ускоряет обмен данными. Заметим, что связь клиент-сервер на рис. 8-3 двусторонняя: клиент может выставлять запросы серверу (callbacks), тогда сервер оповещает клиента о запрошенных асинхронных событиях (например, об обновлении данных), вызывая соответствующие методы контейнера. Это позволяет создавать web-страницы с активным содержимым, взаимодействующие с пользователем.
Технология ActiveX конкурирует с Java. А именно, Java Beans (кофейные зерна) функционально аналогичны управляющим элементам ActiveX. Отличия - в реализации и сегменте рынка: MS Windows VS Unix. Пока количество стандартных компонентов ActiveX на рынке превышает то же для Java Beans. Вопрос 13.