Структура современных систем управления, технология орс и сом объектов. Понятие баз данных

Стандарт OPC — путь к интеграции разнородных систем

OPC — это аббревиатура от OLE for Process Control, или OLE для управления процессами. Ключевыми словами для понимания изложения являются технология Microsoft OLE и интеграция. Точнее, "спрятанное" под термином OLE понятие COM.

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

1) Автоматизация. Это, конечно, собственно автоматизация (например, производства). Но это также и OLE-автоматизация (даже без приставки OLE). И еще это интерфейс автоматизации, который объясняется далее.

2) Интерфейс. Это, разумеется, интерфейс в общепринятых смыслах (их несколько). Но это также интерфейсы объектов COM и еще интерфейсы серверов (например, интерфейс автоматизации).

Интеграция

Что же мы понимаем под интеграцией? Предположим, в результате огромных усилий программистов создана сложная комплексная система, охватывающая автоматизацию на всех уровнях предприятия, начиная от самого нижнего — управления датчиками и исполнительными механизмами — и заканчивая уровнем управления предприятием, вплоть до представления обобщенных данных завода у директора. Реализована ли в данном случае концепция интеграции? В общем случае нет. Здесь интеграция подразумевает не единую глобальную систему как таковую, а прежде всего взаимодействие всех уровней ПО между собой (разумеется, это не исключает объединение их в цельную систему). Фактически, речь идет о том, что различные программные системы, созданные с помощью различных средств, установленных на различных платформах, работающих на разных компьютерах, умеют "договариваться". То есть они знают, как запросить друг у друга данные и как послать друг другу "указания". По большому счету, интеграция сводится к конфигурированию "высоких договаривающихся сторон".

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

Экскурс в COM / DCOM

Не осталась в стороне от этого процесса и компания Microsoft. Мы не будем здесь касаться борьбы Microsoft за Internet. О ее результатах хорошо известно. Но у Microsoft есть еще одна глобальная интеграционная тенденция, и о ней необходимо сказать несколько слов.

Итак, COM — Component Object Model (модель составных объектов) — и ее сетевое расширение DCOM — Distributed COM (распределенная COM) — это технология, введенная первоначально Microsoft для интеграции различных офисных приложений в Windows. Интеграция подразумевала использование объектов одного приложения, например, таблицы Excel, в другом приложении, например, в редакторе Word. Все это известно под аббревиатурой OLE. Начиная с версии OLE 2.0 в ее основу была положена модель COM.

