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

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

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

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

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

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

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

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

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

История

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

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

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

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

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

Однако один из планировщиков Golden Gate , Джон Бонди, по-прежнему убеждал и убедил руководство создать отдел, не подчиняющийся обычному контролю лаборатории в Рочестере, чтобы не было немедленной необходимости в заранее определенном экономическом обосновании. Кроме того, он сузил свою миссию, включив только поддержку распределенного управления данными (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 и Файловая система метода доступа к виртуальному хранилищу (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 вручила награду за выдающиеся технические достижения Кеннету Лоуренсу, премию за выдающийся вклад Ричарду Сандерсу и премию за выдающиеся инновации Ричарду Демерсу.

• В этой статье System / 38 отныне будет использоваться для обозначения System / 38 и ее преемников: IBM AS / 400 (который объединил функциональность System / 36 и System / 38), IBM iSeries и IBM Power Series (которая объединила 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. См. Обсуждение RDB в среде распределенной обработки.

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

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

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

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

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

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

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

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

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

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

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

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

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

Внутри DDM

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

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

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

1. Прикладная программа взаимодействует с локальным ресурсом, например файлом, посредством программных интерфейсов, предоставляемых менеджером локальных ресурсов (LRM). Но если требуемый ресурс находится на удаленном компьютере, для взаимодействия используется DDM. Прикладная программа продолжает использовать интерфейсы, предоставляемые ее LRM, но они перенаправляются клиенту DDM. Архитектура DDM не определяет, как должно происходить это перенаправление, поскольку она не поддерживает каталог удаленных ресурсов. Один из методов перенаправления, используемый несколькими продуктами DDM, ориентированными на файлы, заключается в том, чтобы приложение открывало специальный локальный файл, называемый файлом DDM системой / 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, являются объектами, определенными самоопределяющимися объектами Class . Сообщения, ответы и данные, передаваемые между системами, являются сериализованными объектами. Каждый объект указывает свою длину, идентифицирует свой класс с помощью кодовой точки DDM и содержит данные, как определено его классом. Кроме того, его класс определяет команды, которые могут быть отправлены его экземплярам, ​​когда объект находится на клиенте или сервере DDM, тем самым инкапсулируя объект с помощью ограниченного набора операций.

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

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

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

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

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

Команда 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 состоит из названных объектов «Меню», «Справка» и «Класс». Подклассы класса DDM Class описываются переменными, которые определяют

• суперкласс класса. Классы определяются иерархией наследования; например, Record File является подклассом File, который является подклассом Manager и наследует их данные и команды. Класс Ç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, которая подключается к файлу после определения, авторизован ли клиент на его использование. Метод доступа отключается от файла с помощью команды ЗАКРЫТЬ.

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

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

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

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

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

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

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

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

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

Очереди DDM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• IBM System / 370
  • МВС (МВС / СП, МВС / ESA)
    • База данных 2 - клиент и сервер DRDA
    • CICS - файловый сервер записи в среде обработки транзакций CICS. Больше не поддерживается в CICS для z / OS V5.2 и новее.
  • ВМ (операционная система) (ВМ / SP, ВМ / ESA)
    • SQL / DS - клиент и сервер DRDA
  • ДОС / ВСЕ
    • CICS - файл-сервер записи в среде обработки транзакций CICS. Больше не поддерживается в CICS для z / VSE V2.1 и более поздних версий.
  • z / OS
    • Распределенное управление файлами - Запись файлового сервера
    • База данных 2 - клиент и сервер DRDA
• Система / 36
  • Программа поддержки системы - клиент и сервер записи файлов
• System / 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 с открытым исходным кодом .

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

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

использованная литература