Распределенная архитектура управления данными

Распределенная архитектура управления данными ( DDM ) — это IBM открытая опубликованная программная архитектура для создания, управления и доступа к данным на удаленном компьютере. DDM изначально был разработан для поддержки файлов, ориентированных на записи ; он был расширен для поддержки иерархических каталогов , потоковых файлов , очередей и обработки системных команд; в дальнейшем она была расширена и стала основой архитектуры распределенной реляционной базы данных IBM (DRDA); и, наконец, он был расширен для поддержки описания и преобразования данных . Созданный в период с 1980 по 1993 год, DDM определяет необходимые компоненты, сообщения и протоколы, основанные на принципах объектной ориентации . DDM сам по себе не является частью программного обеспечения; реализация DDM принимает форму клиентских и серверных продуктов. Будучи открытой архитектурой , продукты могут реализовывать подмножества архитектуры DDM, а продукты могут расширять DDM для удовлетворения дополнительных требований. В совокупности продукты DDM реализуют распределенную файловую систему .

Архитектура DDM в средствах массовой информации.

Распределенные приложения

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

1. Протокол передачи файлов (FTP) копирует или перемещает целые файлы или таблицы базы данных каждому клиенту, чтобы с ними можно было работать локально. Эта модель подходит для высокоинтерактивных приложений, таких как редакторы документов и электронных таблиц, где у каждого клиента есть копия соответствующего редактора, и совместное использование таких документов обычно не является проблемой.
2. Приложения тонких клиентов представляют пользователям интерфейс приложения, в то время как вычислительные части приложения централизованы с затронутыми файлами или базами данных. В этом случае связь состоит из удаленных вызовов процедур между тонкими клиентами и сервером, в которых уникально разработанные сообщения определяют вызываемую процедуру, связанные с ней параметры и любые возвращаемые значения.
3. Приложения толстого клиента выполняют все задачи обработки приложений в клиентских системах, но данные централизованы на сервере, поэтому ими можно управлять, чтобы к ним мог получить доступ любое авторизованное клиентское приложение, чтобы все клиентские приложения работали с обновленными данные, и чтобы передавались только записи , разделы потока или таблицы базы данных, на которые влияет приложение. Клиентские прикладные программы должны быть распространены на всех клиентов, работающих с централизованными данными.

Архитектура DDM изначально была разработана для поддержки толстого клиента» модели распределенных приложений « ; он также поддерживает передачу целых файлов.

Преимущества, предоставляемые архитектурой DDM

Архитектура DDM предоставляет распределенным приложениям следующие преимущества:

• Локальная/удаленная прозрачность. Прикладные программы можно легко перенаправить с локальных данных на удаленные. Специализированные программы для доступа и управления данными в удаленных системах не нужны.
• Уменьшенная избыточность данных. Данные необходимо хранить только в одном месте в сети.
• Лучшая безопасность. Устранив избыточные копии данных, можно лучше ограничить доступ к данным в сети только авторизованным пользователям.
• Целостность данных. Обновления, сделанные одновременно локальными и удаленными пользователями, не теряются из-за конфликтов.
• Более своевременная информация. Пользователи нескольких компьютеров в сети всегда имеют доступ к самым последним данным.
• Лучшее управление ресурсами. Ресурсы хранения и обработки данных в сети компьютеров могут быть оптимизированы.

История

Архитектура DDM — это набор спецификаций для сообщений и протоколов, которые позволяют управлять данными, распределенными по сети компьютеров, и получать к ним доступ.

Первоначальные усилия

IBM Системная сетевая архитектура (SNA) изначально была разработана для обеспечения иерархического подключения рабочих станций к мэйнфреймам IBM. Доступные в то время сети связи были жестко спроектированы с точки зрения фиксированных соединений между мэйнфреймом и его набором рабочих станций, которые находились под полным программным контролем мэйнфрейма. Другая связь между мэйнфреймами также осуществлялась посредством фиксированных соединений, используемых программным обеспечением, определенным для конкретных целей. Поскольку сети связи стали более гибкими и динамичными, возникла необходимость в универсальной одноранговой связи, при которой программа на одном компьютере могла инициировать и взаимодействовать с программой на другом компьютере.

Когда в начале 1980-х годов была определена архитектура IBM SNA Advanced Program to Program Communications (APPC), стало также очевидно, что APPC можно использовать для предоставления услуг операционной системы на удаленных компьютерах. Рабочая группа SNA реализовала эту идею и наметила несколько возможных распределенных служб, таких как файловые службы, службы принтеров и службы системной консоли, но не смогла начать разработку продукта. Программное обеспечение APPC еще не было доступно на мэйнфреймах, и, по сути, мэйнфреймы по-прежнему рассматривались в первую очередь как автономные системы. В результате работа над распределенными сервисами была приостановлена ​​рабочей группой SNA.