Первоначально название COM не "выставлялось на показ", было скрыто от широких масс. Но постепенно COM пронизала все варианты Windows 9.x/NT/CE. Достаточно упомянуть такие ее производные, как ActiveX (OLE-

Историческая справка

Сравнительно недавно, в 1 994 г., под эгидой Microsoft была создана организация OPC Foundation (http://www.opcfoundation.org). Как определяет сама OPC Foundation, ее цель — разработка и поддержка открытых промышленных стандартов, регламентирующих методы обмена данными в режиме реального времени между клиентами на базе ПК и ОС Microsoft. Сейчас организация насчитывает более 270 членов, включая почти всех ведущих поставщиков контрольно-измерительного и управляющего оборудования для АСУ ТП. Достаточно назвать такие фирмы, как Siemens, Schneider Automation, Rockwell Software, Wonderware, Intellution, Ci Technologies.

автоматизация) или OLE DB, не говоря уже о самой офисной OLE. Эта технология все больше и больше увлекала Microsoft. И вот в Windows 2000 к COM добавляются некоторые компоненты (транзакции, безопасность, очереди и др.), она преобразовывается в COM+ и объявляется главной, "склеивающей" технологией программирования в архитектуре DNA (Distributed interNet Application — распределенные приложения Internet), а связанные с этим технологии объединяются под общим названием Component Services (сервисы компонентов).

Обо всем этом сейчас уже написано достаточно много. Нам же в первую очередь нужно понять основные положения, связанные с нынешним состоянием технологии COM.

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

Объекты COM передают свою функциональность через интерфейсы. Интерфейс в COM (не путать с тем, что обычно понимается под словом интерфейс) объединяет группу взаимосвязанных функций, предоставляемых объектом. Главная особенность интерфейсов COM заключается в их "публичности". Интерфейсы используются после того, как они "опубликованы", и после этого их нельзя изменять никогда (имеются в виду прототипы и набор функций интерфейса, но не их реализация, которая вполне может изменяться). Если необходима новая версия интерфейса, издается новый интерфейс при сохранении старого. Этим обеспечивается совместимость при обновлении и модернизации объектов. И это первый шаг на пути к интеграции.

Именно интерфейс, вернее, указатель на него является тем, с чем работает вызывающий процесс (читай программист). Объект может предоставлять несколько интерфейсов. Чтобы получить указатель на любой интерфейс, нужно воспользоваться функцией QueryInterface обязательного для всех COM-объектов интерфейса lUnknown. Указатель на этот интерфейс передается инициирующему процессу при создании объекта.

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

Чтобы создать объект, нужно знать, где он находится. В Windows для этого используется регистрация объектов в системном реестре. И не только их. В реестре регистрируются также интерфейсы и кое-что другое. При этом каждый COM-предмет регистрации имеет уникальный в полном смысле этого слова идентификатор, называемый GUID (Globally Unique Identifier — глобально уникальный идентификатор, иногда используется название UUID — Universally Unique Identifier). Присваивает идентификаторы своим COM-детищам их создатель, используя, например, программу GUIDGEN.EXE. Заметим также, что многие COM-объекты могут (а ActiveX просто обязаны) саморегистрироваться.

Регистрация делает доступной информацию о расположении объектов всем приложениям. И это второй шаг на пути к интеграции.

Объекты COM должны быть достаточно независимыми. Они зачастую, если не сказать в большинстве случаев, находятся вне программы COM-клиента, а могут быть запущены также и на другом компьютере. Это имеет далеко идущие последствия.

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

В COM эти и другие проблемы решаются с помощью специальных библиотек, таких, как OLE32.DLL. С одной стороны, эти библиотеки предоставляют функции для работы с объектами. Например, вызов CoCreateInstance создает объект. С другой стороны, активизируемые специальные компоненты выполняют диспетчерские функции, в частности, упаковку и передачу параметров вызываемым методам объектов (так называемый marshalling). В связи с этим упомянем два важных модуля: заместитель (proxy) и заглушка (stub). Они функционируют в адресном пространстве COM-клиента и COM-сервера соответственно и обеспечивают прозрачность вызовов. Механизм таков: COM-клиент вызывает функцию COM-интерфейса, которую ему подсовывает заместитель. Тот передает вызов заглушке через RPC. А заглушка вызывает функцию COM-сервера.

Для нас важно следующее. Первое — поддерживающие компоненты автоматизируют работу с COM-объектами и делают ее прозрачной для COM-клиента (с его точки зрения объект находится в его собственном адресном пространстве). И это третий шаг на пути к интеграции.

И второе — необходимость некоего программного обеспечения напоминает о том, что это в первую очередь технология Microsoft и добиться полной платформенной независимости не совсем просто.

Удаленные объекты

Без сетевых решений разговора об интеграции в настоящее время можно даже и не начинать. В COM по этому поводу существует DCOM — расширение COM, позволяющее добираться до объектов на других компьютерах. Важно то, что с точки зрения программирования ничего не меняется: DCOM — это системный сервис, делающий COM прозрачным в локальных сетях. И это четвертый шаг к интеграции. Но с тем же очевидным недостатком: DCOM должен присутствовать в операционной системе.

Еще одно существенное замечание. Сервис DCOM базируется на RPC. А это очеь сильно затрудняет его использование в глобальных сетях. Требуются специальные программные компоненты и изощрённое сетевое администрирование, чтобы добиться взаимодействия через DCOM в глобальных сетях. Увы! Шаг на пути к интеграции несколько меньше желаемого.

Предоставление объектов

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

1) вы разрабатываете некий COM-объект, "украшаете" его и его интерфейсы GUID, снабжаете документацией (если это объект ActiveX, то официальная документация может и не понадобиться: на программном уровне общаться с распространяемым вами через Internet объектом будете только вы сами) и передаете в виде бинарного кода;

2) вы намечаете какую-либо проблему, изучаете ее, возможно, даже собираете "тусовку" под названием Foundation или Committee и издаете стандарт, подробно описывающий объекты, призванные решать данную проблему. Реализацию вы оставляете другим. Если дело стоящее, желающие найдутся. Именно это можно сказать об OPC!

