Распределенная архитектура управления данными - Distributed Data Management Architecture

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

Архитектура DDM в СМИ.

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

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

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

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

Преимущества архитектуры DDM

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

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

История

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

Начальные усилия

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

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

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

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

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

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

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

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

Общий формат сообщений DDM уже был разработан, но какие конкретные сообщения следует определить? Файловая система System / 36 была определена для удовлетворения ориентированных на записи потребностей языков программирования третьего поколения (3GL), таких как Фортран, КОБОЛ, PL / I, и IBM RPG, а также файловая система System / 38 и Метод доступа к виртуальному хранилищу (VSAM) файловая система мэйнфреймов IBM. И все же их фактические возможности и интерфейсы значительно различались, поэтому какие средства и интерфейсы должна поддерживать архитектура DDM? Видеть файлы, ориентированные на запись.

Первоначальная работа над DDM Золотые ворота проект последовал примеру Доступ к передаче файлов и управление (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. Система управления информацией о клиентах (CICS), что делает CICS сервером DDM для операционных систем мэйнфреймов MVS и VSE.^[4] Лоуренс также работал с программистами из лаборатории IBM Cary, Северная Каролина, над реализацией клиента, ориентированного на записи DDM, для IBM PC DOS.

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

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

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

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

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

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

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

Роджер Райнш из IBM Santa Theresa Programming Center возглавил группу по разработке нескольких продуктов, чтобы определить Архитектура распределенной реляционной базы данных (DRDA). Он зачислил:

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

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

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

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

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

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

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

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

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

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

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

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

Внутри DDM

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

Как работает 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. Client Communications Manager взаимодействует с ServerCommunications Manager для реализации диалогового протокола в форме «Я говорю, пока вы слушаете, а затем вы говорите, пока я слушаю». Могут использоваться различные телекоммуникационные протоколы, в том числе IBM SNA APPC и Интернет-протокол TCP / IP.
5. Сообщения DDM, передаваемые в Server Communications Manager, передаются агенту сервера по пути, указанному в сообщении, и он пересылает сообщения в SRM по тому же пути. Если агент сервера взаимодействует с одним клиентом по одному пути, это просто. Однако агент сервера может взаимодействовать с несколькими клиентами по разным путям.
6. Диспетчер ресурсов сервера (SRM) анализирует сообщения DDM и определяет, что он должен сделать для выполнения запроса. Он может использовать один или несколько функциональных интерфейсов соответствующего диспетчера локальных ресурсов (LRM) серверной системы.
7. SRM накапливает данные и индикаторы состояния из LRM и генерирует соответствующие линеаризованные объекты и ответные сообщения, которые передает агенту сервера.
8. Агент сервера упаковывает ответы и объекты в конверты RPYDSS и OBJDSS и пересылает их в Server Communication Manager, который отправляет их Client Communication Manager и агенту клиента по тому же пути, что и исходная команда.
9. Агент клиента удаляет ответ и объекты из соответствующих конвертов RPYDSS и OBJDSS и передает их диспетчеру клиентских ресурсов.
10. Client Resource Manager анализирует возвращенный объект и ответные сообщения и сопоставляет их, как ожидалось исходным функциональным интерфейсом LRM, для возврата в прикладную программу.

Объектная ориентация

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

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

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

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

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

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

Команда DDM «Атрибуты сервера Exchange» - это первая команда, отправляемая, когда клиент подключается к серверу. Он идентифицирует клиента и указывает менеджеров, которых требует клиент, и уровень архитектуры 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^[12][13] состоит из именованных объектов Menu, Help и Class. Подклассы класса DDM Учебный класс описываются переменными, которые определяют

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Очереди DDM

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

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

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

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

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

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

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

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

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

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

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

Результатом стало определение всеобъемлющего Описание и преобразование данных архитектура (DD&C),^[14] на основе нового специализированного языка программирования, Язык данных (ADL),^[15] для описания клиентских и серверных представлений записей данных и для определения преобразований. Скомпилированные программы ADL могут затем вызываться сервером для выполнения необходимых преобразований по мере поступления записей на сервер или с сервера.

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

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

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

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

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

Продукты DDM от других поставщиков

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

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

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

Рекомендации