Члены рабочей группы SNA из лаборатории разработки IBM в Рочестере, штат Миннесота, были убеждены, что существует экономическое обоснование для распределенных услуг среди компьютерных систем среднего уровня, производимых в Рочестере. Примитивная форма распределенных файловых служб, названная Distributed Data File Facility (DDFF), была реализована для соединения миникомпьютеров IBM System/3 , IBM System/34 и IBM System/36 . Кроме того, компьютеры IBM System/36 и IBM System/38 продавались клиентам в больших количествах, и существовала очевидная необходимость обеспечить, например, возможность взаимодействия компьютеров в штаб-квартире компании с компьютерами на различных складах. APPC был реализован в этих системах и использовался различными приложениями клиентов. Идея распределенных сервисов операционных систем была затем возрождена как проект Golden Gate и попытка оправдать его развитие. Эта попытка также провалилась; Сама идея распределенных сервисов была слишком новой для разработчиков продуктов IBM, чтобы они могли количественно оценить ценность программного обеспечения, связывающего разнородные компьютеры.

Однако один из специалистов по планированию «Золотых ворот» , Джон Бонди, остался убежденным и убедил руководство создать отдел, выходящий за рамки обычного контроля со стороны Рочестерской лаборатории, чтобы не было немедленной необходимости в заранее определенном экономическом обосновании. Далее он сузил ее задачу, включив в нее только поддержку Distributed Data Management (DDM), в частности, поддержку файлов, ориентированных на записи . Затем он убедил опытного архитектора программного обеспечения Ричарда А. Демерса присоединиться к нему в работе по определению архитектуры DDM и продаже идеи DDM системным компаниям IBM.

Первый год этих усилий был по большей части бесплодным, поскольку системные компании IBM продолжали требовать предварительных бизнес-обоснований и настаивали на том, чтобы форматы сообщений были изоморфны интерфейсам блоков управления их локальных файловых систем. Кроме того, когда персональные компьютеры начали использоваться в качестве терминалов, подключенных к мэйнфреймам, утверждалось, что простое улучшение потока данных 3270 позволит ПК получить доступ к данным мэйнфреймов.

В этот период Демерс разработал архитектурную модель клиентов и серверов DDM, их компонентов и взаимодействия между взаимодействующими компьютерами. Кроме того, он определил общий формат сообщений DDM, основанный на принципах объектной ориентации, впервые использованных в языке программирования Smalltalk и IBM System/38. Эта модель прояснила, как продукты DDM могут быть реализованы в различных системах. См. раздел «Как работает DDM» .

В 1982 году проектировщики System/36 убедились, что существует достаточный рынок для файловых сервисов, ориентированных на записи DDM.

Уровень DDM 1: файлы, ориентированные на записи.