Использовать COM-объекты должны COM-клиенты. Но они могут быть разными, если мы говорим об интеграции. И они могут применять разные языки программирования, не исключая скриптовых типа Visual Basic. Технология COM предусматривает две возможности. Либо вы программируете на Си++ и тогда описываете интерфейсы с помощью предоставляемых с документацией h- и c-файлов. В этом случае говорят об интерфейсе (не путать с COM-интерфейсами!). Либо вы используете для запросов так называемую автоматизацию (OLE Automation). В этом случае для доступа к функциям объекта имеется специальный COM-интерфейс IDispatch, который COM-объект в этом случае обязан поддерживать, предоставляя интерфейс автоматизации (опять не путать с COM-интерфейсами!). При этом никакие компилируемые файлы не нужны, но нужна так называемая библиотека типов.

Программирование COM было бы нелегким занятием, если бы не предоставляемые средства. Процесс программирования упрощенно выглядит так. С помощью Cи-подобного языка MIDL (Microsoft Interface Definition Language — язык определения интерфейсов) вы описываете интерфейсы. С помощью компилятора MIDL.EXE они преобразовываются в описанные выше файлы, в том числе и в библиотеку типов. А далее используется библиотека ATL (Active Template Library - библиотека активных шаблонов), "умеющая" интерпретировать эти файлы и многое другое, связанное с COM и ActiveX.

Технология OLE

Технология OLE (Object Linking and Embedding) ― технология управления и обмена информацией между программным интерфейсом других приложений. Связывание и внедрение объектов (Object Linking and Embedding). OLE позволяет создавать объекты (рисунки, чертежи и текст) в одном приложении, а затем отображать эти объекты в других приложениях. Например, при помощи технологии OLE можно создать диаграмму в электронной таблице, а затем отобразить ее в CorelDRAW. Объекты, помещенные в приложение, использующее OLE, называются OLE-объектами. Для того, чтобы технология OLE действовала, приложение, используемое для создания OLE-объекта, и приложение, в которое помещается OLE-объект, должны поддерживать режим OLE. CorelDRAW поддерживает все функции OLE, однако некоторые приложения поддерживают лишь часть этих функций.
Приложение-сервер и приложение-клиент
При использовании OLE в обмене информацией участвуют два приложения - приложение-сервер и приложение-клиент. Приложение-сервер используется для создания и редактирования OLE-объектов (рисунков, чертежей, текстов). После того как объект создан, он помещается в приложение-клиент. Например, при создании диаграммы в электронной таблице и размещении ее в CorelDRAW при помощи OLE. В этом случае электронная таблица являются приложением-сервером, а CorelDRAW - приложением-клиентом. Некоторые приложения могут действовать и как серверные, и как клиентские, другие такой способностью не обладают. Например, CorelDRAW может быть и серверным, и клиентским приложением, в то же время, Corel PHOTO-PAINT может выступать только как приложение-сервер.
Связывание и внедрение
OLE-объекты могут связываться с приложениями клиента или внедряться в них. OLE-связанный объект подключается к отдельному файлу. Управление появлением OLE-объекта в приложении-клиенте осуществляется на основе информации, хранящейся во внешнем файле. Когда этот внешний файл изменяется в серверном приложении, OLE-объект соответствующим образом обновляется. Внедренный OLE-объект полностью содержится в файле приложения-клиента, поэтому он не связан с внешним файлом.
Буфер обмена
Буфер обмена представляет собой временную область памяти, используемую для хранения информации. Реализована возможность копирования в буфер обмена элемент или его часть из приложения-сервера, а затем размещения его в приложение-клиент. Этот элемент становится OLE-объектом. При простом копировании и вставке информации этот элемент становится OLE-внедренным объектом. При создании OLE-связанного объекта с помощью буфера обмена используется команда "Специальная вставка". При использовании буфера обмена вставляемый элемент не всегда становится OLE-объектом. Например, простой текст из текстового редактора ASCII становится при вставке просто текстом CorelDRAW. Для осуществления полного контроля над вставленными элементами следует пользоваться командой "Специальная вставка".
Буксировка
Буксировка представляет собой самый простой способ создания OLE-объекта. При помощи мыши можно выбрать элемент в приложении-сервере, разместить его в приложение-клиент, после чего он автоматически становится OLE-объектом. При обычной буксировке выделенного объекта он становится OLE-внедренным объектом. Если буксировка выделенного объекта будет осуществляться при нажатой клавише CTRL или SHIFT, он становится OLE-связанным объектом. При буксировке файлов в CorelDRAW с рабочего стола Windows 95, CorelDRAW, прежде чем создать OLE-связанный объект, попытается сначала их импортировать. Для увеличения возможностей контроля за процессом, нажмите при буксировке правую кнопку мыши для вызова контекстного меню. Это меню позволяет задать способ, с помощью которого указанные элементы будут помещены в документ.

