Реферат: Разработка приложений в рамках COM/DCOM технологии - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

Разработка приложений в рамках COM/DCOM технологии

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Архив Zip, 71 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

14 1. Введение 3 2. Обзор COM-технологии 3 2.1. Состав COM-объекта 4 2.2. Интерфейсы 4 2.3. Свойства COM-объектов 6 2.4. COM-серверы 7 2.5. Механизм маршаллинга 7 2.6. Фабрики классов 8 2.7. Библиотеки типов 9 2.8. Диспетчерский интерфейс 10 2.9. Привязка идентификаторов 11 2.10. Пользовательские интерфейсы 11 2.11. Двойные интерфейсы 12 3. Расширения COM 12 3.1. OLE / Active document 13 3.2. Automation 13 3.3. ActiveX control 14 3.4. Межпроцессные визуальные объекты 14 3.5. OPC 14 4. Средства разработки COM-приложений 15 1. Введение В данной работе кратко рассмотрена технология COM, которая в настоящее время широко применя ется при разработке программного обеспечения , инт еграции программных продуктов в единые информационные системы . Целью ра зработки COM-технологии являлось стремление к интеграции программного обеспечения через стандартизацию механизмов взаимодействия программ ных модулей между собой . На основе д анной техно л огии , которая являет ся масштабируемой , разработано огромное число технологий , которые стали стандартами в разнообразных сферах применения информацион ных технологий – от управления технолог ическими процессами в промышленности до домашних персональных компь ю теров . Массовое применение COM отчасти связано с мощью ее разработчика , фирмы Microsoft. С этим приходится считаться , и каждый программ ный продукт , выпущенный под платформу Windows, для достижения коммерческого успеха обязан соответствовать инновациям Mi c rosoft. 2. Обзор COM-технологии Технология COM (Component Object Technology) – о бъектно-ориентированная программная спецификация , п редложенная Microsoft. COM предназначена для повышения надежности взаимодействия программных пр одуктов между собой . Данная технология н е определяет структуру программного продукта , язык программирования и прочие детали реализации . COM является стандартом , который регламентирует модель программного объекта , соответствующий требованиям COM-технологии. Программный объект , созданный согласно специф икации COM называется COM-объектом. Данная технология определяет механизм взаимодействия COM-объектов между собо й . COM относится к так называемым двоичным стандартам , т.к . прилагается к оттранслир ованному в дво ичный код программному объекту . Взаимодействие COM-объектов обеспечива ется набором предопределенных подпрограмм , на зываемыми интерфейсами , доступ к которым обеспечивается через уникальные идентификаторы интерфейсов GUID (Global Unique Interface Identifyer ), уникальность которых гарантирует операционная система . Такой механизм сх ож с использованием указателей при досту пе к объектам в объектно-ориентированных языках программирования , что дает возможность прозрачного управления объектами , т.к . до ступ к ним о б еспечивается ч ерез указатели . COM-технология расширяет этот механизм , перенося применение указателей (в виде GUID) для доступа к объектам на уровень операционной системы . Таким образо м , COM-объекты могут быть прозрачно друг для друга модифицироваться , т.к. досту п к объектам обеспечивается через GUID. COM тех нология включает в себя также библиотеку , в которой содержится набор стандартных интерфейсов , которые определяют ядро фу нкциональности COM и небольшой набор API функций , разработанных для создания COM-о б ъектов и управления ими. Архитектура COM является расширяемой , и на ней базир уются другие технологии Microsoft, такие как OLE и ActiveX . Эти технологии в настоящее время являются расширениями опе рационной системы , и определяют свои соб ственные правила рабо ты и предлагают свои библиотеки для создания объектов и для управления объектами на осно ве данных технологий . Используя COM как осн ову , разработчики программного обеспечения по лучают возможность создавать свои собственны е расширения таким образом , что про г раммные объекты созданные , по правилам COM-технологии могут работать с другими COM-объектами через унифицированный механизм взаимодействия , который предлагает COM. COM использует такое понятие как «кл асс» , которое по смыслу означает то же самое , что и в об ъектно-ориен тированных средствах разработки . COM-объект явля ется объектом COM-класса (COM class). COM-классы , для различия с кл ассами в объектно-ориентированных языках , с помощью которых может создаваться приложе ние , обычно называются соклассами (CoClass). Далее в тексте будет использоваться терм инология , исходящая из объектно-ориентированного программирования. 2.1. Состав COM-объекта В COM-технологии различаются следующие строительные блоки , используемые для создания объектов : · Interface (COM-интерфейс ) - множество прототипов функ ций (методов ), чисто определенных . Термин «чисто определенный метод» или «абстрактный м етод» исходит теории объектно-о риентированного анализа , и означает , что в определении класса отсутствует реализа ция метода , а присутствует только его определение . От такого класса нел ьзя создавать объекты . Его предназначение – описать фундаментальные общности для всех производных классов ; · COM object (COM-объект ) – объект класса CoClass, котор ый содержит реализаци ю COM интерфейса ; · COM/ActiveX server (COM сервер или ActiveX сервер ) – модуль , такой как EXE, DLL или OCX, который содержит ма шинный код COM или ActiveX объектов ; · Class factory (фабрика классов ) – объект , которы й может создавать COM-объекты из CoClass ; · Type library (библиотека типов ) – файл , содержа щий информацию о типах данных , которые использует COM/ActiveX сервер. 2.2. Интерфейсы Интерфейсы явля ются основными строительными единицами COM. Они объединяются на семантич ески связан ные группы подпрограмм , через которые COM-о бъекты осуществляют взаимодействие : COM определяет следующие ключевые аспекты , связанные с COM-интерфейсами : · Методы интерфейса абстрактны (чисто опре делены ). Инт ерфейс представляет собой набор прототипов методов , чье назначение состоит только в определении интерфейса . Определения прот отипов методов включает в себя определен ия числа и типов передаваемых значений , возвращаемого значения , а также ожидаем о го поведения объекта . Как методы реализованы , в определение интерфейса не включается . Таким образом , реализуется п олиморфизм интерфейса , т.к . каждый потомок , наследующий интерфейс , может включать собс твенную реализацию метода ; · Интерфейс подчиняе тся двои чному стандарту . Так как все методы интерфейса а бстрактны , интерфейс представлен как указател ь на vtable (virtual table) . Каждая запись в vtable представляет собой сс ылку на соответствующий метод класса , ко торый содержит реализацию интерфейса . Определ ение интерфейса как указателя устанавл ивает протокол для доступа к COM-объекту , который является двоичным . Таким образом , получение доступа к реализации метода интерфейса объекта представляет собой ч ерез последовательную процедуру получения ук азателей : С GUID систем а связывает указатель на интерфейс . Указ атель на интерфейс , в свою очередь я вляется указателем на vtable, через которую об еспечивается указатель на таблицу указателей на код с реализациями методов. Множество объектов одного класса в си стеме используют одну общую vtable, и для каждого такого объекта создается структур а с частными данными , необходимыми для корректного вызова функций. · Интерфейс включает в себя определенную функциональность . Методы и нтерфейса семантиче ски связаны по функциональности и назнач ению . Согласно этому , методы интерфейса о бычно именуется согласно своему назначению , и имя предваряется заглавной I. Для при мера , метод IMalloc предназначен для размещения и освобождения памяти ; · Интерфейс имеет уникальный идентификатор . Интерфе йсы различаются посредством использования гл обальных идентификаторов GUID, которые используются для ссылки на идентификаторы конкретных интерфейсов IID (Interface Identifier). Каждый интерфейс имеет свой IID, и при рег истрации в системе получает связанный с ним GUID. Использование GUID более совершенно , ч ем использование символьных имен , т.к . гар антирует отсутствие конфликтов имен при обновлении программных продуктов (выхода новы х версий ) и при использова н и и программного обеспечения от различных производителей ; · Интерфейс не может измениться после регистрации в сис теме. Каждый интерфейс предназн ачен для выполнения определенной задачи , и определяет , какие данные поступают на обработку и какие данные выводя тся . Таким образом , после того , к ак интерфейс опубликован в системе , и стал доступен для использования , он н е должен меняться . Любое изменение в семантике интерфейса ведет к необходимост и оявления нового интерфейса . Однако сущ ествует возможность безопасно й реа лизации многоинтерфейсных объектов посредством использования для доступа к разным ве рсиям интерфейса разные IID. · Интерфейсы наследу ют функциональность от одного базового п редка . Все интерфейсы прямо или косвенно являются потомками интерфе йса IUnk nown. Этот интерфейс обеспечивает базовую функцион альность интерфейса , которая включает в себя динамический опрос объекта (dynamic quering) и управление жизн енным циклом объекта (lifetime managment) . Эта функциональность обеспечивает ся тремя методами интер фейса IUnknown: QueryInterface , AddRef и Release . Каждый класс , который реал изует интерфейс , должен реализовать эти три метода , наряду с методами , унаследова нные от другого интерфейса , и своими собственными методами . Ниже представлено к раткое описание функ ционального назначен ия упомянутых методов : - QueryInetrface обеспечивает опрос объекта и доступ к указателю на интерфейс . QueryInerface является пер вой записью в vtable, и предлагает эффективный путь для определения возможностей объек та , в простейшем слу чае через эт от метод при установлении связи обеспечи вается передача указателя на интерфейс IUnknown тому объекту , который пытается получить доступ к данному объекту . Данный мето д также делает возможным обновление COM объ екта без потерь на обновление остал ь ных зависимых объектов , т.к . объект может быть динамически опрошен к лиентами через указатель на IUnknown. Это функц ия носит название dynamic quering; - AddRef и Release находятся на втором и третьем местах в vtable. Э то простые счетные функции , которые пр едоставляются для управления временем жизни объекта . Пока внутренний счетчик объекта , отражающий количества раз вызова AddRef и Release больше нуля (вызов AddRef может ув еличивать его значение ), объект остается в памяти . Как только значение счетчика дости г ает нуля (вызов Release может уменьшать его значение ), реализация инте рфейса может безопасно удалить все завис имые нижележащие объекты . Это функция но сит название lifetime managment; 2.3. Свойства COM-объектов COM-объект – это объект CoClass, который является классом , реализующим один или более и нтерфейсов . COM-объект предоставляет функции , кот орые доступны через указатель на один из его интерфейсов . Всвязи с этим , COM-объект обладает следующими особенностями : · COM-объект защи щен от прямого изменения внеш ними программами в своих данных , т.к . доступ к COM-объекту возможен только через указатель на интерфейс ; · COM-объект может быть использован приложениями , реали зованными практически на любых современных средствах разработки пр иложений (алгор итмических языках ), с любой внутренней ор ганизацией приложения , главное , чтобы средство разработки позволяло работать с указате лями на структуры , на массивы и на функции. 2.4. COM-серверы Объект COM-класса дол жен иметь в своем составе фабрику классов , и идентификатор класса CLSID (Class Identifier), так чтобы COM-объ ект мог быть создан на основе сущес твующего модуля . COM-сервер – это приложение , или библиотека , предоставляющее определенный набор сервисных фу нкций для клиентских приложений или библиотек. COM-сервер состоит из COM-объектов . На пример , COM-сервер , который включает в себя код элементов управления ActiveX (ActiveX control) – явля ется ActiveX-сервером . Для разработчика имеется большое число библиоте к , которые можно использовать для создания COM-объектов . В качестве примера можно привести би блиотеку Microsoft Active Template Library, предоставляющую набор шаблонов , на основе которых можно создавать свои собственные программные продукты , постро енные п о COM-технологии . Например , шаблон для COM-сервера включает в себя код для основных функций , которые дол жен обеспечивать COM-сервер : регистрация сервера в системе , загрузка /выгрузка сервера , создание объектов , управления фабриками кл ассов , обеспечение выда ч и информ ации о сервере , включая : тип сервера , help-файл , имя сервера , библиотека типов и т.д. Клиенты не должны знать , каким образом сервер выполняет свои функции , и клиенты не должны знать , где сервер находится – все взаимодействие осуществляется че рез указатели на интерфейс сервера . COM-сервер может быть следующих типов : · In-process server (внутренний сервер ) – программный DLL модуль , работающий в рабочем пространс тве памяти клиентского приложения : · Local server (локальный сервер ) – программный EXE модуль , работающий в отдельном адресно м пространстве ; · Remote server (удаленный сервер ) – программный EXE модуль , работающий на удаленной машине : 2.5. Механизм маршаллинга Разница между внутренним и удаленн ым серверами в том , какой тип межпро цессной связи используется . В данном слу чае существует необходимость использования п осредников , которые обеспечивают передачу пар аметров и вызов функций . Такой механизм н азывается маршаллингом (marshalling). Т.к . в случае , когда клиент и сервер находятся в разных адресных пространствах , доступ к ресурсам не может быть осуществлен непосредствен но через указатели . Поэтому посредники с о стороны клиента (proxy) осуществляют у п аковку аргументов в пакеты маршаллинга (marshalling packets), и обеспечивают удаленный вызов процеду р (Remote Procedure Call). Посредник со стороны сервера (stub) р еализуют распаковку параметров , и помещение их в стек . Далее осуществляется выз ов непосре д ственно реализации ме тода . По сути , сервер создает клиентский вызов процедуры в своем собственном адресном пространстве. Посредники используют COM-средства , для осуществления взаимодействия в разных процессах . Для взаимодействия объектов , нах одящихся на разных машинах , используются средства расширения COM – распределенная COM (Distributed COM или DCOM). COM предлагает стандартный механизм маршал линга – интерфейс диспетчеризации (Dispatch Inte r face). 2.6. Фабрики классов Фабрики или производители классов (class factories) - специальный тип COM-объектов , используемый для создания и регистрации COM-объектов . Пр оизводители классов реализуют стандартный ме ханизм создани я объектов COM-классов . К лассы без идентификаторов класса (CLSID) и фаб рики классов могут быть созданы посредст вом вызова конструктора . Использование фабрик и классов для создания объектов означает , что для клиентского приложения , котором у необходимо созда т ь объект класса , не нужно знать об этом кл ассе ничего , кроме его идентификатора CLSID. Ф абрика классов возьмет вызов конструктора на себя , включая передачу аргументов в конструктор и остальные специфичные де йствия . Класс фабрики классов может быть объедин е н со многими COM-клас сами , для каждого из которых могут создаваться объекты . При создании же объ екта фабрики классов , в конструктор пере дается идентификатор CLSID класса , для создания объектов которого предназначается фабрика . Этот идентификатор определ я ет , о бъекты какого класса могут быть созданы с помощью данной фабрики классов . Т аким образом , каждый экземпляр фабрики к лассов в системе может быть использован для создания объектов только одного определенного класса. Создание объекта класса производится посредством следующих действий : · вызова г лобальной API-функции CoGetClass, которая ищет в си стемном реестре зарегистрированный класс с данным CLSID, определяет путь к серверу , загружает сервер и выдает указатель на интерфейс производителя классов (обы чно IClassFactory); · Указатель на IС lassFactory может быть использован для вызова методов производителя классов , напр имер : CoCreateInstance (создание объекта ); Альтернативо й рассмотренному методу может служить вы зов глобальной API-функции CoCreateInst ance, которая выполняет перечисленный выше действия и создает объект класса с идентификатором CLSID, но таким образом можно создать толь ко один объект данного класса , т.к . ф ункция не возвращает указатель на интерф ейс производителя классов. 2.7. Библиотеки типов Библиотека типов (type library) предоставляет инф ормацию об используемых типах объектов и интерфейсах , которые предоставляются ActiveX-серев ером . Библиотека типов по смыслу аналоги чна , например , заголовочному файлу (head er) для разработок на языке C и любому д ругому модулю , содержащему информацию об используемых типах данных и объектах . Бо льшинство информации подобного рода может быть записано в библиотеку типов . Пол учить информацию из библиотеки типов мож но путем опроса запущенного объе кта или же посредством загрузки непосре дственно библиотеки типов . После создания библиотеки типов , к ней обеспечивается доступ через специальный тип интерфейсов : ITypeLib, ITypeInfo и ITypeComp. Интерфейс ITypeLib обеспечивает доступ к ин ф ормации о типах в библиотеке типов , а также к описан иям конкретных объектов , которые , в свою очередь , могут быть получены через интерфейс ITypeInfo. Библиотека типов содержит информацию о том , какой интерфейс , в каком COM-объекте содержится , количество и ти п методов интерфейсов и их параметров . Эти описания включают в себя уникаль ные идентификаторы классов (CLSID) и их интерф ейсов (IID), через которые осуществляется корректн ый доступ к объектам . В библиотеке т ипов также может содержаться следующая и нфор м ация : · Описания пользовательских типов данных , связанных с пользовательскими интерфейсами ; · Функции , которые экспортируются ActiveX-сервером , но которые не являются интерфейсными методами ; · Информация об энумерованных типах данных (символьных конста нтах ); · Ссылки н а описания типов в других библиотеках типов. Использование библиотеки типов очень важно для о бъектов , которые предназначены для распростра нения и последующего использования многими пользователями . Также существует еще ряд причин использ ования библиотек типо в : · Объекты , которые используют непосредственную привязку к vtable, должны быть описаны в библиотеке типов , т.к . ссылки в vtable формируются во время компиляции ; · Объекты , созданные из классов , которые поддерживают интерфейс IProvideClassInfo, должны иметь библиотеку типов . Объекты , имеющие в своем состав е данные интерфейс , являются типизированными COM-объектами , т.к . предоставляют информацию об используемых типах (из библиотеки типов ); · Элементы управления ActiveX должны иметь библиотеку т ипов , которая содержится непосредственно в DLL или OCX файле , содержащем код ActiveX-сервера ; · Приложения , которые являются Automation-серверами , должны имет ь библиотеку типов , для более удобно связывания с клиентами ; · Использование библиотеки типов в любом случае облегчает работу с внешними приложениям и , которые могут узнать об используемых типах данных , и т.о . исключается исп ользование более громоздкого метода передачи параметров в системе через универсальны й механизм ; 2.8. Диспетчерский интерфейс Диспетчерский интерфейс (dispatch interface) – стандартная специальная реализация интерфейса IDispatch, которую предлагает COM. Данная реализация обеспечивает выполнение процедур позднего связывания (late bindi ng) и маршаллинга . Дис петчерский интерфейс хранит внутри себя таблицу диспетчерских идентификаторов (dispID), каждый из которых является уникальным идентифика тором члена интерфейса , и таблица , по сути , реализует отображение соответствующего dispID на имя каждого члена интерфе йса . Клиент , желающий получить доступ к ресурсу сервера (к методу или к свойству ), должен знать dispID для соответствующ его ресурса . Такую информацию можно полу чить через вызов метода интерфейса IDispatch, ко торый называется GetIDsOf N ames, и который является первой записью в vtable для ин терфейса IDispatch. Таким образом , клиент получает информацию типах данных , используемых серв ером , и получает таблицу диспетчерских и дентификаторов , с отображением имени каждого ресурса сервера на со о твет ствующий dispID. Данная операция и со стороны клиента , и со стороны сервера , при использовании стандартной реализации интерф ейса IDispatch реализуется автоматически . Эта процеду ра называется поздним связыва нием , т.к . осуществляется на этапе выполнения программы , а не на этапе компиляции . Имея для каждого имени ресурса сервера соответствующий dispID, клиент может осуществить обращение к нему , используя метод интерфейса dispID, который именуется Invoke. Метод Invoke имеет сигнатуру , допус кающую вызов с л ю бым количе ством параметров , чем обеспечивается его универсальность . Реализация Invoke распаковывает параме тры и осуществляет вызов соответствующего метода или свойства и осуществляет ко нтроль над выдачей исключений при выполн ении метода или свойства . Когд а выполнение метода или обработка с войства заканчивается , возвращаемые значения метода или свойства отправляются обратно клиенту . Если обращение клиента к сер веру переходит через границы процесса ил и машины , то автоматически реализуются в се действия по орг а низации маршаллинга . Такая прозрачность является осно вным достоинством использования интерфейса д испетчеризации. Основным недостатком диспетчерского инте рфейса является ограничение на типы данн ых , которые можно использовать при перед аче параметров . Это сле дует из н еобходимости упаковки и распаковки параметро в при осуществлении маршаллинга . Допускается использовать 13 стандартных типов данных . На пользовательские типы данных устанавливаю тся достаточно строгие ограничения . Если требования задачи не укладываю т ся в эти ограничения , разработчик имеет возможность реализовать маршаллиг , путем написания своего proxy/stub кода . Еще одним не достаток проявляется в том , что при компиляции программы не выполняется проверка соответствия типов вызываемых функций , т.к . св я зывание диспетчерских инт ерфейсов осуществляется на этапе выполнения программы , и таким образом , не конт ролируется вызов Invoke с неверным набором ар гументов , что вызывает ошибку выполнения. 2.9. Привяз ка идентификаторов COM пр едлагает возможность привязки диспетчерских интерфейсов на этапе компиляции . Если об ъект описан в библиотеке типов , то dispID может быть прочитан для каждого ресурс а объекта , т.к . dispID является для каждого метода или свойства фиксирован , и явл яется част ь ю описания используем ых типов данных объекта . Такая процедура называется привязкой идентификаторов (ID bindig). Мет од GetIDsOfNames вызывается компилятором во время трансляции программы , таким образом , привязка идентификаторов является формой раннего связы вания (early binding). В результате , на этапе выполн ения , при первом вызове сервера клиентом , не требуется вызов процедуры привязки интерфейсов , что ускоряет работу . Еще одним достоинством данного подхода являет ся проверка соответствия типов в обращен иях к ресурсам сервера. Основным недостатком является отсутствие возможности проверки имени ресурса , есл и он вдруг изменился . В клиентском о бъекте все вызовы будут осуществляться ч ерез однажды связанные на этапе компиляц ии интерфейсные идентификаторы. 2.10. Пользо вательские интерфейсы Vtable-интерфейс ы (vtable interfaces) или польз овательские интерфейсы - определяются пользователем , и допускают вызывать мет оды интерфейса , пользуясь ссылками из vtable, при условии , если известен поря док записи ссылок на методы , число и тип передаваемых аргументов . Первые три записи в vtable соответствуют трем методам ин терфейса IUnkown, за которыми следуют ссылки н а остальные поддерживаемые интерфейсы . Если объект не реализует диспетчерский интер фейс, то следом за IUnkown непосредственно следуют ссылки на методы пользовательских интерфейсов , то есть , становится возможн о обращение к методам и свойствам о бъектов непосредственно через ссылки из vtable. В случае если сервер имеет библ иотеку типов и реализу ет диспетчерск ий интерфейс , то клиент может получить информацию из библиотеки типов , без о существления вызова функций через привязки . Достаточно получить идентификаторы dispID диспетчер ского интерфейса , и осуществить привязку непосредственно к vtable. Так и м образ ом , можно осуществить более быстрый дост уп к ресурсам объекта , осуществляя прямо й вызов через ссылки в vtable, не использ уя диспетчерский интерфейс . Код непосредствен ной привязки к vtable может быть автоматическ и сгенерирован на этапе компиляции . Р азумеется , такой метод вызова функций гораздо быстрее , чем методы п ривязки идентификаторов (т.к . вызов осуществляе тся через Invoke, что вызывает процедуры упако вки /распаковки параметров ) и позднего св язывания (т.к . осуществляется полный цикл работы с дисп е тчерским интерфейс ом ). 2.11. Двойные интерфейс ы Несмотря н а то , что COM предоставляет возможность обр ащения к ресурсам серверов используя vtable-и нтерфейсы , что повышает скорость взаимодейств ия клиента и сервера , некоторые кли енты могут быть разработаны таким образом , что обращаются к объектам то лько через интерфейс диспетчеризации . Это могут быть , например , интерпретируемые макр оязыки , которые включают в себя средства для работы с COM-объектами , и в к оторых не реализованы воз м ожност и для привязки к vtable. Таким образом , COM п редлагает то , что называется двойственным , или двойным интерфейсом (dual interface). Двойные интер фейсы предлагают два пути для доступа к ресурсам сервера : через диспетчерский интерфейс и через vtable-инт е рфейс . Двойной интерфейс определяется как нас ледник IDispatch. Преимущества использования двойных интер фейсов : · Двойные интерфейсы предлагают возможность получения указателей на ресурсы сервера по их именам при компиляции объекта , таким образом , позволяя создавать клиентов , с привязко й к vtable на этапе компиляции ; · Двойные интерфейсы позволяют клиентам осуществить прямой д оступ к ресурсам сервера через vtable-интерфе йсы , что увеличивает скорость взаимодействия объектов ; · Двойные интерфейсы имею преим ущества проверки соответс твия типов на этапе компиляции (преимуще ства раннего связывания ); · Клиенты , не раб отающие напрямую с vtable-интерфейсами имеют возможность взаимодействовать с объектами че рез диспетчерские интерфейсы ; · Двойные интерфейсы предос тавляют возможность маршаллинга для обоих своих частей – для ди спетчерского интерфейса и vtable-интерфейса . При обращении к серверу , находящемуся в д ругом адресном пространстве осуществляется а втомаршаллинг при обращении через любую часть интерфейса. Суще ствует набор ограничений по использованию двой ных интерфейсов . Они в основном связаны с типами данных , т.к . двойной интерф ейс является наследником интерфейса IDispatch. Однако , существует путь для частичного избежан ия таких ограничений , определяя не двойн о й интерфейс , а два отдельны х , один из которых – диспетчерский , другой - пользовательский (без ограничений на тип данных ). Таким образом , можно ос уществить доступ к ресурсам сервера как через диспетчерский , так и через vtabl- интерфейс. 3. Ра сширения COM Одним из расширением технологии COM является OLE, предста вляющая собой библиотеку собственных интерфе йсов , типов данных и подпрограмм , предназ наченных для обеспечения функциональности OLE. К аждая функция именуется с префиксом I Ole. Еще одним расширением COM является н е так давно созданная технология ActiveX. Осно вные ответвления ActiveX носят названия ActiveX Documents (докуме нты ActiveX) и элементы управления ActiveX (ActiveX controls). ActiveX «моложе » OLE, и была разработан а как COM-расш ирение , оптимизированное по скорости и п о размеру . Однако , OLE с появлением ActiveX уже была неплохо развита , и сейчас различ ия между этими двумя технологиями начина ют уменьшаться , а их функциональности вс е больше перекрываться. 3.1. OLE/Active document Документы OLE (OLE/Active documents) – один из набора сервисов , кот орые предлагает технология OLE. Объекты OLE documents имеют все свойства OLE по связи и внедрению данных , визуального редактирования , поддержки drag- and-drop, активизации по месту (in-pl a ce-activation). Используя OLE document можно определить любой количество интерфе йсов , через которые обеспечивается стандартно е поведения объекта , такое как визуально е редактирования и drag-and-drop. Посредством реализа ции этих интерфейсов , объекты OLE documents мог ут быть свободно объединены в единую систему взаимодействующих объектов с разн ыми форматами данных , таких , как звуковые фрагменты , текстовые документы и растро вые изображения. Объект OLE documents может быть р еализован как внутренний и внешний COM-сервер . Т акой объект состоит из двух частей : визуальной (presentation data), предназначенной для отображения визуальной части объекта и из внут ренней части (native data), используемой для редактирова ния объекта . Объе к ты OLE documents могут быть контейнерами документов (document container) и серве рами документов (document server). Сервер документов обеспе чивает функциональность объектов OLE documents. В среде контейнера документов может быть активи зирован любой сервер д окументов. 3.2. Automation Технология автоматизации (automation) предлагает возможность програ ммного управления одного приложения другим . В данной технологии различаются две составные компоненты : · Клиентская часть , называемая контроллером автоматизации (automation controller); · Серверная часть , которая носит название объекта автоматиза ции (automation object) – объект , которым управляет кл иент. Объекты ав томатизации могут быть реализованы как в нутренние , внешние и удаленные с ерве ра . Технология автоматизации характеризуется двумя положениями : · Объекты автоматизац ии должны иметь возможность определить м ножество свойств и команд через описания типов , т.е . они должны получить инфо рмацию об интерфейсах объекта , с которым идет вз аимодействие , о методах интерфейсов и о типах аргументов . Такая информация предоставляется через библиотеки типов . Однако , использование библиотеки типов необязательно при использовании интерф ейса диспетчеризации , т.к . с помощью после днего осуществляется п ривязка инте рфейсов на этапе выполнения программы (н едостатком такого подхода является отсутстви е проверки соответствия типов на этапе компиляции ); · Объекты автоматизац ии должны предоставлять свои методы обще доступными для внешнего использования , так , чт обы ими могли пользоваться вне шние приложения . Для этого , в объектах автоматизации должен быть реализован инте рфейс диспетчеризации. Основным достои нством технологии автоматизации является воз можность создания объектов , работающих в любом процессном прост ранстве . Таким образом , вместо создания невизуального OLE-об ъекта предпочтительнее использовать Automation. Еще о дно достоинство технологии Automation заключается в механизме взаимодействия приложений , реализу емый интерфейсом диспетчеризации , который авт о м атизирует процесс маршаллинга . Однако , этот механизм ограничивает набор типов данных , которые можно использовать при автомаршаллинге. 3.3. ActiveX control Технология ActiveX расширяет COM и OLE новыми функциями , специфич ными для элементов управления ActiveX (ActiveX control). ActiveX control – визуальные объекты управления , реализуе мые как внутренние COM-сервера , и которые включаются в OLE-контейнеры , и работают в их среде . Элементы управления ActiveX не являются законченными пр и ложениям и , но представляют собой объект , который решает нек оторую частную задачу и может быть встроен в различные приложения . Основными характерными особенностями ActiveX controls является возмож ность обработки событий , привязки к исто чникам данных и подде ржка лицензиров ания. Элементы управления ActiveX особенно широко используются в разработке Web-приложений , где ActiveX controls используются как интерактивные объекты на Web-страницах . По существу , ActiveX становится стандартом , специально направленным на интерактивную часть World Wide Web, например , для просмотра в Web-браузере не гипертекстовых документов , доступ к базам данных и т.д. 3.4. Межпроцессные виз уальные объекты Объекты ав томатизации , документы OLE и элементы управлен ия ActiveX являются общими используемыми о бъектами для всех приложений . Менее обще е использование COM-объектов присутствует в межпроцессных объектах , которые визуально отображаются и используются в многопроцессны х приложениях . Эти типы объектов гораздо сл о жнее создавать , т.к . прот окол взаимодействия , применяемый в управлении визуальными объектами в мнопроцессных п риложениях стандартизован только для визуаль ных объектов , которые используют интерфейс OLE document. Следовательно , необходимо создать пользоват е л ьские интерфейсы объектов и их реализации , которые будут управлять маршаллингом интерфейсов . Также , это можно реализовать через : · Использование двойс твенного интерфейса IDispatch, который поддерживает а втомаршаллинг ; · Написание собственн ого класса , реа лизующего маршаллинг. 3.5. OPC Спецификация одной из модификаций OLE, которая называется OPC (OLE for Process Control) была разработана группой фирм , з анимающихся разработкой программного обеспечения для систем промышленной ав томатизац ии . Данная технология включает в себя набор стандартных соглашений , применяемых в системах промышленной автоматизации . В настоящее время особое развитие получило использование OPC как связующей механизм вза имодействия отдельных компонент SCADA-с и стем , а также систем различных производителей друг с другом , обеспечивая эффективную по времени и стоимости ин теграцию компонент программного обеспечения . Связь по OPC осуществляется прозрачно для р азработчика , используя все средства , которые предоставля е т COM, что позволяет не внедряясь в технику связи организо вывать взаимодействующие в единых информацио нных системах программные компоненты. 4. Средства разработки COM-приложений Основным и нструментом разработки COM-приложений , ч то закономерно , являются продукты Microsoft, относящиес я к семейству визуальных средств програм мирования Visual Studio. Все компоненты этого семейства предлагают средства работы по технологи и COM, и направлены в основном именно н а разработку продуктов в р а мках этой технологии . Основной фигурой для рассмотрения в данном разделе будет семейство средств разработки приложений фирмы Inrise Inc., относящиеся к классу RAD (Rapid Application Development) – средства быстрой разработки приложений . Это продукты Borla nd С ++ Builder и Borland Delphi, которые начиная с версии 3 поддерживают разработку COM-приложений . С ++ Builder и Delphi (далее , просто C++ Builder, т.к . оба этих про дукта предоставляют идентичные возможности , д аже более того , используют одни и т е же объ ектные библиотеки ) предлагаю т набор готовых компонент , используя кот орые как шаблоны , можно легко начать разработку приложения в рамках COM. C++ Builder предла гает набор классов с реализаций основных функций интерфейсов IDispatch, пользовательских и двойн ы х интерфейсов , работы с библиотеками типов и фабриками классов . Форма , созданная в визуальном редакторе легко портируется в COM-класс , с перен есением всех свойств и методов автоматич ески в библиотеку типов . Работа над описанием интерфейсов и объектов не т р ебует знания языка описания интерфейсов IDL (interface definition language) и языка описания объ ектов ODL (object definition language), т.к . вся работа ведется в визуальном редакторе . Код на IDL все р авно создается , но этот процесс может быть для разработ ч ика прозрач ен.
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
Под лежачий камень вода не течёт. Ну и норм. Не люблю, когда мокро.
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

Обратите внимание, реферат по программированию "Разработка приложений в рамках COM/DCOM технологии", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru