|
|
АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
Многозвенная архитектура. В случае большого числа пользователей возникают проблемы своевременной и синхронной замены версий клиентских приложений на рабочих станциях. Такие проблемы решаются в рамках многозвенной архитектуры (рис. 3.7). Часть общих приложений переносится на специально выделенный сервер приложений. Тем самым понижаются требования к ресурсам рабочих станций, которые будут называться «тонкими» клиентами. Данный способ организации вычислительного процесса является разновидностью архитектуры клиент-сервер.  Рис. 3.7. Многозвенная архитектура
Использование многозвенной архитектуры может быть рекомендовано также в случае, если некоторая программа требует для своей работы много ресурсов, то может оказаться дешевле построить тонкую сеть с одним очень мощным сервером, чем использовать несколько мощных клиентских рабочих станций. Особенно это имеет значение, если данной программой пользуются не постоянно, а время от времени. На рис.3.8 представлена архитектура многозвенного приложения.
Рис. 3.8. Архитектура многозвенного приложения
Разумное сочетание производительности сервера приложений и производительности рабочих станций позволят построить сеть, более дешёвую при установке и эксплуатации.
3.9. Микроядерные архитектуры
В основе микроядерных архитектур лежит идея вынесения основной части функций ОС за пределы ядра. Ранние ОС строились по принципу монолитного ядра. Затем их стали строить по принципу многослойных систем. Использование микроядерной ОС стало альтернативой монолитной и многослойной ОС. Микроядерная ОС подобно традиционной может работать в 2 режимах: в режиме ядра и пользовательском режиме. Когда выполняется код, хранящийся в ядре, то ОС находится в режиме ядра и выполняемому процессу доступны все ресурсы компьютера. При работе в пользовательском режиме исполняемому процессу доступы не все ресурсы, например, ему запрещено обращаться к регистрам внешних устройств и для того, чтобы обратиться, например к диску, процесс должен обратиться к ядру. В традиционных ОС ядро выполняет функции управления процессами, управления памятью, файловой системой и внешними устройствами. Идея микроядерной архитектуры состоит в том, что ОС включает в себя небольшое ядро, несколько модулей, таких как модуль управления памятью (МП), модуль управления процессами (МПр), модуль управления файловой системой (МФ), модуль управления устройствами (МУ). Все модуль работают в режиме пользователя и общаются между собой с помощью сообщений. Микроядро работает в режиме ядра и выполняет функции коммутатора сообщений (рис. 3.9). Подобная организация позволяет строить модульные ОС. Например, заменив модуль МФ можно работать с другим типом файловой системы. Другим достоинством микроядерного подхода является возможности организовывать многомашинные системы (рис.3.10) за счет того, что микроядро может посылать сообщения как модулям, работающим на том же компьютере, так и модулю, работающему на других компьютерах.
Рис. 3.9. Микроядро работает в режиме ядра и выполняет функции коммутатора сообщений
Рис. 3.10. Система на базе компьютеров с микроядерными ОС
Система, показанная на рис. 3.10 содержит 2 компьютера, соединенных в локальную сеть. На каждом из компьютеров установлена микроядерная ОС, в состав которой кроме ядра входят модули МП, МПр, МФ, МУ. Каждый из компьютеров может запускать процесс, как у себя, так и на соседнем компьютере используя, например, команду spawn (). Для этого микроядро компьютера 1 посылает по сети сообщение микроядру компьютера 2. Микроядерные системы были очень популярны в девяностых и нулевых годах. В настоящее время они также продолжают использоваться. Примером может служить ОС реального времени QNX [34].
3.10. Удаленное выполнение работ
Выполнение заданий на одном или нескольких удаленных компьютерах используется достаточно давно. В основу положена достаточно очевидная идея – переслать исполняемый код на удаленный компьютер, например, используя FTP, и там его запустить. Ниже в качестве примеров рассмотрены 3 подхода: UNIX-to-UNIX Copy (UUCP), Sun Grid Engine и Globus Toolkit. UUCP является одной из старейших и простейших реализаций идеи выполнение заданий на одном или нескольких удаленных компьютерах. В Sun Grid реализуется идея кластера, в соответствии с которой множество распределенных ресурсов представляется пользователю как единая система. Globus Toolkit является реализацией идей построения грид-систем, обладающих открытой архитектурой и не имеющей централизованного управления. Информацию о других системах этого класса можно найти, например в [23].
Система UUCP – это очень старая система, которая появилась еще в конце семидесятых годов прошлого века и была ориентирована использовании в составе компьютерных сетей, построенных на базе модемных соединений. Она появилась практически одновременны с протоколом TCP/IP и была быстро вытеснена последним, хотя до настоящего времени она входит в состав многих Unix-систем. С точки зрения пользователя система UUCP – это набор Unix-команд, основными из которых являются следующие: UUCP - подготовка пересылки файла, UUCICO = пересылка файла, UUX - выполнение команды на удаленном компьютере, UUQX- выполнение удаленного задания.
В системе UUCP для обозначения удаленных файлов и команд используется синтаксис имя_компьютера! имя_компьютера! имя_компьютера!путь. Например, строка на языке shell: uuxcathost1/file1 host2!file2 | host3 lprбудет означать, что нужно слить 2 файла (file1 и file2), которые находятся, соответственно на хостах host1и host2, направить результат на host3 и распечать его там. Для выполнения данной операции указаннуя строку надо просто набрать на консоли.
Кластеры. Кластеры обычно определяют как параллельная или распределенная система, которая состоит из множества соединенных между собой компьютеров, которые используются как единый компьютерный ресурс. Основу кластера составляют ОС, которая должна обеспечить представление кластера как единого ресурса (Single System Image, SSI). Компьютеры, входящие в состав кластера, используются многими пользователями. В качестве примера кластера рассмотрим Sun Grid Engine (sge, gridengine), который является одной из распространенных кластерных систем. Несмотря на свое название он является не грид, а кластерной системой, поскольку имеет централизованное управление. Sun Grid Engine представляет собой распределённую систему управления очередями заданий, предназначенных для пакетного выполнения на узлах кластера. Кластер представляет собор набор вычислительных ресурсов, доступных пользователям обычно через одну точку доступа. Администратору может определять политику управления ресурсами. Планировщик распределяет задания по узлам кластера, свободными ресурсами, возможностями компьютеров и требованиями заданий по ресурсам. Пользователи могут запускать задания, не заботясь о месте их выполнения. Задания могут быть как обычными пакетными, так и интерактивными и параллельными, имеется поддержка нескольких систем контрольных точек с возможность динамической миграции заданий с узла на узел. Физически кластер состоит из следующих составных частей: управляющего (master) компьютера (хоста), запасного управляющего хоста (shadow master), административных хостов и пользовательских (submit) хостов и вычислительных хостов. Распределение хостов является ролевым - управляющий хост может одновременно являться и вычислительным. Роли отдельных хостов прописываются администратором на управляющем хосте. SGE может управлять отдельным кластером или группой кластеров.
На каждом вычислительном хосте в фоновом режиме работает программа-демон [31, оторая отвечает за формирование очереди заданий на выполнение. Каждый вычислительный хост может выполнять несколько заданий одновременно. Для выполнения работ пользователь составляет описание задания, которое содержит требования (profile) к объёму памяти, требуемой производительности, указывается также имя пользователя и имя группы. На управляющем хосте работает главный демон (sge_qmaster), который обслуживает очередь заданий, поступающих от пользователей и взаимодействует с другими (рабочими) демонами, получая от них информацию о производительности и загрузке узлов, текущем состоянии выполняемых заданий, и посылает им задания. При выборе заданий, назначаемых на исполнение могут одновременно использоваться 3 политики упорядочивания заданий, влияние каждой из которых определяется её весом. В случае появления проблем с управляющим хостом его можно заменить запасной управляющий хост.
SGE использует системные учётные записи пользователей. Любой пользователь, имеющий учётные записи на пользовательском и вычислительном хостах может запускать задания на выполнение в рамках SGE. Выделяются следующие группы пользователей: администратор (manager), который имеет все права, включая право изменять конфигурацию системы, операторы, которые могут управлять системой, но не могут изменять конфигурацию, владелец очереди, который может приостанавливать и закрывать очередь и пользователь, который - может запускать задания на выполнение.
Грид. Обычно под термином грид понимаетсягеографически распределенная инфраструктура, объединяющая множество разнотипных ресурсов, таких как компьютеры, хранилища и базы данных, сети, доступ к которым пользователь может получить из любой точки, независимо от места их расположения. Термин Грид в смысле одной из технологий распределенных вычислений появился в середине 90-х годов происходит от английского слова «grid» и в переводе на русский язык является «решетка» или электрическая сеть.
Классическим определением термина грид является следующее: «Грид-согласованная, открытая и стандартизованная среда, которая обеспечивает гибкое, безопасное, скоординированное разделение (общий доступ) ресурсов в рамках виртуальной организации». При этом под виртуальной организацией понимается сообщества пользователей, объединенных едиными научными, инженерными задачами, подчиняющихся некоторым заданным правилам. Классическое определение было дано столь широко, что его трактуют весьма свободно.
Концепция Грид предполагает создание компьютерной инфраструктуры нового типа, обеспечивающей глобальную интеграцию информационных и вычислительных ресурсов на основе промежуточного ПО, которое предоставляет пользователю набор стандартизированных сервисов для обеспечения надежного, совместимого, дешевого и всепроникающего доступа к географически распределенным вычислительным и информационным и ресурсам (отдельным компьютерам, кластерам и суперкомпьютерным центрам, хранилищам информации, сетям, научному инструментарию и т.д.).
Grid-технологии являются столь новой и активно развивающейся отраслью науки, что терминология в ней не устоялась, а применяемые классификации Grid инфраструктур разнообразны и многогранны. По этой причине авторы идеи грид сформулировали 3 критерия принадлежности системы к грид-системам [35]: грид должен координировать использование ресурсов при отсутствии централизованного управления, грид должен использовать стандартные, открытые, универсальные протоколы и интерфейсы, грид должен новый уровень качества обслуживания.
Из этих требований следует, что настоящий грид не может использовать централизованное управление. Если реализуется централизованное управление, но это не грид, а кластер. Кроме того, грид должен строиться с использованием стандартных открытых протоколов.
Не следует смешивать технологию Грид с технологией параллельных вычислений, ее задачи входит лишь координация использования ресурсов, хотя в рамках конкретной Грид-системы, возможно организовать параллельные вычисления с использованием существующих технологий (MPI, PVM,).
По своему назначению Grid принято делить на вычислительный грид (computational Grid) и грид для хранения больших массивов информации (data Grid), приборный грид (Device Grid), предназначенный для обслуживания сложных технических систем, грид доступа (Access Grid), ориентированный на организацио взаимодействие групп пользователей в рамках грид и семантический грид (Semantic Grid). Семантический грид является некоторым гибридом семантического веба и грид и орентирован, в первую очередь, на поддержку концепции электронной науки (e- science). Например, подбор исходных данных и вычислительных ресурсов для решения крупной научной проблемы. Функционирование семантического грида основано на самом широком использовании онтологий [36].
Рис. 3.11. Стек протоколов Грид
Архитектура Грид представляет собой архитектуру взаимодействующих протоколов, сервисов и интерфейсов.
Архитектура протоколов Грид разделена на уровни (рис. 3.11), и может быть представлена в виде стека (набор уровней и слоев) протоколов. Эта структура аналогична модели OSI (модель взаимодействия отрытых систем). Стек протоколов включает 5 уровня:
1. Аппаратный уровень (Fabrik Layer), к которому относятся протоколы, по которым соответствующие сервисы непосредственно работают с ресурсами;
2. Связывающий уровень (Connectivity Layer) составляют протоколы, которые обеспечивают обмен данными между компонентами базового уровня, а также протоколы идентификации и аутентификации;
3. Ресурсный уровень (Resource Layer)-это ядро многоуровневой системы, протоколы которого взаимодействуют с ресурсами, используя унифицированный интерфейс и не различая архитектурные особенности конкретного ресурса;
4. Коллективный (Collective Layer) уровень отвечает за координацию использования имеющихся ресурсов;
5. Прикладной уровень (Application Layer) описывает пользовательские приложения, работающие в среде виртутальной организации; приложения функционируют, используя протоколы, определенные на нижележащих уровнях.
В качестве примера реализации Грид рассмотрим более подробно ннструментальные средства Грид (Globus Toolkit), разработанные в рамках проекта Глобус (Globus Project).
Средства Globus Toolkit представляют собой совокупность программных компонент, и включает следующие основные компоненты.
GRAM (Globus Resource Allocation Manager), ответственный за создание/удаление процессов. Этот компонент Globus Toolkit устанавливается на вычислительном узле Грид-системы, в качестве которого может выступать как рабочая станция, так и вычислительный кластер. Пользователи формируют запросы к GRAM на специальном языке RSL (Resource Specification Language).
MDS (Monitoring and Discovery Service) обеспечивает способы представления информации о Грид-системе, такой как данные о конфигурации или состоянии как всей системы, так и отдельных ее ресурсов, логически организована в виде дерева, и доступ к ней осуществляется по стандартному протоколу LDAP (Lightweight Directory Access Protocol).
GASS (Global Access to Secondary Storage) обеспечивает возможность хранения массивов данных в распределенном окружении и доступа к этим данным.
GSI (Globus Security Infrastructure) обеспечивает защиту, включающую шифрование данных, а также аутентификацию и авторизацию с использованием механизма цифровых сертификатов Х.509 [23].
Globus Toolkit получил широкое распространение, так как был первым полноценным набором инструментальных средств для разработок в области технологии Грид и стал стандартом де-факто.
Ранние версии Globus Toolkit имели ряд недостатков, основным из которых являлось отсутствие унифицированных средств разработки приложений, способных взаимодействовать между собой.
Для решения этой проблемы была предложена Открытая архитектура сервисов Грид (Open Grid Services Architecture – OGSA). Стандарт OGSA определяет основной набор услуг, которые предоставляют Грид-системы, и описывает их архитектуру.
В OGSA Грид рассматривается как савокупность сервисов, которые могут использоваться для построения требуемой инфраструктуры. Стандарт OGSA предлагает конструировать Грид по принципу сервис-ориентированной архитектуры. Сервисы допускают множество реализаций, но имеют стандартный, строго специфицированный интерфейс, через который могут взаимодействовать как друг с другом, так и с приложениями Грид.
В OGSA предлагается трехуровневое представление Грид. Нижний уровень представлен ресурсами, которые могут входить в Грид-систему (Компьютеры, кластеры, диски, файлы, базы данных, сети). Средний уровень представляет собой сервисы (запуск заданий, доступ к данным, безопасность, управление ресурсами, мониторинг). На этом уровне осуществляется обобщение (виртуализация) ресурсов. Пользователю предоставляются высокоуровневые услуги с четко определенными интерфейсами. Строгая спецификация этого уровня является основная задачей OGSA. На верхнем уровне находятся пользовательские приложения, которые используют сервисы. Этот уровень в OGSA не специфицирован [37, 38, 39].
3.11. Системы, ориентированные на работу с сообщениями
Системы, ориентированные на работу с сообщениями, реализуют асинхронные механизмы связи и могут поддерживать сохранные механизмы связи, т.е. гарантируется, что сообщение не будет потеряно, даже если компьютер-приемник находится вне сети. Можно выделить две основные идеи использования механизмов работы с сообщениями при построении ИС. Во-первых механизм работы с сообщениями можно использовать для построения ИС, основное назначение которых состоит в формировании реакции на асинхронные события, во-вторых, сообщения можно рассматривать как средство синхронизации и интеграции процессов и приложений.
На практике используются, по крайней мере, 6 подходов к построению систем, ориентированных на работу с сообщениями.
1. Системы, поддерживающие графический интерфейс пользователя.
2. Системы, использующие механизм обмена сообщениями между отдельными подсистемами.
3. Распределенное приложение, реализуемые как множество процессов, обменивающихся сообщениями.
4. Распределенные приложения обмениваются скомпилированными сообщениями.
5. Обмен текстовыми сообщениями между пользователями.
6. Приложения обмениваются сообщениями, содержащими самоописываемые данные.
Все приложения, поддерживающие графический интерфейс пользователя (GUI), работают с событиями. Событие генерируется в случае, когда пользователь нажимает на кнопку на клавиатуре или щелкает мышкой. Все современные платформы программирования, такие как .NET и Java поддерживают эти механизмы.
Системы, использующие механизм обмена сообщениями между отдельными подсистемами, используются достаточно часто. Такой принцип используется при построения многих управляющих систем. Примером системы такого типа могут служить рассмотренные выше микроядерные ОС.
Одним из важнейших подклассов систем, работающих с сообщениями являются системы, реализуемые как множество процессов, обменивающихся сообщениями, поскольку на работе с сообщениями основана распространенная технология программирования для параллельных вычислительных систем, состоящих из большого числа процессоров, не имеющих общей памяти. В качестве основного способа взаимодействия параллельных процессов, работающих на разных процессорах, используется обмен сообщениями, что и дало название самой технологии – интерфейс передачи сообщений (Message Passing Interface, MPI).
Распределенные приложения, построенные по принципу обмена скомпилированными сообщениями, достаточно эффективны при построении корпоративных ИС. К этой группе, в первую очередь можно отнести очереди сообщений.
Системы обмен текстовыми сообщениями между пользователями также достаточно популярны. Это, прежде всего, системы электронной почна и разного рода системы обмена сообщениями.
ИС, в которых приложения обмениваются сообщениями, содержащими самоописываемые данные, в последние годы становятся все более популярны. К таким системам можно отнести, в первую очередь веб-сервисы, которые будут подробно рассмотрены ниже. Такие системы ориентированы, прежде всего, на использование в очень крупных системах, которые интегрируют сервисы принадлежащие разным пользователям.
Далее будут более подробно рассмотрены подходы к построения некоторых конкретных типов ИС, использующие механизмы работы с сообщениями.
MPI. MPI предполагает, что связь происходит в пределах известной группы процессов. Каждый процесс получает идентификатор (processID). Процессы объединяются в группы. Каждая группа имеет уникальный идентификатор (groupID). Идентификатор процесса уникален внутри группы.
Пара идентификаторов processID и groupID однозначно определяют процесс, каждый из которых может выступать как в качестве источника, так и в качестве приемника сообщения и используется вместо адреса транспортного уровня. В вычислениях может участвовать произвольное число процессов и групп процессов, которые выполняются одновременно на разных хостах.
MPI представляет собой библиотеку, которая содержит, в частности, примитивы для передачи сообщений, примитивы для приема сообщений и примитивы синхронизации процессов.
MPI-программа - это множество параллельных взаимодействующих процессов. Все процессы порождаются только один раз.
В ранних версиях в ходе выполнения MPI-программы порождение дополнительных процессов или уничтожение существующих не допускается. (Позже в версии MPI-2.0 такая возможность появилась.) Каждый процесс работает в своем адресном пространстве, никаких общих переменных или данных в MPI нет. Основным способом взаимодействия между процессами является явная посылка сообщений.
В состав библиотеки входит более ста функций, основными из которых являются следующие.
MPI_bsend- помещает исходящее сообщение в локальный буфер отправки сообщений.
MPI_send- отсылает сообщение и ждет, пока оно не будет скопировано в локальный или удаленный буфер отправки сообщений.
MPI_ssend- послать сообщение и ожидает начала его передачи на обработку.
MPI_sendrecv-отсылает сообщение и ожидает ответа.
MPI_isend-передает ссылку на исходящее сообщение и продолжает работу.
MPI_issend-передает ссылку на исходящее сообщение и ожидает начала его передачи на обработку.
MPI_recv-принять сообщение, блокировать работу в случае его отсутствия.
MPI_irecv- проверить наличие входящих сообщений, не блокируя работы.
Данная библиотека поддерживает практически все возможные типы взаимодействий, включая синхронные и асинхронные взаимодействия.
MPI поддерживает работу с языками С и Фортран, однако это совершенно не является принципиальным.
Стандарт MPI фиксирует интерфейсы, которые должны соблюдать как создатели платформ, так и прикладные программисты.
Текущей является версия MPI-2.0, которая появилась в конце 90-х годов, продолжает использоваться более ранний стандарт MPI-1.1.
Самую подробную информацию о MPI можно получить на сайте [39]
Очереди сообщений. Использование вызовов удаленных процедур и обращения к удаленным объектам позволяют скрыть детали взаимодействия между элементами в распределенных системах, то есть повышают прозрачность доступа. К сожалению, эти механизмы не идеальны. В частности, в условиях, когда нет уверенности в том, что на принимающей стороне в момент выполнения запроса компьютер работает, приходится искать альтернативные пути обмена. Кроме того, вызов удаленных процедур и обращения к удаленным объектам используют синхронные механизмы взаимодействия, при которой на время осуществления операции необходимо блокировать работу клиентского приложения.
Использование систем, ориентированных на работу с сообщениями позволяет организовывать надежное асинхронное взаимодействие в рамках распределенных гетерогенных систем. Использование очередей сообщений позволяет решить многие из проблем, связанные с надежностью и доступностью ИС, в частности, построения систем, работающих по принципу 24/7, т.е. систем доступных 24 часа в сутки и 7 дней в неделю. Подобный эффект достигается за счет того, что приложения, входящие в состав ИС, обмениваются сообщениями, которые обрабатываются и сохраняются на отдельных работающих круглосуточно серверах.
Такие системы называют системами очередей сообщений (Message-queuing systems, MQ).
Если один компонент ИС хочет послать сообщение другому компоненту, то он посылает данное сообщение MQ, а уж MQ затем пересылает его адресату.
Основная идея, лежащая в основе MQ, состоит в том, что приложения общаются между собой путем помещения сообщений в очереди. В общем случае, эти сообщения передаются по цепочке коммуникационных серверов и достигают места назначения, даже если получатель в момент отправки сообщения был неактивен. Каждое приложение может работать с произвольным числом очередей. Очередь может быть прочитана только связанным с ней приложением, при этом несколько приложений могут совместно использовать одну очередь.
Отправитель может гарантировать только попадание сообщения в очередь получателя, но не может гарантировать то, что сообщение будет действительно прочитано получателем. Отправитель и получатель могут функционировать абсолютно независимо друг от друга. Сообщения в принципе могут содержать любые данные. Адресация осуществляется путем назначения очереди имени, которое должно быть уникальным в пределах системы, в которую направляется сообщение.
Функционирования системы очередей сообщений можно описать с помощью 4 примитивов:
- put - добавить сообщение в соответствующую очередь;
- get - извлечь из очереди самое старое сообщение, если очередь пуста, то перейти в режим ожидания и оставаться в нем до момента появлении сообщения в очереди;
- poll - проверить наличие сообщений в очереди, если очередь не пуста, то извлечь из очереди самое старое сообщение, если очередь пуста, то продолжить работу.
Существует две основных модели обмена сообщениями: точка-точка (point-to-point) и публикация-подписка (publish-subscribe).
Модель точка-точка применяется тогда, когда отправителю требуется отправить сообщения одному получателю. При использовании данной модели адрес получателя определяется отправителем. Эта модель использует push-модель для работы с сообщениями, т. е. модель «проталкивания» сообщений.
Модель публикация-подписка предполагает, что в системе кроме отправителей и получателей имеется несколько очередей, которые называются темами (topics). Отправитель может помещать сообщения в любую тему. Каждый получатель может выражать заинтересованность в получении сообщений из произвольных очередей посредством подписки (subscription).
Модель публикация-подписка модель применима, когда одному или нескольким компонентам - писатели (publishers) необходимо послать сообщение одному или нескольким компонентам-адресатам - подписчикам (subscribers). Данная модель основана на понятии тем (message topic).
Отправители посылают сообщения в темы, и все подписчики данной темы получают эти сообщения.
Обе модели основаны на понятии очередь сообщений (message queue).
Сообщения могут быть помещены только в локальные очереди отправителя, то есть в очереди, находящиеся на том же самом хосте. Эта очередь называется исходящей очередью (source queue). Аналогично, прочитанные сообщения могут быть прочитаны только из локальных очередей. Таким образом, набор очередей представляет собой распределенную систему, разнесенную на множество хостов.
Выбор между первой или второй моделью определяется спецификой задачи.
Очереди управляются менеджерами очередей (queue managers). Обычно менеджер очередей взаимодействует непосредственно с отправляющими и принимающими сообщения приложениями. Существуют, однако, и специализированные менеджеры очередей, которые работают как маршрутизаторы, или ретрансляторы: они перенаправляют приходящие сообщения другим менеджерам очередей.
Практически все ведущие производители ИС, такие как Microsoft, IBM, Oracle и др. предлагают собственные системы работы с очередями сообщений.
В качестве примера системы работы с очередями сообщений рассмотрим систему IBM MQSeries.
IBM WebSphere MQ – это одна из самых мощных МQ систем, которая в качестве базового API используется Интерфейс Message Queuing Interface (MQI). Он представляет собой процедурный API для приложений, создаваемых с помощью процедурных языков программирования, таких как C, COBOL кроме того можно работать с объектно-ориентированными языками Java и C++, которые поддерживаются при помощи объектно-ориентированных API, созданных на основе MQI. WebSphere MQ, поддерживает также Java Message Service (JMS). В состав системы входят средства для обеспечения безопасного доступа, аутентификации.
WebSphere MQ приобрела популярность в относительно традиционной для IBM области мэйнфреймов, которые используются для организации доступа и обработки больших баз данных, а также для обработки больших объемов финансовых данных.
Базовая архитектура MQSeries достаточно традиционна. Все очереди и темы управляются менеджерами очередей (queue managers). Менеджер очередей отвечает за извлечение сообщений из выходных очередей и пересылку их другим менеджерам очередей.
Менеджеры очередей могут быть скомпонованы с каким-либо процессом в единое приложение, управляющее очередями. В этом случае очереди скрываются от приложений за стандартным интерфейсом, но непосредственная работа приложения с очередями может оказаться более эффективной. Другим вариантом организации может быть запуск и работа менеджеров очередей и приложений на разных хостах. В этом случае приложениям предоставляется такой же интерфейс, как и при размещении менеджеров очередей на одном с ними хосте.
Каналы сообщений представляют собой важный компонент системы MQSeries. Каждый канал сообщений имеет только одну связанную с ним очередь отправки. Из этой очереди выбираются сообщения, которые следует переслать на другой конец канала. Передача по каналу может происходить только в том случае, если активны как отправляющий, так и принимающий агенты.
Для передачи сообщения одним менеджером очередей другому (возможно, удаленному) необходимо, чтобы каждое сообщение содержало в себе адрес назначения. Для этого используется заголовок сообщения. Адрес в MQSeries образован из двух частей. Первая часть состоит из имени менеджера очередей, которому это сообщение должно быть доставлено, а вторая часть — это имя очереди назначения, сообщающее этому менеджеру, к какой очереди добавлять сообщение.
Кроме адреса получателя необходимо также определить маршрут, которым должно следовать сообщение. Описание маршрута производится путем задания имени локальных очередей отправки, в которые должно добавляться сообщение. Нет необходимости задавать в сообщении полное описание маршрута. Указав, в какую очередь отправки должно быть добавлено сообщение, можно однозначно определить, какому соседнему менеджеру очередей будет передано данное сообщение.
Обычно маршруты сохраняются в таблицах маршрутизации внутри менеджеров очередей.
Сообщения могут быть записаны в очередь или считаны из нее путем использования соответственно примитивов MQput и MQget. Обычно сообщения извлекают из очереди на основании их приоритета. Сообщения с одинаковым приоритетом извлекаются из очереди по принципу первым пришел — первым ушел (FIFO), то есть дольше всех находящиеся в очереди сообщения извлекаются первыми. Кроме того, можно запросить конкретное сообщение. Кроме всего прочего, MQSeries предоставляет средства для уведомления приложений о приходе сообщений, что позволяет приложениям не опрашивать постоянно очередь на предмет прихода новых сообщений.
WebSphere MQ – это программный продукт, входящий в состав IBM WebSphere.
Другим примером системы очередей сообщений может служить Java Message Service (JMS). JMS является составной частью JEE и представляет собой стандартный Java API, который позволяет создавать, посылать, получать и читать сообщения в асинхронном режиме. JMS определяет набор интерфейсов и классов, для работы с сообщениями.
С точки зрения используемого подхода, JMS похожа на JDBC. JMS позволяет работать с системами разных производителей (MQSeries, OpenMQ, SonicMQ и др., в которые включена поддержка JMS.
JMS API обеспечивает всю необходимую функциональность для работы с сообщениями как в режиме точка-точка, так и в режиме рассылка-подписка. Каждое из сообщений состоит из 3 частей: заголовка, свойств и тела.
Первые системы работы с сообщениями появились в конце 1980-х годов. Первая спецификация JMS 1.0 относится к 1998 году. В качестве эталонной реализации JMS можно указать на систему Open Message Queue (OpenMQ) [40].
Электронная почта как система работы с сообщениями. Одним из типовых применений систем работы с сообщениями является система электронной почты. В системе электронной почты хосты работают как пользовательские агенты, которые могут создавать, посылать, принимать и читать сообщения. Каждый хост соединяется с почтовым сервером, который выполняет функции коммуникационного сервера.
Когда пользовательский агент представляет сообщение для передачи на хост, то последний пересылает сообщение на локальный почтовый сервер. Почтовый сервер удаляет сообщение из своего выходного буфера и с помощью cервера имен (DNS) определяет куда нужно доставить сообщение.
Затем почтовый сервер устанавливает соединение и передает сообщение на целевой почтовый сервер, который, в свою очередь, сохраняет сообщение во входящем буфере получателя, т. е. помещает его в почтовый ящик получателя сообщения. Если искомый почтовый ящик временно недоступен, то сообщение сохраняется на почтовом сервере.
Интерфейс принимающего хоста предоставляет пользовательским агентам сервисы, при помощи которых они могут регулярно проверять наличие сообщений, т. е. пришедшей почты. Агент пользователя может работать либо напрямую с почтовым ящиком пользователя на локальном почтовом сервере или копировать сообщения в локальный буфер своего хоста. Систему электронной почты можно рассматривать как пример ИС обмен текстовыми сообщениями между пользователями [41].
|
|
|
Скачать 4.65 Mb.