Интерфейсы объектов

Давайте в общих чертах познакомимся с составной объектной моделью (COM — Component Object Model) и работой COM-интерфейсов.

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

COM-объектом называют фрагмент кода, реализующий один или несколько интерфейсов. COM-объекты могут быть чрезвычайно простыми (например, объекты классов C++ со статической компоновкой) или чрезвычайно сложными (программа, работающая на сервере на другом краю Земли).

Любой COM-объект в обязательном порядке должен поддерживать интерфейс с именем IUnknown, обеспечивающий два базовых свойства COM-объектов: подсчет обращений и способность запрашивать другие интерфейсы. При помощи интерфейса IUnknown можно определить, какие еще интересующие вас интерфейсы поддерживаются объектом. Поясню сказанное на примере. Предположим, мы только что создали трехмерный объект средствами механизма визуализации и теперь хотим изменить его положение в макете. Поскольку нужная функция для изменения положения присутствует в интерфейсе IDirect3DRMFrame, желательно выяснить, поддерживается ли этот интерфейс созданным объектом, и, если результат проверки окажется положительным, — вызвать соответствующую функцию IDirect3DRMFrame для изменения положения объекта. Для определения того, поддерживается ли тот или иной интерфейс данным объектом, следует вызвать функцию IUnknown:: QueryInterface:

Если вызов функции был успешным, следовательно, объект поддерживает интерфейс IDirect3DRMFrame и вы можете им пользоваться:

Интерфейс IUnknown является базовым для всех остальных COM-интерфейсов, так что при наличии указателя на любой интерфейс можно вызвать QueryInterface для любого интерфейса, которым вы хотите пользоваться.

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

Кроме того, любой интерфейс или COM-объект может наследовать функции и свойства от другого интерфейса или целой группы интерфейсов. Однако выяснить это программными средствами невозможно; приходится смотреть на определение интерфейса. Например, если заглянуть в заголовочный файл d3drmobj.h в DirectX 2 SDK, вы увидите, что интерфейс IDirect3DRMFrame является производным от IDirect3DRMVisual. Следовательно, IDirect3DRMFrame заведомо поддерживает все функции интерфейса IDirect3DRMVisual. IDirect3DRMVisual является производным от IDirect3DRMObject, который в свою очередь порожден от IUnknown. Следовательно, интерфейс IDirect3DRMFrame поддерживает все функции IDirect3DRMFrame, а также все функции интерфейсов IDirect3DRMVisual, IDirect3DRMObject и IUnknown.

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

Удаленные объекты

Стандарт Component Object Model (СОМ) с самого начала разрабатывалась с учетом поддержки распределенных систем, однако ее первоначальная реализация могла работать только на одном компьютере. Объекты СОМ могли быть реализованы в DLL или в отдельном процессе, исполняемом на той же машине, что и их клиент, но не могли располагаться на других машинах в вычислительной сети.

Эта ситуация изменилась с появлением распределенной СОМ (Distributed СОМ — DCOM). Теперь объекты СОМ могут предоставлять свои сервисы и клиентам на других машинах (Рис.3.5.).

Рис. 3.5. Распределенная СОМ.

 

Для достижения этого DCOM использует вызов удаленной процедуры (RPC). При использовании RPC клиент выполняет нечто похожее на локальный вызов компонента, но на самом деле вызов обрабатывается компонентом на другой машине сети. В DCOM также включена поддержка средств контроля доступа (контроль за тем, какими клиентами может использоваться данный объект), а также возможность указания, на какой машине должен быть создан объект. Сервисы DCOM можно использовать для создания защищенных распределенных приложений СОМ.

DCOM позволяет клиенту создавать и использовать объекты как на удаленных системах, так и на локальной. Более того, клиент может даже не осознавать различия между этими двумя случаями.

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

Объектный RPC

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

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

Вызов метода объекта, реализованного в удаленном сервере, также использует заместитель и заглушку, но в данном случае клиенту необходимо выполнить вызов удаленной процедуры (RPC) сервера.