Добавлен: 04.04.2023
Просмотров: 108
Скачиваний: 2
ВВЕДЕНИЕ
COM (Component Object Model – модель многокомпонентных объектов) – одна из базовых технологий MS Windows. Основная цель технологии COM – обеспечение возможности экспорта объектов. Идея экспорта состоит в том, что один модуль создает объект, а другой его использует, обращаясь к его методам и сервисам. Естественно рационально экспортировать сложные объекты, реализующие большие и трудоемкие задачи, неизвестные вам алгоритмы и тому подобное. Это к тому, что не стоит создавать COM объект, выполняющий чтение или запись файла, т.е. простую операцию. Это нецелесообразно, и вы потратите боль времени разрабатывая и отлаживая COM-объект, чем получите удовольствия от его использования.
Один из путей решения проблемы экспорта объектов это создание объекта в DLL, а вызов методов осуществить из основного приложения. Но! Существуют некоторые операторы, которые некорректно работают в DLL, например, оператор IS всегда возвращает false, а при использовании оператора AS генерится исключение. Также необходимо точно знать какую функцию и с какими параметрами необходимо вызвать, следовательно необходимо наличие у программиста качественной документации к библиотеке. У кого-нибудь была такая? У меня была, но она разрабатывалась крупной компанией и была очень дорогой. В принципе рядовому программисту иногда не под силу качественно составить документацию, ведь наличие одной ошибки приведет к невозможности использовать его разработку, а это сложна и рутинная работа. К тому же существует проблема с освобождением памяти. Память, выделенная в одном модуле, не может быть освобождена в другом.
Можно также выделить и несколько других проблем.
- передача параметров модулю (различные представления данных в двоичном виде для различных языков программирования могут стать серьезным препятствием для использования чужих библиотек);
- поиск установленной копии приложения, реализующего требуемые сервисы, инициализация его;
- обеспечение корректной работы для нескольких клиентов.
Эти проблемы решает COM. Вызов объектов и методов решается использованием интерфейсов, передача параметров решается маршалингом, описание параметров и методов с помощью библиотек типов, автоматического запуска сервера с помощью фабрики классов и ее регистрации в реестре.
Объект исследований – технология COM.
Предмет исследований - изучение основных методов и определений технологии COM.
Цель работы – получить знания по данной теме.
Для достижения цели необходимо решить следующие задачи:
1. Исследовать предметную область.
2. На основании теоретического анализа изучения проблемы, собрать требуемые данные по указанной теме.
3. Систематизировать и обобщить существующие в специальной литературе, научные подходы к данной проблеме.
Теоретическая значимость проведенного исследования состоит в обобщении научного знания по данной проблеме.
Практическая значимость работы выражается в получении навыков и умения программирования.
Успешность выполнения задач по написанию работы в наибольшей степени зависит от выбранных методов исследования.
В работе использовались методы как эмпирического исследования: сравнительно-сопоставительный, наблюдение, так и используемые как на эмпирическом, так и на теоретическом уровне исследования: абстрагирования, анализ и синтез.
Из всего многообразия литературы считаю наиболее приемлемыми для себя и работы следующих авторов Гагарина Л. Г. , Ездаков А. Л. , Карпенков С. Х. , Колдаев В. Д. , Кудинов Ю. И. , Лазарева И. М., Малявко А. А., Орлов С. А., Тузовский А. Ф. , Федорова Г. Н. , Черпаков И. В.
Структурно курсовая работа состоит из введения, трех глав, заключения и списка литературы.
Глава 1. Предпосылки возникновения COM
Технология СОМ является одной из базовых технологий Windows и для того, чтобы понять ее назначение, необходимо рассмотреть основные предпосылки ее возникновения[1]. Если попытаться кратко сформулировать ее цель – то это способ взаимодействия клиентских приложений и серверов или предоставление сервисов одним приложением другому. Таким образом, главной предпосылкой возникновения СОМ является именно взаимодействие приложений.
Проблема взаимодействия приложений Windows имеет две стороны: взаимодействие на одном компьютере и в сети Intranet или Internet[2]. Взаимодействие приложений, размещенных на удаленных компьютерах, обеспечивается технологией DCOM (Distributed COM – распределенная модель компонентных объектов), а также и технологией COM+. COM+ является следующим эволюционным шагом в развитии технологии СОМ. Технология COM+ не только включает в себя технологии COM и DCOM, но и имеет свои специфические особенности, облегчающие программирование взаимодействующих приложений Windows в рамках одного компьютера или в сети[3].
Чтобы яснее представить себе проблему взаимодействия приложений Windows, надо вспомнить следующее. Каждый процесс в 32-разрядной Windows имеет свое адресное пространство размером в 4Гб и, по этой причине, один процесс не имеет никакой возможности (и хорошо!) получить доступ к данным или функциям другого процесса, так как любой адрес в процессе ссылается на свое адресное пространство.
В логической и хронологической последовательности взаимодействие приложений Windows реализовалось с использованием следующих технологий:
1 Dynamic Link Libraries (DLL) – динамически подключаемые библиотеки.
2 Open DataBase Connectivity (ODBC) – открытый интерфейс доступа к базам данных, встроенный в Windows и Windows NT.
3 Dynamic Data Exchange (DDE) – динамический обмен данными.
4 Object Linking and Embedding (OLE1.0) – внедрение и связывание объектов.
5 OLE2.0 – OLE на базе COM.
6 Distributed COM (DCOM) – распределенная модель компонентных объектов.
7 COM+ – новейшая технология COM.
Зачем вообще приложениям необходимо взаимодействовать друг с другом? Если некоторому приложению необходимо, допустим, использовать электронные таблицы Excel, то почему бы ему не подключить соответствующую библиотеку DLL? Естественно, можно, и это уже было первым подходом к решению данной проблемы. Однако, такой подход имеет свои недостатки, главным из которых является проблема сопровождения и модификации ПП[4]. Если разрабатывалась новая версия какой-либо функции DLL, то перестают работать приложения, которые используют старую версию библиотеки[5]. Если новую версию функции снабдить новым именем, то необходимо разрабатывать новую документацию и включать в библиотеку обе версии функции[6]. Несложно себе представить, в какой конгломерат превратится библиотека в течение весьма небольшого промежутка времени и насколько сложно будет ориентироваться в многочисленных версиях функций!
Главную идею технологии ODBC можно проиллюстрировать все на той же Excel. Так как это приложение должно быть способно считывать данные из БД различных форматов, необходимо или разрабатывать различные версии Excel для каждой из БД (Excel для Access, Excel для Oracle и т.д.) или заблаговременно подключать все необходимые библиотеки к Excel. Microsoft выбрала другой путь, создав промежуточный программный слой, который определяет стандартный интерфейс для приложений. На уровне вызовов этот интерфейс использует язык SQL, а реализация взаимодействия с БД обеспечивается драйверами, поставляемые в форме DLL[7]. Таким образом, ODBC располагается между приложением и источниками данных различных форматов.
Технологию динамического обмена данными DDE можно рассматривать как попытку стандартизации обмена данными между приложениями[8]. Вся идеология Windows основана на обработке сообщений (messages) и любые приложения могут обмениваться друг с другом сообщениями, используя общую очередь сообщений. Проблема, однако, состоит в том, что каждое из приложений должно знать протокол обмена данными, т.е. формат сообщений, и собственно сообщения Windows не позволяют передавать сравнительно большие объемы данных[9]. Технология DDE как раз и предложила такой стандартный протокол, реализованный во многих приложениях. Главными недостатками DDE является сложность программирования, ненадежность и то обстоятельство, что приложения должны знать формат передаваемых данных.
Технологию внедрения и связывания объектов OLE1.0 фирма Microsoft представила в 1991г. как попытку реализации объектно-ориентированного механизма взаимодействия приложений. Главной идеей OLE является концепция составного документа, который может содержать объекты других приложений[10].
До OLE приложения могли обмениваться статическими снимками данных через буфер обмена Windows. Однако редактирование таких данных должно выполняться тем приложением, которое их породило, а после редактирования они вновь должны быть вставлены в другой документ. Если изменяются исходные данные, то, очевидно, должны изменяться данные и в составном документе. Однако, системный буфер обмена не имеет никаких средств поддержания таких связей. Более того, проблемы возникают и при перемещении исходных данных в новое место.
Внедренный с помощью OLE1.0 объект содержит статические данные (рисунок) и данные, необходимые для его редактирования. Для редактирования объекта пользователю приложения-контейнера необходимо щелкнуть по объекту, вследствие чего в отдельном окне запускается исходное приложение, породившее эти данные[11]. По окончании редактирования пользователь может сохранить данные и эти данные будут обновлены и в приложении-контейнере.
Недостатками технологии OLE1.0 являются:
1 Так как базовым механизмом OLE1.0 является DDE, который по своей природе асинхронен, то после вызова любой функции возврат управления происходит немедленно и требуется ожидать, в цикле, завершения требуемой операции.
2 Так как для передачи данных между приложениями используется разделяемая глобальная память, то данные сначала копируются в нее, откуда они тут же могут быть вытолкнуты Windows в файл подкачки, вследствие чего замедляется работа приложения[12].
3 Связи OLE1.0 легко разрываются при перемещении файлов.
4 Пользователю неудобно редактировать данные в отдельном окне.
Глава 2. Основные понятия и определения.
COM (Component Object Model) – модель компонентных объектов Microsoft[13]. Стандартный механизм, включающий интерфейсы, с помощью которых одни объекты предоставляют свои сервисы другим. Является основой многих объектных технологий, в том числе OLE и ActiveX. Другой перевод: многокомпонентная модель объектов.
DCOM (Distributed Component Object Model) – распределенная модель компонентных объектов[14]. Расширение модели COM фирмы Microsoft, ориентированное на поддержку и интеграцию распределенных объектных приложений, функционирующих в сети.
COM представляет собой основанную на объектах клиент-серверную модель, разработанную Microsoft для обеспечения взаимодействия между компонентами программного обеспечения и приложениями. Microsoft расширила эту технологию добавлением элементов ActiveX, которые представляют результат развития технологий OLE и OCX. OCX (OLE Custom eXtension) – это программируемые компоненты-приложения с интерфейсом на базе OLE, позволяющим легко включать их в другие приложения[15]. С 1996 года они стали называться ActiveX.
Сейчас Microsoft предлагает использовать термин Active technologies вместо ActiveX, включая в новые технологии такие составляющие:
- Active Documents (активные документы)
- ActiveX (управляющие элементы)
- Active Scripting controls
· Automation (автоматизация, прежде известная как OLE Automation)
Ключевым аспектом COM является то, что эта технология обеспечивает связь между клиентами и серверами посредством интерфейсов[16]. Именно интерфейс предоставляет клиенту способ "узнать" у сервера, какие именно возможности он поддерживает на этапе выполнения. Для расширения возможностей сервера необходимо просто добавить новый интерфейс к существующим.
Delphi предоставляет программисту мастеров (wizards) и классы, которые облегчают разработку приложений, основанных на технологиях COM[17]. Мастера позволяют создавать:
- простые COM–совместимые классы для использования в одном приложении;
- полновесные серверы COM;
- серверы автоматизации (Automation servers) и контроллеры автоматизации (Automation controller);
- управляющие элементы ActiveX;
- активные формы ActiveForms.