к библиотеке к оглавлению к высокоуровн. языкам - 3GL к визуальным средам - 4GL к архитектуре DB-интерфейсов

Dynamic Data Exchange (DDE) - механизм взаимодействия приложений в ОС Windows и OS/2

Dynamic Data Exchange (DDE) - механизм взаимодействия приложений в операционных системах Microsoft Windows и OS/2. Хотя этот механизм до сих пор поддерживается в последних версиях Windows, в основном он заменён на более мощные механизмы - OLE, COM и Microsoft OLE Automation. Однако, DDE по прежнему используется в некоторых местах внутри самой Windows, в частности, в механизме ассоциации расширения имени файла с приложениями. Это является следствием модели разработки, в которой Microsoft в новых версиях ОС Windows следит за обеспечением совместимости со всеми её предыдущими версиями. Возможно использование для извлечения данных из сторонних приложений.

DDE - давний и прижившийся протокол обмена данными между разными приложениями, появившийся еще на заре эры Windows. С тех пор на его базе был создан интерфейс OLE, а в 32-разрядном API Windows появились и другие методы межпрограммного взаимодействия. Но ниша, занимаемая DDE, осталась неизменной - это оперативная передача и синхронизация данных в приложениях.

Приложения, использующие DDE, разделяются на две категории - клиенты и серверы (не путать с одноименной архитектурой СУБД). Оба участника процесса осуществляют контакты (conversations) по определенным темам (topic), при этом в рамках темы производится обмен элементами данных (items). Устанавливает контакт клиент, который посылает запрос, содержащий имена контакта и темы. После установления контакта всякое изменение элемента данных на сервере передается данным клиента.

Первоначально программирование DDE было чрезвычайно сложным делом - оно требовало взаимосвязанной обработки более чем десяти сообщений Windows. В версии Windows 3.1 появилась библиотека DDEML, которая перевела управление DDE на уровень вызова процедур. Разработчики подсистемы DDE в Delphi, верные идеологии создания VCL, свели интерфейс этого протокола к четырем компонентам - двум для сервера и двум для клиента.

На уровне поддержания контакта лежат компоненты TDDEServerConv и TDDEClientConv. Первый играет пассивную роль - он только указывает имя одной из поддерживаемых сервером тем. Все операции по установлению и разрыву контакта осуществляет из приложения-клиента второй компонент.

Обмен данными по протоколу DDE состоит из трех этапов:

установка соединения
собственно обмен данными
разрыв соединения

Каких-то особенностей, характерных именно для протокола DDE, здесь, как видите, нет: можно легко провести параллели между протоколом DDE и файлами (открытие, работа, закрытие), между протоколом DDE и протоколом TCP (установка соединения, обмен данными, разрыв соединения) и т.д. В процессе установки соединения один из участников является его инициатором (в терминологии DDE - клиентом), а второй находится в постоянной готовности к установке соединения (в терминологии DDE - сервер). И сервер, и клиент - это некие приложения (упрощенно - *.exe-файлы), запущенные на одном или на разных компьютерах, хотя одно и то же приложение в принципе может являться одновременно и сервером, и клиентом протокола DDE (пример такого приложения - электронные таблицы Microsoft Excel). Со стороны клиентского приложения каких-либо предварительных действий в протоколе DDE делать не требуется, а вот серверное приложения должно сначала зарегистрироваться в Windows в качестве сервера протокола DDE. Если этого не сделать, клиент DDE не сможет подсоединиться к серверу. Сервер DDE при регистрации сообщает Windows то имя, под которым он будет "известен" на данном компьютере. В терминологии DDE это имя называется Application. Разработчики DDE-серверов обычно стараются сделать это имя совпадающим с именем самого приложения, например Application-имя упомянутых выше таблиц Microsoft Excel - "EXCEL", DDE-сервер системы Intouch имеет имя "VIEW" и т.д. В принципе, имя для своего DDE-сервера можно задавать любое, лишь бы оно вписывалось в традиционные понятия об имени (латинские буквы, цифры, знаки подчеркивания) и имело длину не более 8 символов. Именно по этому имени и будет подсоединяться к серверу клиент DDE-протокола.

Посредством одного контакта могут быть связаны и синхронизированы несколько пар элементов данных. Для их описания предназначены компоненты TDDEServerItem и TDDEClientItem. Каждый из них во время работы должен указывать на контакт, к которому он привязан. Кроме того, в составе обоих есть свойства, содержащие некий текст. При установленном контакте их содержимое синхронизируется. Помимо этого в модуле DDEMAN описан и пятый компонент, который управляет всеми связями DDE.

DDEML

Win32 API включает библиотеку DDEML

Dynamic Data Exchange Management Library - DDEML - библиотека динамической связи (DLL), которую используют приложения, выполняемые в Windows, чтобы работать с общими данными. DDEML обеспечивает прикладной программируемый интерфейс (API), который упрощает задачу использования DDE в Win32 приложениях. Вместо посылки и обработки сообщений DDE непосредственно, приложение использует DDEML функции, чтобы управлять взаимодействием DDE.

Поскольку Win32 API имеет архитектуру, построенную на обработке сообщений, то использование сообщений - наиболее подходящий метод для автоматической передачи информации между приложениями. Тем не менее, сообщения Win32 содержат только два параметра (wParam, lParam) для передачи данных. В этом Вы можете убедиться прочитав пример для среды Delphi, в котором используется функция посылки сообщения. В результате, эти параметры должны косвенно указывать на передаваемые данные. Протокол DDE определяет точно, как приложения должны использовать wParam и lParam параметры, чтобы передать данные. Протокол DDE имеет специфические правила для распределения и удаления передаваемых объектов.

к библиотеке к оглавлению к высокоуровн. языкам - 3GL к визуальным средам - 4GL к архитектуре DB-интерфейсов

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

НОВОСТИ ФОРУМА

Рыцари теории эфира