Общий формат сообщений DDM уже разработан, но какие конкретные сообщения следует определить? Файловая система System/36 была создана для удовлетворения ориентированных на запись потребностей языков программирования третьего поколения (3GL), таких как Fortran , COBOL , PL/I и IBM RPG , как и файловая система System/38 и файловая система System/36. Файловая система метода доступа к виртуальному хранилищу (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 в Херсли-Парке, Великобритания, над адаптацией большей части серверного программирования System/36 DDM для использования в среде обработки транзакций IBM Customer Information Control System (CICS). тем самым превращая CICS в сервер DDM как для операционных систем мэйнфреймов MVS, так и для VSE. Лоуренс также работал с программистами из лаборатории IBM в Кэри, Северная Каролина, над реализацией клиента DDM, ориентированного на записи, для IBM PC DOS .

Уровень 1 архитектуры DDM был официально опубликован в 1986 году. Во время этого объявления IBM вручила награду за выдающиеся технические достижения Кеннету Лоуренсу, награду за выдающийся вклад Ричарду Сандерсу и награду за выдающиеся инновации Ричарду Демерсу.

• В этой статье System/38 отныне будет использоваться для обозначения System/38 и ее преемников: IBM AS/400 (который объединил функциональные возможности System/36 и System/38), IBM iSeries и IBM Power Series (который объединил iSeries с IBM RS/6000, линейкой продуктов IBM для серверов и рабочих станций на базе RISC/UNIX).

Уровень DDM 2: иерархические каталоги и потоковые файлы.

С ростом важности IBM PC и операционной системы Unix в сетевых средах поддержка DDM также потребовалась для иерархических каталогов и потоко-ориентированных файлов персонального компьютера IBM под управлением IBM PC DOS и IBM RS/6000 под управлением IBM AIX ( версию Unix от IBM). См. Потоковые файлы .

Уровень 2 архитектуры DDM был опубликован в 1988 году. Ян Фишер и Сунил Гаитонде выполнили большую часть работы по архитектуре поддержки DDM для каталогов и потоковых файлов.

Уровень DDM 3: службы реляционных баз данных

В 1986 году IBM выпустила на рынок четыре различных продукта реляционных баз данных (RDB), каждый из которых создан для конкретной операционной системы IBM. Ученые из исследовательской лаборатории IBM в Альмадене разработали System/R*, прототип распределенной RDB, и они почувствовали, что пришло время превратить ее в рыночные продукты. Однако System/R* был основан на System/R, исследовательском прототипе RDB, и его было нелегко добавить к продуктам IBM RDB. Видеть для обсуждения RDB в среде распределенной обработки.

Роджер Рейнш из Центра программирования IBM в Санта-Терезе возглавил группу специалистов по различным продуктам для определения архитектуры распределенной реляционной базы данных (DRDA). Он записался:

• Представители каждого из четырех продуктов IBM RDB.
• Брюс Линдсей, исследователь System/R*,
• Пол Ровер (из лаборатории IBM в Зиндельфингене, Германия), который разработал спецификацию для описания данных, названную «Форматированные данные: архитектура объектного контента» (FD:OCA).
• Ричард Сандерс и Ричард Демерс из группы архитектуры DDM определят соответствующие модели, сообщения и протоколы.

В 1990 году уровень архитектуры DDM 3 и DRDA были опубликованы одновременно. IBM И DDM, и DRDA были определены как стратегические компоненты архитектуры системных приложений (SAA) . DRDA была реализована во всех четырех продуктах IBM RDB и других поставщиков.

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

Уровень DDM 4: Дополнительные услуги

Распределенное управление файлами (DFM) был инициирован проект по добавлению служб DDM в операционную систему IBM MVS, чтобы позволить программам на удаленных компьютерах создавать файлы VSAM , управлять ими и получать к ним доступ . Джон Хафферд, менеджер проекта DFM, обратился к команде DDM Architecture за средством преобразования полей данных в записях при их передаче между системами. Ричард Демерс взял на себя инициативу по этому вопросу при поддержке Коичи Ямагучи из проекта DFM. См. Описание и преобразование данных .

Следующие дополнительные услуги были определены Ричардом Сандерсом, Яном Фишером и Сунилом Гаитонде в архитектуре DDM на уровне 4:

• Для DFM — управление хранилищем и определяемые пользователем атрибуты файлов.
• Для DRDA — протоколы управления двухфазными фиксациями для распределенных единиц работы, ориентированных на приложение.
• Очереди, которые можно создавать, очищать или удалять на удаленном сервере. Записи очереди — это записи, определяемые приложением, которые добавляются в очередь или принимаются из нее. См . раздел «Очереди DDM» .
• Процессор системных команд — диспетчер, которому могут быть отправлены для выполнения команды, определенные хост-системой сервера.
• Многозадачный коммуникационный менеджер, который позволяет нескольким агентам клиента взаимодействовать с соответствующими агентами сервера, используя единый диалог между системами клиента и сервера.
• Менеджер точек синхронизации координирует логические единицы работы на нескольких серверах DDM. Протоколы двухфазной фиксации обеспечивают скоординированное восстановление ресурсов в случае сбоя какой-либо логической единицы работы.

Уровень 4 архитектуры DDM был опубликован в 1992 году.

Уровень DDM 5: Библиотечные услуги

Работа над архитектурой DDM уровня 5 заключалась в поддержке

• мэйнфрейма Многораздельные наборы данных , которые представляют собой файлы, состоящие из внутреннего каталога и нескольких элементов; по сути, это библиотеки похожих файлов.
• персональных компьютеров Библиотеки , которые объединяют доступ к файлам в нескольких папках в одной библиотеке.
• дальнейшие улучшения DRDA.

Ян Фишер был архитектором, ответственным за уровень 5 DDM, который был опубликован издательством Open Group , а не IBM. Вскоре после этого группа IBM по архитектуре DDM была расформирована.

Внутри ДДМ

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

Как работает DDM

Архитектура DDM определяет протокол клиент/сервер; то есть клиент запрашивает услуги у сервера, который взаимодействует со своими локальными ресурсами для выполнения запрошенной услуги, результаты которой, данные и индикаторы состояния, возвращаются клиенту. На приведенной выше диаграмме показаны роли клиентов и серверов DDM по отношению к локальным ресурсам. (Здесь используется общая терминология клиентов и серверов , но в архитектуре DDM клиент называется исходным сервером , а сервер называется целевым сервером .)

1. Прикладная программа взаимодействует с локальным ресурсом, например файлом, посредством программных интерфейсов, предоставляемых локальным менеджером ресурсов (LRM). Но если нужный ресурс находится на удаленном компьютере, в качестве посредника взаимодействия используется DDM. Прикладная программа продолжает использовать интерфейсы, предоставляемые ее LRM, но они перенаправляются на клиент DDM. Архитектура DDM не определяет, как должно происходить это перенаправление, поскольку она не поддерживает каталог удаленных ресурсов. Один из методов перенаправления, используемый некоторыми продуктами, ориентированными на файлы DDM, заключается в том, чтобы приложение открыло специальный локальный файл, называемый файлом DDM в System/38 , который предоставляет информацию о местоположении и доступе к удаленному файлу. Затем происходит перенаправление на клиент DDM.
2. Архитектура DDM определяет объекты уровня менеджера для файлов, реляционных баз данных, методов доступа и т. д. Менеджер клиентских ресурсов (CRM) полиморфно поддерживает функциональные интерфейсы, определенные LRM клиентской системы. Его основной функцией является создание соответствующих линеаризованных команд DDM и объектов данных для каждого функционального интерфейса. (См. сообщения DDM .) Эти объекты отправляются диспетчеру ресурсов сервера (SRM) удаленного сервера DDM. Однако на самом деле они маршрутизируются через клиентские и серверные агенты DDM и менеджеры связи.
3. Агент клиента DDM помещает линеаризованную команду в конверт RQSDSS, а линеаризованные объекты — в связанные конверты OBJDSS. (См. Сообщения DDM .) Агент клиента взаимодействует с агентом сервера, чтобы создать путь для сообщений, которые он получает от CRM, для передачи в SRM. Если прикладной программе необходимо взаимодействовать только с одним удаленным ресурсом, это просто. Однако прикладная программа может одновременно взаимодействовать с несколькими ресурсами различного типа, расположенными в нескольких удаленных системах. Клиентский агент во всех случаях представляет прикладную программу и направляет сообщения по отдельным виртуальным путям к каждому ресурсу.
4. Диспетчер клиентских коммуникаций взаимодействует с диспетчером серверных коммуникаций для реализации протокола диалога в форме «Я говорю, пока вы слушаете, а затем вы говорите, пока я слушаю». Могут использоваться различные телекоммуникационные протоколы, включая IBM SNA APPC и Интернет-протокол TCP/IP.
5. Сообщения DDM, передаваемые диспетчеру связи с сервером, передаются агенту сервера по пути, указанному в сообщении, и он пересылает сообщения в SRM по тому же пути. Если агент сервера взаимодействует с одним клиентом по одному пути, это просто. Однако агент сервера может взаимодействовать с несколькими клиентами по разным путям.
6. Диспетчер ресурсов сервера (SRM) анализирует сообщения DDM и определяет, что необходимо сделать для выполнения запроса. Он может использовать один или несколько функциональных интерфейсов соответствующего диспетчера локальных ресурсов (LRM) серверной системы.
7. SRM накапливает данные и индикаторы состояния от LRM и генерирует соответствующие линеаризованные объекты и ответные сообщения, которые передает агенту сервера.
8. Агент сервера упаковывает ответы и объекты в конверты RPYDSS и OBJDSS и пересылает их диспетчеру связи с сервером, который отправляет их диспетчеру связи с клиентами и агенту клиента по тому же пути, что и исходная команда.
9. Агент клиента удаляет ответ и объекты из соответствующих конвертов RPYDSS и OBJDSS и передает их диспетчеру ресурсов клиента.
10. Менеджер клиентских ресурсов анализирует возвращенный объект и ответные сообщения и отображает их, как ожидается исходным функциональным интерфейсом LRM, для возврата в прикладную программу.

Объектно-ориентированность

Архитектура DDM является объектно-ориентированной . Все объекты, определенные DDM, являются объектами, определяемыми самоопределяющимися объектами классов . Сообщения, ответы и данные, которые передаются между системами, представляют собой сериализованные объекты. Каждый объект определяет свою длину, идентифицирует свой класс с помощью кода DDM и содержит данные, определенные его классом. Кроме того, его класс определяет команды, которые могут быть отправлены его экземплярам, ​​когда объект находится в клиенте или сервере DDM, тем самым инкапсулируя объект с помощью ограниченного набора операций.

Структурно архитектура DDM состоит из иерархических уровней объектов, каждый из которых проявляет возникающие свойства на все более высоких уровнях.

• Поле — это строка битов, которая кодирует число, символ или другой объект данных. Экземпляры подкласса Field инкапсулированы операциями, которые может выполнять его класс; например, арифметические операции над целочисленными полями.
• Объект — это самоидентифицирующаяся сущность, состоящая из одного или нескольких полей, инкапсулированных с помощью определенного набора операций. Объекты этого уровня были созданы на основе классов объектов ядра Smalltalk. языка программирования
  • Скалярный объект состоит из одного поля, закодированного и описанного классом объекта. Скалярные объекты используются в качестве значений параметров объектов команды и ответа. Они также используются в качестве значений атрибутов объекта, таких как длина объекта в документации DDM. Методы кодирования, используемые для значений этих скалярных объектов, полностью определяются архитектурой DDM.
  • Сопоставленный объект состоит из одного или нескольких полей, например полей записи, определенной приложением. Методы кодирования и выравнивание этих полей не определяются архитектурой DDM; вместо этого он определяется операторами объявления прикладной программы и методами кодирования и выравнивания его языка программирования.
  • Объект коллекции — это контейнер для объектов, определенный классом коллекции. Примерами объектов коллекции являются команды и ответы DDM.
• Менеджер — это самоидентифицирующаяся сущность, предоставляющая среду для хранения и обработки объектов. Менеджер инкапсулирован операциями, определенными его классом. Вместе набор менеджеров реализует общую среду обработки клиента или сервера DDM. Сущности менеджера на этом уровне были созданы на основе системных объектов операционной системы System/38. Менеджеры, определенные DDM, включают в себя: словарь, супервизор, агент, каталог, файл(ы), метод(ы) доступа, реляционную базу данных, диспетчер приложений SQL, очередь, диспетчер блокировок, диспетчер безопасности, диспетчер восстановления, процессор системных команд, диспетчер связи. (с).
• Сервер — это самоидентифицирующийся объект, который предоставляет среду для хранения и обработки менеджеров в качестве клиента или сервера в распределенной среде обработки. Примерами являются клиенты и серверы, специализирующиеся на распределенном управлении файлами или распределенными реляционными базами данных.

Хотя архитектура DDM является объектно-ориентированной, продукты DDM были реализованы с использованием языков и методов, типичных для их хост-систем. Версия DDM для Smalltalk была разработана для IBM PC компанией Object Technology International , при этом соответствующие классы Smalltalk автоматически создавались из Справочного руководства DDM.

Подмножества и расширения

DDM — это открытая архитектура. Продукты DDM могут реализовывать подмножества архитектуры DDM; они также могут создавать свои собственные расширения.

Команда DDM «Обмен атрибутами сервера» — это первая команда, отправляемая при подключении клиента к серверу. Он идентифицирует клиента и указывает менеджеров, которые требуются клиенту, а также уровень архитектуры DDM, на котором требуется поддержка. Сервер отвечает, идентифицируя себя и указывая, на каком уровне он поддерживает запрошенных менеджеров. Общее правило заключается в том, что продукт, поддерживающий уровень X менеджера DDM, должен также поддерживать уровень X-1, чтобы новые серверные продукты могли соединяться со старыми клиентскими продуктами.

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

• в качестве клиента, сервера или того и другого. Например, DDM/PC — это только клиент, CICS/DDM — только сервер, а System/38 DDM — это и клиент, и сервер.
• для поддержки конкретных менеджеров, таких как файлы, ориентированные на записи, файлы, ориентированные на поток, реляционные базы данных (как часть DRDA) или любая их комбинация. Например, база данных MVS 2 обеспечивает поддержку клиентов и серверов только для того подмножества DDM, которое требуется для DRDA.
• для поддержки только избранных команд менеджера, таких как возможность загрузки и выгрузки записей из последовательного файла.
• для поддержки выбранных параметров команды, таких как параметр «Вернуть неактивные записи» команды «Получить запись».

Когда клиент DDM подключен к известному серверу DDM, например клиент System/38 к серверу System/38, архитектуру DDM также можно расширить, добавив

• новые менеджеры по конкретным продуктам.
• новые команды для существующего менеджера DDM.
• новые параметры для команды DDM или ответного сообщения.

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

Сообщения DDM

В чисто объектно-ориентированной реализации DDM клиенты и серверы, а также все содержащиеся в них менеджеры и объекты существуют в куче памяти, а для их соединения используются указатели (адреса памяти). Например, объект команды указывает на каждый из своих объектов параметров. Но таким способом команда не может быть передана от клиента к серверу; изоморфная копия команды должна быть создана как одна непрерывная строка битов. В куче команда состоит из размера команды в куче, указателя на класс команды и указателей на каждый из объектов параметров команды. Линеаризованная команда состоит из общей длины линеаризованной команды, кодовой точки, идентифицирующей класс команды, и каждого из ее линеаризованных объектов параметров. Архитектура DDM присваивает уникальные кодовые точки каждому классу объектов. Этот простой метод используется для всех объектов, передаваемых между клиентом и сервером, включая команды, записи и ответные сообщения.

Все эти линеаризованные объекты помещаются в конверты, которые позволяют агентам клиента и сервера координировать свою обработку. В архитектуре DDM эти конверты называются структурами потоков данных (DSS). Команды помещаются в DSS запроса (RQSDSS), ответы помещаются в DSS ответа (RPYDSS), а другие объекты помещаются в DSS объекта (OBJDSS). В RQSDSS может быть только одна команда и только один ответ в RPYDSS, но в OBJDSS можно поместить множество объектов, например записей. Кроме того, многие OBJDSS могут быть связаны с RQSDSS или PRYDSS, чтобы разместить столько объектов, сколько необходимо. DSS состоит из общей длины DSS, байта флага, идентифицирующего тип DSS, идентификатора запроса и линеаризованных объектов в DSS. Идентификатор запроса связывает RQSDSS с последующими OBJDSS от клиента, например, с записями, которые должны быть загружены в файл с помощью команды «Загрузить файл» . Идентификатор запроса также связывает RQSDSS от клиента с RPYDSS или OBJDSS от сервера к клиенту.

Документация

Справочное руководство DDM состоит из именованных объектов Menu, Help и Class. Подклассы класса DDM Class описываются переменными, которые определяют

• суперкласс класса. Классы определяются иерархией наследования; например, файл записи является подклассом файла, который является подклассом менеджера и наследует его данные и команды. Класс Çlass и его подклассы самоописываются с помощью команд çlass и переменных класса , включая:
• заголовок, который кратко описывает класс.
• статус класса относительно текущей работы над архитектурой DDM.
• описательный текст и графика, связывающие класс с его компонентами и средой.
• данные (поля, объекты, менеджеры и т. д.), инкапсулированные экземплярами класса.
• команды, которые можно отправлять его экземплярам.

Эти объекты могут содержать ссылки на другие именованные объекты в тексте и спецификациях, тем самым создавая гипертекстовые связи между страницами Справочного руководства DDM. Страницы меню и справки образуют интегрированное руководство по DDM. Бумажная версия Справочного руководства DDM уровня 3 громоздка, содержит более 1400 страниц и несколько неудобна в использовании, но интерактивная версия также была создана с использованием внутренних средств связи IBM. Учитывая относительно низкую скорость этих средств связи, они в основном использовались в лаборатории IBM в Рочестере.

В дополнение к Справочному руководству DDM имеется Общая информация. документ, предоставляющий информацию о DDM на высшем уровне, и Руководство программиста обобщает концепции DDM для программистов, реализующих клиенты и серверы.

Модели файлов DDM

Архитектура DDM определяет три основные модели файлов: файлы, ориентированные на записи, файлы, ориентированные на потоки, и иерархические каталоги.

Архитектура DDM предоставляет следующие услуги для управления удаленными файлами:

• создание, очистка и удаление файлов,
• копирование, загрузка и выгрузка данных файла,
• блокировка и разблокировка файлов,
• получение и изменение атрибутов файлов,

Файлы, ориентированные на запись

Файлы, ориентированные на записи, были разработаны с учетом требований к вводу, выводу и хранению данных языков программирования третьего поколения (3GL), таких как Fortran, Cobol, PL/I и RPG. Вместо того, чтобы каждый язык обеспечивал собственную поддержку этих возможностей, они были включены в службы, предоставляемые операционными системами.

Запись представляет собой серию связанных полей данных, таких как имя, адрес, идентификационный номер и зарплата одного сотрудника, в которых каждое поле закодировано и сопоставлено с непрерывной строкой байтов. Ранние компьютеры имели ограниченные возможности ввода и вывода, обычно в виде стопок перфокарт по 80 столбцов или в виде бумаги или магнитных лент. Записи приложений, такие как записи данных о сотрудниках, последовательно считывались или записывались по одной записи и обрабатывались пакетами. Когда стали доступны устройства хранения с прямым доступом, языки программирования добавили в программы способы произвольного доступа к записям по одной, например, доступ по значениям ключевых полей или по положению записи в файле. Все записи в файле могут иметь один и тот же формат (как в файле расчета заработной платы) или разные форматы (как в журнале событий). Некоторые файлы доступны только для чтения, поскольку их записи, однажды записанные в файл, могут быть только прочитаны, в то время как другие файлы позволяют обновлять свои записи.

Файловые модели DDM, ориентированные на записи, состоят из атрибутов файла, таких как дата его создания, дата последнего обновления, размер записей и слоты, в которых записи могут храниться. Записи могут иметь фиксированную или переменную длину, в зависимости от носителя, используемого для хранения записей файла. DDM определяет четыре типа файлов, ориентированных на записи:

• Последовательные файлы, в которых записи хранятся в последовательных слотах.
• Прямые файлы, в которых отдельные записи хранятся в слоте файла, определяемом значением поля записей.
• Файлы с ключами, в которых записи хранятся в последовательных слотах и ​​для которых вторичный порядок поддерживается посредством индекса значений ключевых полей, содержащихся в записях.
• Альтернативные индексные файлы, в которых отдельный индекс значений ключевых полей основан на существующем последовательном, прямом или ключевом файле.

Архитектура DDM также определяет множество методов доступа для работы с файлами, ориентированными на записи, различными способами. Метод доступа — это случай использования файла, созданного с помощью команды OPEN, которая подключается к файлу после определения того, имеет ли клиент право использовать его. Метод доступа отключается от файла с помощью команды CLOSE.

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

В файле одновременно можно открыть несколько экземпляров методов доступа, каждый из которых обслуживает одного клиента. Если файл открыт для доступа к обновлению, могут возникнуть конфликты, когда к одной и той же записи обращаются несколько клиентов. Чтобы предотвратить такие конфликты, можно получить блокировку всего файла. Кроме того, если файл открывается для обновления, блокировка записи устанавливается первым клиентом, прочитавшим ее, и снимается, когда этот клиент ее обновляет. Все остальные клиенты должны дождаться снятия блокировки.

Потоковые файлы

Потоковые файлы состоят из одной последовательности байтов, в которую программы могут отображать данные приложения по своему усмотрению. Потоковые файлы — это основная файловая модель, поддерживаемая Unix и Unix-подобными операционными системами, а также Windows . DDM определяет модель файла с одним потоком и метод доступа к одному потоку.

Модель файла потока DDM состоит из атрибутов файла, таких как дата его создания, размер потока и непрерывного потока байтов. Доступ к потоку можно получить с помощью метода доступа к потоку. Прикладные программы записывают данные в части потока, даже если эти данные состоят из записей. Они отслеживают расположение элементов данных в потоке любым удобным для них способом. Например, поток данных файлов документов определяется программой обработки текста, такой как Microsoft Word , а поток данных файла электронной таблицы — такой программой, как Microsoft Excel .

Метод доступа к потоку — это случай использования файла потока одним клиентом. Курсор отслеживает позицию текущего байта подпотока, используемого клиентом. Используя различные команды SET, курсор можно указать на начало или конец файла, на любую конкретную позицию в файле или на любое положительное или отрицательное смещение от текущей позиции.

В файле одновременно можно открыть несколько экземпляров метода доступа Stream, каждый из которых обслуживает одного клиента. Если файл открыт для доступа «обновления», могут возникнуть конфликты, когда к одному и тому же подпотоку обращаются несколько клиентов. Чтобы предотвратить такие конфликты, можно получить блокировку всего файла. Кроме того, если файл открывается для обновления, блокировка подпотока устанавливается первым клиентом, который «прочитал» его, и снимается, когда этот клиент «обновляет» его. Все остальные клиенты должны дождаться снятия блокировки.

Иерархические каталоги

Иерархические каталоги — это файлы, каждая запись которых связывает имя с местоположением. Иерархия возникает, когда запись каталога идентифицирует имя и расположение другого каталога. Используя клиентские и серверные продукты DDM, программа может создавать, удалять и переименовывать каталоги на удаленном компьютере. Они также могут перечислять и изменять атрибуты файлов удаленных каталогов. Записи в каталоге можно последовательно читать с помощью метода доступа к каталогу DDM. Файлы, идентифицированные записями каталога, можно переименовывать, копировать и перемещать в другой каталог.

Очереди DDM

Очереди — это механизм связи, который обычно обеспечивает краткосрочную связь между программами посредством записей. Очередь DDM находится в одной системе, но к ней могут обращаться программы из нескольких систем. Существует три подкласса очередей DDM, которые можно создать в целевой системе с помощью отдельных команд создания:

• Очереди в порядке очереди — асинхронный канал между программами постановки в очередь и удаления из нее.
• Очереди «последним пришел — первым ушел», складной стек.
• Очереди с ключами — механизм разветвления, в котором выбранные записи могут быть исключены из очереди по значению ключа.

Модель очереди DDM состоит из атрибутов очереди, таких как дата ее создания, количество записей, которые может содержать очередь, и длина записей. Записи в очереди могут иметь фиксированную или переменную длину.

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

Реляционные базы данных

( Реляционная база данных RDB) — это реализация языка структурированных запросов (SQL), которая поддерживает создание, управление, запросы, обновление, индексирование и взаимосвязи таблиц данных. Интерактивный пользователь или программа может отправлять операторы SQL в RDB и получать в ответ таблицы данных и индикаторы состояния. Однако операторы SQL также можно скомпилировать и сохранить в RDB в виде пакетов, а затем вызывать по имени пакета. Это важно для эффективной работы прикладных программ, выдающих сложные высокочастотные запросы. Это особенно важно, когда таблицы, к которым осуществляется доступ, расположены в удаленных системах.

Архитектура распределенной реляционной базы данных (DRDA) прекрасно вписывается в общую структуру DDM, как описано в разделе «Объектно-ориентированная ориентация» . (Однако DDM также можно рассматривать как компонентную архитектуру DRDA, поскольку требуются и другие спецификации. ). Объекты уровня менеджера DDM, поддерживающие DRDA, называются RDB (для реляционной базы данных) и SQLAM (для диспетчера приложений SQL).

Описание и преобразование данных

Прозрачность — ключевая цель архитектуры DDM. Без перекомпиляции должна быть возможность перенаправить существующие прикладные программы в службы управления данными удаленного компьютера. Для файлов это в основном выполнялось клиентами DDM на интерфейсном/функциональном уровне, но как насчет полей данных в записи? Полная прозрачность требует, чтобы клиентские прикладные программы могли записывать и читать поля, закодированные их локальной системой управления данными, независимо от того, как их кодирует любой удаленный сервер, а это подразумевает автоматическое преобразование данных .

Например, мэйнфреймы IBM кодируют числа с плавающей запятой в шестнадцатеричном формате и символьные данные в EBCDIC , а персональные компьютеры IBM кодируют их в формате IEEE и ASCII . Дополнительная сложность возникла из-за способов, которыми компиляторы различных языков программирования отображают поля записи в строки битов, байтов и слов в памяти. Прозрачное преобразование записи требует подробного описания как клиентского, так и серверного представления записи. Учитывая эти описания, поля представлений клиента и сервера могут быть сопоставлены по имени поля и могут быть выполнены соответствующие преобразования.

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

Результатом стало определение комплексной архитектуры описания и преобразования данных (DD&C), на основе нового специализированного языка программирования A Data Language (ADL), для описания клиентских и серверных представлений записей данных и для определения преобразований. Скомпилированные программы ADL затем могут быть вызваны сервером для выполнения необходимых преобразований по мере того, как записи передаются на сервер или с него.

Архитектура DD&C пошла дальше и определила средства, с помощью которых операторы объявления языка программирования могут автоматически преобразовываться в ADL и обратно, и, следовательно, из одного языка программирования в другой. Эта возможность так и не была реализована из-за ее сложности и стоимости. Однако был создан компилятор ADL, и программы ADL, если они доступны, вызываются для выполнения преобразований с помощью DFM и системы IBM 4680 Store. Однако программистам приложений необходимо вручную писать программы ADL.

Внедрение продуктов

Продукты DDM от IBM

Следующие продукты IBM реализовали различные подмножества архитектуры DDM:

• IBM Система/370
  • МВС (МВС/СП, МВС/ЕСА)
    • База данных 2 — клиент и сервер DRDA
    • CICS — файловый сервер записи в среде обработки транзакций CICS. Выпуск прекращен в CICS для z/OS V5.2 и более поздних версий.
  • VM (операционная система) (VM/SP, VM/ESA)
    • SQL/DS — клиент и сервер DRDA
  • DOS/VSE
    • CICS — файловый сервер записи в среде обработки транзакций CICS. Выпуск прекращен в CICS для z/VSE V2.1 и более поздних версий.
  • з/ОС
    • Распределенное управление файлами — файловый сервер записи
    • База данных 2 — клиент и сервер DRDA
• Система/36
  • Программа поддержки системы — клиент и сервер записи файлов
• System/38 и его преемники: AS/400, iSeries и Power Series.
  • Клиент и сервер записи файлов
  • Клиент и сервер каталогов и потоковых файлов
  • DRDA Клиент и сервер
• Персональный компьютер IBM
  • ПК ДОС
    • Netview/PC — клиент и сервер каталогов и потоковых файлов
    • DDM/PC — клиент каталогов и потоковых файлов.
    • Поддержка ПК/36 — клиент каталогов и потоковых файлов.
    • PC Support/400 — клиент каталогов и потоковых файлов.
  • Персональная система/2 - ОС/2
    • PC/Support/400 — клиент и сервер потоковой передачи файлов и каталогов
    • DRDA Клиент и сервер
• IBM 4680 и IBM 4690 Системы хранения
  • Клиент и сервер записи файлов
  • Клиент и сервер каталогов и потоковых файлов
• RS/6000 АИКС
  • DRDA Клиент и сервер

Продукты DDM других производителей

Полный список продуктов, в которых реализован DRDA, см. в Таблице идентификаторов продуктов DRDA с открытым исходным кодом .

См. также

• Файловая система, ориентированная на записи