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

редактировать

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

Архитектура DDM на носителе.

Содержание

  • 1 Распределенные приложения
  • 2 Преимущества, предоставляемые архитектурой DDM
  • 3 История
    • 3.1 Начальные усилия
    • 3.2 Уровень 1 DDM: файлы, ориентированные на записи
    • 3.3 Уровень DDM 2 : Иерархические каталоги и файлы, ориентированные на поток
    • 3.4 Уровень 3 DDM: Службы реляционных баз данных
    • 3.5 Уровень 4 DDM: Дополнительные службы
    • 3.6 Уровень 5 DDM: Библиотечные службы
  • 4 Внутри DDM
    • 4.1 Как работает DDM
    • 4.2 Объектная ориентация
    • 4.3 Подмножества и расширения
    • 4.4 Сообщения DDM
    • 4.5 Документация
    • 4.6 Модели файлов DDM
      • 4.6.1 Файлы с записью
      • 4.6.2 Файлы с потоковой ориентацией
      • 4.6.3 Иерархические каталоги
    • 4.7 Очереди DDM
    • 4.8 Реляционные базы данных
    • 4.9 Описание данных и преобразование
  • 5 Внедрение продуктов
    • 5.1 Продукты DDM от IBM
    • 5.2 Продукты DDM от других поставщиков
  • 6 См. также
  • 7 Ссылки

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

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

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

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

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

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

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

История

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

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

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

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

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

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

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

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

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

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

Общий формат сообщений DDM уже разработан, но какие сообщения следует определить? Файловая система определена система удовлетворения ориентированных на потребляющих языков программирования третьего поколения, таких как Fortran, COBOL, PL / I и IBM RPG, а также файловая система System / 38 и файловая система Virtual Storage Access Method (VSAM) мэйнфреймов IBM. И все же их фактические возможности и интерфейсы значительно различались, так что какие средства и интерфейсы поддерживают архитектуру DDM? См. файлы, ориентированные на записи.

Первоначальная работа над DDM в рамках проекта Golden Gate следовала примеру международного стандарта доступа и управления файлами (FTAM ) для распределенных файлов, но это было очень абстрактно и сложно сопоставить с локальными файловыми службами. Фактически, это было одним из препятствий для принятия системными фирмами IBM. Кеннет Лоуренс, системный архитектор, ответственный за файлы службы System / 36, утвержден, что могла бы легко реализовать хотя бы одна система IBM, а также другим системам запрашивать любые необходимые изменения. Естественно, он выступал за поддержку требований System / 36. После года неудач с продажей идей DDM другим системным компаниям аргументы IBM Лоуренса возобладали.

Ричард Сандерс присоединился к разработчикам команды архитектуры DDM и вместе с Лоуренсом и Демерсом работал над определением конкретных сообщений, необходимых для System / 36 DDM. Прогресс в определении DDM побудил System / 38 также принять участие. Это расширило сферу поддержки файлов записи DDM для удовлетворения требований расширенной файловой системы System / 38.

Файлы существуют в контексте, предоставляющем операционную систему, которая предоставляет услуги для организации файлов, совместного использования их с совместными пользователями и для защиты их от несанкционированного доступа. На уровне 1 DDM доступ к удаленным файловым каталогам не поддерживался, кроме передачи полного имени, который был сообщением. Однако безопасность и совместное использование были необходимы. Сандерс занимался проектированием в этих областях. Сандерс также определены электрические протоколы, используемые средства связи, которые были включены в компонент, называемый DDM Conversational Communications Manager. Первоначально реализован с использованием APPC, позже он был реализован с TCP / IP.

. После завершения разработки продукта System / 36 DDM Лоуренс работал с программистами из лаборатории IBM Hursley Park, Великобритания, чтобы адаптировать большую часть System / 36. Программирование DDM для использования сервера в среде обработки транзакций IBM Customer Information Control System (CICS), что делает CICS сервером DDM для операционных систем мэйнфреймов MVS и VSE. Лоуренс также работал с программистами из лаборатории IBM Cary, Северная Каролина, над реализацией клиента, ориентированного на записи DDM, для IBM PC DOS.

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

  • В этой статье 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 Personal Computer, на запущен IBM PC DOS. и IBM RS / 6000 под управлением IBM AIX (версия Unix от IBM). См. Файлы, ориентированные на поток..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внутри 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. Диспетчер ресурсов клиента анализирует возвращенный объект и отвечает на сообщения и сопоставляет их, как ожидалось исходным функциональным интерфейсом LRM для возврата в прикладную программу.

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

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

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

  • Поле - это строка битов, которая кодирует число, символ или другой объект данных. Экземпляры подкласса Полевые инкапсулируются операциями, которые могут выполнять его класс; например, арифметические операции над целочисленными полями.
  • Объект - это самоидентифицирующийся объект, состоящий из одного или нескольких полей, инкапсулированных определенным набором операций. Объекты на этом уровне были вдохновлены классами ядра ядра программирования Smalltalk
    • Скалярный объект из одного поля, как закодировано и описано классом объекта. Скалярные объекты используются в качестве параметров объектов команд и ответов. Они также используются в качестве значений атрибутов объекта, таких как длина объекта в DDM документации. Методы кодирования, используемые для значений этих скалярных объектов, полностью покрытой архитектурой DDM.
    • Отображенный объект из одного или нескольких, таких как поля записи, обязательное приложение. Методы кодирования и выравнивания этих полей не решающей архитектурой DDM; вместо этого он задает оператор объявления прикладной программы и методы кодирования и выравнивания своего языка программирования.
    • Объект коллекции - это контейнер для объектов, как определено классом коллекции. Примерами объектов коллекции являются команды и ответы DDM.
  • Менеджер - это самоидентифицирующийся объект, обеспечивающий хранение и обработку объектов. Менеджер инкапсулирован операциями, определенными его классом. Вместе набор менеджеров реализует общую среду обработки клиента или сервера DDM. Менеджеры систем диспетчера системы 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, например к системе / 38 к серверу System / 38, архитектура DDM также может быть расширена путем добавления

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

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

сообщения DDM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Очереди DDM

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

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

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

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

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

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

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

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

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

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

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

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

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

Реализация продуктов

продуктов DDM от IBM

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

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

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

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

См. также

Ссылки

Последняя правка сделана 2021-05-17 09:15:27
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте