Архитектура управления распределенными данными (DDM) открыта, опубликована IBM архитектура обеспечение для создания, управления и доступа к данным на удаленном компьютере. DDM изначально был разработан для поддержки файлов с записью ; он был расширен для поддержки иерархических каталогов, потоковых файлов, очередей и системных команд; в дальнейшей она была расширена и стала источником архитектуры распределенной реляционной базы данных IBM (DRDA); и, наконец, он был расширен для поддержки описания и преобразования данных. Определенный в период с 1980 по 1993 год, DDM определяет необходимые компоненты, сообщения и протоколы, все основанные на принципах объектной ориентации. DDM сам по себе не является частью программного обеспечения; реализация DDM принимает форму клиентских и серверных продуктов. В качестве открытой архитектуры продукты реализовывать подмножества архитектуры DDM, а продукты могут расширять DDM для удовлетворения дополнительных требований. Взятые вместе, продукты DDM реализуют распределенную файловую систему.
Архитектура DDM на носителе.Дизайн Разработчики распределенных приложений должны определить наилучшее размещение программ и данных приложения с точки зрения количества и частоты передаваемых данных, а также соображений управления данными, безопасности и своевременности. Существует три модели клиент-сервер для проектирования распределенных приложений:
Архитектура DDM оптимизирована для поддержки моделей распределенных приложений с толстым клиентом; он также передает передачу файлов целиком.
Архитектура DDM предоставляет распределенным приложениям следующие преимущества:
Архитектура DDM - это набор спецификаций сообщений и протоколов, которые позволяют управлять данными, распределенными по сети компьютерами и получать к ним доступ.
IBM Системная сетевая архитектура (SNA) изначально была предоставлена для обеспечения иерархического подключения рабочих станций к мэйнфреймам IBM. Сети связи, доступные в то время, были жестко спроектированы с точки зрения фиксированных точек соединения между мэйнфреймом и его набором станций, которые находились под полным программным управлением мэйнфрейма. Другая связь между мэйнфреймами включает в себя фиксированные соединения, используемые программным, определенным для определенных целей. По мере как сети связи становились более гибкими и динамичными, желательна общая одноранговая связь, при которой программа на одном компьютере могла запускать и взаимодействовать с программой на другом компьютере.
Когда в начале 1980-х была определена архитектура IBM SNA Расширенная программа для программных коммуникаций (APPC), стало очевидно, что APPC можно использовать для предоставления служб операционной системы на удаленных компьютерах. Рабочая группа SNA преследовала эту идею и определила несколько распределенных служб, таких как файловые службы, службы печати и службы системной консоли, но не смогла начать продукт продукта. Программное обеспечение APPC еще не было доступно для мэйнфреймов, и, в более общем плане, мэйнфреймы все еще рассматривались в основном как автономные системы. В результате работа над распределенными сервисами была приостановлена рабочей группой SNA.
Члены рабочей группы SNA из лаборатории разработки IBM в Рочестере, штат Миннесота, были заведены, что существует экономическое обоснование для распределенных сервисов среди компьютерных систем среднего уровня, производимых в Рочестере. Для подключения IBM System / 3, IBM System / 34 и IBM System была реализована примитивная форма распределенных файловых служб, называемая Distributed Data File Facility (DDFF). / 36 миникомпьютеры. Компьютеры IBM System / 36 и IBM System / 38 продавались клиентов в нескольких количествах, возникла очевидная необходимость включить, например, компьютеры в штаб-квартире компании для взаимодействия с компьютерами на различных складах. APPC был реализован в этих системах и использовался различными приложениями клиентов. Затем идея распределенных служб была возрождена как проект Golden Gate, и была сделана попытка оправдать его развитие. Эта попытка также не удалась; Специалисты по планированию продуктов IBM, чтобы иметь возможность количественно оценить программное обеспечение, соединяющего разнородные компьютеры.
Тем не менее, один из планировщиков "Золотые Ворота", Джонди, Бонди, оставившимся контроля создал отдел вне обычной лаборатории в Рочестере, чтобы не было немедленной необходимости в заранее определенном экономическом обосновании. Кроме того, он сузил свою миссию, включив поддержку распределенного управления данными (DDM), в частности поддержку файлов, ориентированных на записи. Затем он убедил опытного архитектора программного обеспечения Ричарда А. Демерса присоединиться к решению задач по определению архитектуры DDM и продаже DDM системным компаниям IBM.
Первый год этих усилий оказался в основном бесплодным, системным компаниям IBM продолжали требовать предварительных бизнес-обоснований и настаивали на форматах сообщений, изоморфных интерфейсов управления блоками управления локальных файловых систем. Персональные компьютеры начали работу в качестве терминалов, подключенных к мэйнфреймам, утверждалось, что простое расширение потока 3270 позволит ПК получить доступ к данным мэйнфреймов.
В течение этого периода Демерс разработал архитектурную модель клиентов и серверов DDM, их компонентов и взаимодействий между компьютерами, которые взаимодействуют между собой. Кроме того, он определил общий формат для сообщений DDM, основанный на принципах объектной ориентации, предложенных языком программирования Smalltalk и IBM System / 38. Эта модель прояснила, как продукты DDM могут быть реализованы в различных системах. См. Как работает DDM.
В 1982 году планировщики Система / 36 убедились, что существует достаточный рынок для файловых сервисов, ориентированных на записи DDM.
Общий формат сообщений DDM уже разработан, но какие сообщения следует определить? Файловая система определена система удовлетворения ориентированных на потребляющих языков программирования третьего поколения, таких как Fortran, COBOL, PL / I и IBM RPG, а также файловая система System / 38 и файловая система Virtual Storage Access Method (VSAM) мэйнфреймов IBM. И все же их фактические возможности и интерфейсы значительно различались, так что какие средства и интерфейсы поддерживают архитектуру DDM? См. файлы, ориентированные на записи.
Первоначальная работа над DDM в рамках проекта Golden Gate следовала примеру международного стандарта доступа и управления файлами (FTAM ) для распределенных файлов, но это было очень абстрактно и сложно сопоставить с локальными файловыми службами. Фактически, это было одним из препятствий для принятия системными фирмами IBM. Кеннет Лоуренс, системный архитектор, ответственный за файлы службы System / 36, утвержден, что могла бы легко реализовать хотя бы одна система IBM, а также другим системам запрашивать любые необходимые изменения. Естественно, он выступал за поддержку требований System / 36. После года неудач с продажей идей DDM другим системным компаниям аргументы IBM Лоуренса возобладали.
Ричард Сандерс присоединился к разработчикам команды архитектуры DDM и вместе с Лоуренсом и Демерсом работал над определением конкретных сообщений, необходимых для System / 36 DDM. Прогресс в определении DDM побудил System / 38 также принять участие. Это расширило сферу поддержки файлов записи DDM для удовлетворения требований расширенной файловой системы System / 38.
Файлы существуют в контексте, предоставляющем операционную систему, которая предоставляет услуги для организации файлов, совместного использования их с совместными пользователями и для защиты их от несанкционированного доступа. На уровне 1 DDM доступ к удаленным файловым каталогам не поддерживался, кроме передачи полного имени, который был сообщением. Однако безопасность и совместное использование были необходимы. Сандерс занимался проектированием в этих областях. Сандерс также определены электрические протоколы, используемые средства связи, которые были включены в компонент, называемый DDM Conversational Communications Manager. Первоначально реализован с использованием APPC, позже он был реализован с TCP / IP.
. После завершения разработки продукта System / 36 DDM Лоуренс работал с программистами из лаборатории IBM Hursley Park, Великобритания, чтобы адаптировать большую часть System / 36. Программирование DDM для использования сервера в среде обработки транзакций IBM Customer Information Control System (CICS), что делает CICS сервером DDM для операционных систем мэйнфреймов MVS и VSE. Лоуренс также работал с программистами из лаборатории IBM Cary, Северная Каролина, над реализацией клиента, ориентированного на записи DDM, для IBM PC DOS.
Уровень 1 архитектуры DDM был официально опубликован в 1986 году. На момент этого IBM вручил награду за выдающиеся технические достижения Лоуренсу, премию за выдающиеся вкладки Ричарду Сандерсу и премию за выдачу инноваций Ричарду Демерсу.
С ростом значения IBM PC и операционной системы Unix в сетевых средах, поддержка DDM также потребовалась для иерархических каталогов и потоковых файлов IBM Personal Computer, на запущен IBM PC DOS. и IBM RS / 6000 под управлением IBM AIX (версия Unix от IBM). См. Файлы, ориентированные на поток..
Архитектура DDM уровня 2 была опубликована в 1988 году. Ян Фишер и Сунил Гайтонде выполнили часть архитектурной работы по поддержке DDM для каталогов и потоковых файлов.
В 1986 году IBM продает четыре различных продукта реляционных базовых данных (RDB), каждый из которых создан для определенной системы операционной IBM. Ученые из исследовательской лаборатории IBM в Алмадене разработали систему / R *, прототип распределенной РБД, и они почувствовали, что пришло время превратить ее в рыночные продукты. Однако System / R * основан на System / R, исследовательском прототипе RDB, и его нелегко добавить в продукты IBM RDB. См. Обсуждение RDB в среде распределенной обработки.
Роджер Райнш из Программного обеспечения IBM в Санта-Тереза возглавил группу по разработке нескольких продуктов для определения Распределенной реляционной базы данных (DRDA). Он включил в список:
В 1990 году одновременно были опубликованы уровень архитектуры DDM 3 и DRDA. И DDM, и DRDA были обозначены как стратегические компоненты IBM Архитектура системных приложений (SAA). DRDA была реализована всеми четырьмя продуктами IBM RDB и другими поставщиками.
Награды были вручены участникам разработки DRDA. Ричард Сандерс получил награду за выдающийся вкладчик, а Роджер Райнш и Ричард Демерс получили награды за выдающиеся инновации.
Проект распределенного управления файлами (DFM) был инициирован с помощью приложения службы DDM в операционной системе IBM MVS, чтобы программы на удаленных компьютерах могли создать, управлять и получать доступ VSAM файлы. Джон Хафферд, менеджер проекта DFM, обратился к команде архитектуры DDM в поисках средств преобразования полей данных в функции при их передаче между системами. Ричард Демерс взял на себя инициативу в этом вопросе при помощи Коичи Ямагути из проекта DFM. См. Описание и преобразование данных.
Ричард Сандерс, Ян Фишер и Сунил Гайтонд определили следующие дополнительные службы в режиме DDM на уровне 4:
Уровень 4 архитектуры DDM был опубликован в 1992 году.
Архитектура работает над Уровень 5 DDM состоял из поддержки
Ян Фишер был архитектором, ответственным за DDM уровня 5, который был опубликован Open Group, а не IBM. Вскоре после этого архитектурная группа IBM DDM была расформирована.
Архитектура DDM - это формально определенный и хорошо структурированный набор спецификаций. В этом разделе представлены ключевые технические концепции, лежащие в основе DDM.
Архитектура DDM определяет протокол клиент / сервер; то есть клиент запрашивает услуги у сервера, который взаимодействует с его локальными ресурсами для выполнения запрошенной услуги, результаты которой, данные и индикаторы состояния, возвращаются клиенту. На приведенной выше диаграмме показаны роли клиентов и серверов DDM по отношению к локальным ресурсам. (Здесь используется общая терминология клиентов и серверов, но в архитектуре DDM клиент называется исходным сервером, а сервер - целевым сервером.)
Архитектура DDM объектно-ориентированная. Все сущности, DDM, являются объектами, определенными самоопределяемыми объектами Class. Сообщения, ответы и данные, передаваемые между системами, являются сериализованными объектами. Каждый объект указывает свою длину, идентифицирует свой класс с помощью кодовой точки DDM и содержит данные, как определено его классом. Кроме того, его класс определяет команды, которые могут быть отправлены его экземплярам, когда объект находится на клиенте или сервере DDM, тем самым инкапсулирующий объект с помощью ограниченного набора операций.
Структурно архитектура DDM из иерархических уровней объектов, каждый из которых проявляет новые свойства на всех более высоких уровнях.
Хотя архитектура DDM является объектно-ориентированной, продукты DDM были реализованы с использованием языков и методов, типичных для их хост-систем. Версия Smalltalk DDM была выбрана для IBM PC компанией Object Technology International, с предоставленными классами Smalltalk, созданными автоматически из Справочного руководства DDM.
DDM - это открытая архитектура. Продукты DDM могут реализовывать подмножества архитектуры DDM; они также могут создавать свои собственные расширения.
Команда DDM «Атрибуты сервера Exchange» - это первая команда, отправляемая, когда клиент соединяется с сервером. Он идентифицирует клиента и указывает менеджеров, который требует клиент, и уровень архитектуры DDM, на котором требуется поддержка. Сервер, идентифицируя себя отвечает, на каком уровне он поддерживает запрошенных менеджеров. Общее правило заключается в том, что продукт, поддерживающий уровень X менеджера DDM, должен также поддерживать уровень X-1, чтобы новые серверные продукты соединялись со старыми клиентскими продуктами.
Подмножества DDM могут быть реализованы для удовлетворения различных требований продукта:
Когда клиент DDM подключен к известному серверу DDM, например к системе / 38 к серверу System / 38, архитектура DDM также может быть расширена путем добавления
Такие расширения могут быть использованы в объектно-ориентированной структуре DDM, чтобы можно было использовать средства обработки сообщений DDM.
В чисто объектно-ориентированной реализации DDM клиенты и серверы, а также все объекты памяти в них менеджеры и объекты существуют в куче с указателями (адресами), используемыми для их соединения. Например, объект команды указывает на каждый из своих объектов параметров. Команда не может быть передана таким образом от клиента к серверу; изоморфная копия команды быть создана как одна непрерывная строка битов. В куче состоит команда из размера команды в куче, указатель на класс команды и указателей на каждый из объектов параметров команды. Линеаризованная команда состоит из общей длины линеаризованной команды, кодовой точки, идентифицирующей класс команды, и каждого из ее линеаризованных объектов параметров. Архитектура DDM определяет уникальные кодовые точки каждому классу объектов. Этот простой метод используется для всех объектов, передаваемых между клиентом и серверами, включая команды, записи и ответные сообщения.
Все эти линеаризованные объекты помещаются в конверты, которые позволяют агентам клиента и сервера координировать свою обработку. В структуре DDM эти конверты называются структурой потока данных (DSS). Команды помещаются в запрос DSS (RQSDSS), помещаются в DSS ответа (RPYDSS), а другие объекты помещаются в объект DSS (OBJDSS). В RQSDSS может быть только одна команда и только один ответ в RPYDSS, но многие объекты, такие как записи, могут быть помещены в OBJDSS. Кроме того, многие объекты связаны с RQSDSS или PRYDSS, чтобы вместить столько объектов, сколько необходимо. DSS состоит из общей длины DSS, байта флага, идентифицирующего тип DSS, поиска запросов и линеаризованных объектов в DSS. Идентификатор запроса связывает RQSDSS с последующими объектами OBJDSS от клиента, такими как записи, которые должны быть загружены в файл командой Загрузить файл. Идентификатор запроса также связывает RQSDSS от клиента с RPYDSS или OBJDSS от сервера к клиенту.
Справочное руководство DDM состоит из названных объектов Меню, Справка и Класс. Подклассы класса DDM Class описываются переменными, которые определяют
Эти объекты содержат ссылки на другие именованные объекты в тексте и спецификациях, тем самым создавая гипертекст ссылки между страницами Справочного руководства DDM. Страницы меню и справки образуют единое руководство по DDM. Бумажная версия Справочного руководства DDM уровня 3 громоздка, более 1400 страниц, и несколько неудобна в использовании. Учитывая относительно низкую скорость этих средств связи, он в основном использовался в лаборатории IBM в Рочестере.
В дополнение к Справочному руководству по DDM, документ с общей предоставленной информацией о DDM на исполнительном уровне, а Руководство программиста обобщает концепции DDM для программистов, реализующих клиентов и серверы.
Архитектура DDM определяет три общие модели файлов: файлы, ориентированные на записи, файлы, ориентированные на поток, и иерархические каталоги.
Архитектура DDM предоставляет следующие услуги для управления удаленными файлами:
Файлы, ориентированные на записи, были разработаны для удовлетворения требований ввода, вывода и хранения данных в программировании третьего поколения (3GL) языки, такие как Fortran, Cobol, PL / I и RPG. Вместо того, чтобы каждый язык предоставлял свою собственную поддержку этих возможностей, они были включены в службы, предоставляемые операционными системами.
A запись - это серия связанных полей данных, таких как имя, адрес, идентификационный номер и зарплата одного сотрудника, в которой каждое поле закодировано и сопоставлено с непрерывной строкой байтов. Ранние компьютеры имели ограниченные возможности ввода и вывода, как правило, в виде стопок по 80 перфокарт с колонками или в виде бумаги или магнитных лент. Записи приложений, такие как записи данных сотрудников, последовательно считывались или записывались по отдельности и обрабатывались партиями. Когда стали доступны устройства хранения с прямым доступом, языки программирования добавили в программы способы произвольного доступа к записям по одной за раз, такие как доступ по значениям ключевых полей или по положению записи в файле. Все записи в файле могут иметь один и тот же формат (как в файле расчета заработной платы) или разные форматы (как в журнале событий). Некоторые файлы доступны только для чтения в том смысле, что их записи после записи в файл можно только читать, в то время как другие файлы позволяют обновлять свои записи.
Модели файлов DDM, ориентированные на записи, состоят из атрибутов файла, таких как дата его создания, дата последнего обновления, размер его записей и слоты, в которых могут храниться записи. Записи могут быть фиксированной или переменной длины, в зависимости от носителя, используемого для хранения записей файла. DDM определяет четыре типа файлов, ориентированных на записи:
Архитектура DDM также определяет множество методов доступа для работы с файлами, ориентированными на запись, различными способами. Метод доступа - это пример использования файла, созданного с помощью команды OPEN, которая подключается к файлу после определения, авторизован ли клиент на его использование. Метод доступа отключается от файла с помощью команды CLOSE.
Метод доступа отслеживает текущую обрабатываемую запись с помощью курса. Используя различные команды SET, можно курсор указать на начало или конец файла, на ближайшую или предыдущую последовательную запись в соответствии с порядком своими ключами.
В файле можно одновременно открыть несколько экземпляров методов доступа, каждый из которых обслуживает одного клиента. Если файл открыт для доступа к обновлению, могут возникнуть случаи, когда к одной и той же записи обращаются несколько клиентов. Чтобы предотвратить такие конфликты, можно получить блокировку для всего файла. Кроме того, если файл открыт для обновления, блокировка обновляется первым клиентом. Все остальные клиенты должны дождаться снятия блокировки.
Потоковые файлы состоят из единственной установки байтов, на которые программы могут отображать данные приложения, как они хотят. Потоковые файлы - это основная файловая модель, поддерживаемая Unix и Unix-подобными операционными системами, а также Windows. DDM определяет модель файла с одним потоком и метод доступа к одному потоку.
Модель потока DDM из атрибутов файла, таких как дата создания и размер потока, а также непрерывный поток байтов. Доступ к потоку можно получить с помощью Stream Метод доступа. Прикладные программы записывают данные в части потока, даже если эти данные состоят из записей. Они отслеживают расположение элементов данных в потоке сообщения в сообщениях. Например, поток файлов документов программой обработки текста, такой как Microsoft Word, а поток данных таблицы таблицы электронной таблицы - такой программой, как Microsoft Excel.
Метод доступа к потоку - это пример использования файла поток одним клиентом. Курсор установленного текущего байта подпотока, используемого клиентом. Используя различные команды SET, можно курсором на начало или конец файла, на любую конкретную позицию в файле или на любом указателе или отрицательном смещении от текущей позиции.
В файле можно одновременно открыть несколько экземпляров метода доступа Stream, каждый из которых обслуживает клиента. Если файл открыт для доступа «обновления», могут быть проблемы того времени, когда к одному и же подпотоку обращаются несколько. Чтобы предотвратить такие конфликты, можно получить блокировку для всего файла. Кроме того, если файл открыт для обновления, блокировка для подпотока получается первым клиентом, чтобы «прочитать» его, и снимается, когда этот клиент «обновляет» его. Все остальные клиенты должны дождаться снятия блокировки.
Иерархические каталоги - это файлы, каждый из которых связывает с местоположением. И возникает, когда запись каталога определяет имя и расположение другого каталога. Используя клиентские и серверные продукты DDM, программа может создавать, удалять и переименовывать каталоги на удаленном компьютере. Они также могут перечислять и атрибуты файлов удаленных каталогов. Записи в каталоге можно последовательно читать с помощью метода доступа к каталогу DDM. Файлы, описанныеми каталогов, можно переименовывать, копировать и перемещать в другой каталог.
Очереди - это механизм связи, который обычно обеспечивает краткосрочное общение между программами посредством записей. Очередь DDM находится в одной системе, но к ней могут обращаться программы в нескольких системах. Существует три подкласса очередей DDM, которые реализованы в системе с помощью отдельных команд создания:
Модель очереди DDM состоит из атрибутов очереди, таких как дата его создания, количество записей, которые могут содержать очередь, и длина записей. Записи в очереди могут быть фиксированной длиной.
В отличие от файловых моделей DDM, нет необходимости открывать метод доступа в очереди. Программы могут добавлять записи в очередь и получать записи из очереди, как определено классом очереди. Программы также могут очищать записи из очереди, устанавливать операции с очередью, составлять список атрибутов очереди и проверять атрибуты очереди. Программы также могут блокировать очередь или отдельные записи в очереди, чтобы предотвратить предотвращение программы со стороны других. Все остальные клиенты должны дождаться снятия блокировки.
A реляционная база данных (RDB) - это реализация языка структурированных запросов (SQL), который поддерживает создание, управление, запросы, обновление, индекс и взаимосвязь. таблиц данных. Интерактивный пользователь или программа могут выдавать операторы SQL в RDB и получать в ответ таблицы данных и индикаторы состояния. Однако операторы SQL также могут быть скомпилированы и сохранены в RDB как пакеты, а затем вызваны по имени пакета. Это важно для эффективной работы прикладных программ, которые выдают сложные высокочастотные запросы. Это особенно важно, когда таблицы, к которому нужно получить доступ, находятся в удаленных системах.
Архитектура распределенной реляционной базы данных (DRDA) хорошо вписывается в общую структуру DDM, как описано в Объектно-ориентированная. (Однако DDM также можно рассматривать как компонентную энергиюуру DRDA, поскольку требуются и другие спецификации). Объекты уровня менеджера DDM, поддерживающие DRDA, называются RDB (для реляционной базы данных) и SQLAM (для SQL Application Manager).
Прозрачность - ключевая цель архитектуры DDM. Без перекомпиляции должна быть возможность перенаправить прикладные программы в службы управления данными удаленного компьютера. Что касается файлов, в основном это было выполнено клиентами DDM на уровне интерфейса / функциональности, но как насчет полей в записи? Полная прозрачность требует, чтобы клиентские прикладные программы записывали и читать поля, закодированные их системой управления независимо от того, как их кодирует какой-либо удаленный сервер, а это подразумевает автоматическое преобразование данных.
, мэйнфрейм- компьютеры IBM кодируют числа с плавающей запятой в шестнадцатеричном формате, а символьные данные - в EBCDIC, а персональные компьютеры IBM кодируют их в формате IEEE и ASCII. Дальнейшая сложность возникла из-за способов различных языков программирования отображают поля строки строк языков, байтов и слов в памяти. Прозрачное преобразование записи требует подробных описаний как клиентского, так и серверного представления записи. С учетом этих описаний поля клиентского и серверного представлений могут быть сопоставлены по имени поля и могут быть выполнены соответствующие преобразования.
Ключевой проблемой является получение достаточно подробных описаний записей, но описания обычно задаются в прикладных программах абстрактно с помощью операторов объявлений, определенных языков программирования, при этом компилятор языка обрабатывает детали кодирования и отображения. В среде распределенной обработки необходим единый стандартизованный способ описания записей, независимый от всех языков программирования, способный описывать широкий спектр форматов записей фиксированной и стандартной стандартизованной среды в использовании файлах.
Результат определения общей архитектуры описания и преобразования данных (DDC), основанной на новом специализированном языке программирования, языке данных (ADL), для описания клиентских и серверных представлений записей данных и для указание преобразований. Скомпилированные программы ADL могут затем вызываться сервером для выполнения необходимых преобразований по мере поступления записей на сервер или с сервера.
Архитектура DDC пошла дальше и определила средства, с помощью которых операторы объявления языка программирования могут быть автоматически преобразованы в ADL и из него, и, следовательно, из одного языка программирования в другой. Эта возможность никогда не была реализована из-за ее сложности и стоимости. Однако создается компилятор ADL, и программы ADL вызываются, когда они доступны для выполнения преобразований с помощью DFM и системы хранения IBM 4680. Однако прикладным программистом необходимо вручную писать программы ADL.
Следующие продукты IBM реализуют различные подмножества архитектуры DDM:
Полный список продуктов, в которых реализован DRDA, см. в таблице продуктов DRDA с открытым исходным кодом.