Эбберс М. Введение в современные мейнфреймы: основы z/OS

Подождите немного. Документ загружается.

412 Глава14

WebSphere Application Server содержит средства связи с другими подсистемами z/OS,

такими как CICS, DB2 и IMS. Связь осуществляется через адаптер ресурса и коннектор.

Доступ к корпоративным информационным системам (Enterprise Information Systems,

EIS) заднего плана расширяет функциональные возможности сервера приложений

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

J2EE Connector Architecture (JCA) определяет соглашения между приложением,

коннектором и сервером приложений, на котором выполняется приложение. Прило-

жение содержит компонент, называемый адаптером ресурса (resource adapter).

Он находится в коде приложения, обеспечивающем интерфейс с коннектором и со

здаваемым разработчиком приложения.

С точки зрения программирования это означает, что программисты могут исполь-

зовать единый унифицированный интерфейс для получения данных из EIS. Адаптер

ресурса отсортировывает различные элементы и обеспечивает модель программирова-

ния, не зависящую от фактического выполнения EIS и требований к связи.

1481 Коннекторы в z/OS

WebSphere для z/OS содержит следующие коннекторы, позволяющие веб-приложе-

ниям в z/OS взаимодействовать с программными продуктами промежуточного уров-

ня для мэйнфреймов, такими как CICS, IMS и DB2:

• CICS Transaction Gateway;

• IMS Connect;

• DB2 JDBC.

CICS Transaction Gateway

Система Customer Information Control System (CICS) содержит шлюз CICS Transaction

Gateway (CTG) для подключения сервера приложений к CICS. CTG обеспечивает ин-

терфейс между Java и транзакциям CICS-приложений. Он представляет собой набор

клиентских и серверных программных компонентов, включающих службы и средства

доступа к CICS с сервера приложений. CTG использует специальные API и протоколы

в сервлетах или EJB для запрашивания служб и функций менеджера транзакций CICS.

IMS Connect

IMS Connect представляет собой TCP/IP-сервер коннектора, позволяющий клиенту

сервера приложений обмениваться сообщениями с IMS Open Transaction Manager

Access (OTMA). Этот сервер осуществляет связь между TCP/IP-клиентами и базами

данных IMS. Он поддерживает множество TCP/IP-клиентов, осуществляющих доступ

ко множеству баз данных. Для защиты информации, передаваемой через TCP/IP, IMS

Connect обеспечивает поддержку протокола SSL (Secure Sockets Layer).

IMS Connect также может выполнять функции маршрутизатора между клиентами

сервера приложений и локальным клиентами с базами данных и ресурсами IMSplex.

Сообщения запросов, получаемые от TCP/IP-клиентов с использованием TCP/IP-под-

ключений или локальных клиентов, использующих z/OS Program Call (PC), передают-

 WebSphereApplicationServerвz/OS 413

ся в базу данных посредством сеансов межсистемного средства сопряжения (cross-

system coupling facility, XCF). IMS Connect получает сообщения ответов из базы данных,

после чего передает их обратно запросившим TCP/IP-клиентам или локальным кли-

ентам.

IMS Connect поддерживает TCP/IP-клиентов, связывающихся посредством сокет-

ных вызовов, однако также реализована поддержка любого TCP/IP-клиента, связыва-

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

тельских «выходов» сообщений (message exits)

могут выполняться в адресном про-

странстве IMS Connect для преобразования формата сообщений инсталляции z/OS

в формат сообщений OTMA, прежде чем IMS Connect отправит сообщение IMS. Поль

зовательские «выходы» сообщений также осуществляют преобразование формата

сообщений OTMA в формат сообщений инсталляции, прежде чем отправить сообще-

ние обратно в IMS Connect. Затем IMS Connect отправляет выходные данные клиенту.

DB2 JDBC

Java Database Connectivity (JDBC) представляет собой интерфейс программирования

приложений (API), используемый языком программирования Java для доступа к раз-

личным формам табличных данных, равно как и к некоторым иерархическим систе-

мам, таким как IMS. Спецификации JDBC были разработаны компанией Sun Microsys-

tems совместно с поставщиками реляционных баз данных, такими как Oracle и IBM,

чтобы обеспечить переносимость Java-приложений между платформами баз данных.

Этот интерфейс не обязательно попадает в категорию «коннекторов», так как для

его реализации не требуется отдельного адресного пространства. Интерфейс пред-

ставляет собой Java-конструкцию, подобную Java-классу, но не обеспечивающую реа-

лизацию своих методов. В JDBC действительная реализация JDBC-интерфейса обес-

печивается изготовителем базы данных и называется «драйвером». Это обеспечивает

переносимость, так как все операции доступа к JDBC выполняются посредством

стандартных вызовов со стандартными параметрами. Таким образом, можно напи-

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

весь код, зависящий от платформы, хранится в JDBC-драйверах.

В итоге JDBC должен быть гибким в отношении выполняемых и невыполняемых

им функций, основываясь только на том факте, что различные системы управления

базами данных имеют различный уровень функциональности. JDBC-драйверы обес-

печивают физический код, реализующий объекты, методы и типы данных, опреде-

ленные в спецификации. Стандарты JDBC определяют четыре типа драйверов с но-

мерами от 1 до 4. Различие между ними основано на физической реализации драйве-

ра и способе его связи с базой данных.

z/OS поддерживает только драйверы Type 2 и Type 4.

• Type 2.

JDBC API вызывает код, зависящий от платформы и базы данных, для доступа

к базе данных. Этот тип драйвера является наиболее используемым и обеспе

чивает наивысшую производительность. Однако так как код драйвера зависит

от платформы, для каждой платформы необходимо создавать отдельную вер-

сию (этим должен заниматься изготовитель базы данных).

414 Глава14

• Type 4.

Драйвер Type 4 полностью написан на Java и осуществляет доступ к целевой

базе данных напрямую, используя протокол самой базы данных (в случае DB2

используется протокол DRDA). Так как драйвер полностью написан на Java, его

можно перенести на любую платформу, поддерживающую данный протокол

DBMS без изменений, что позволяет приложениям использовать его на раз-

личных платформах без изменений.

Java-приложение, выполняющееся под управлением WebSphere Application Server,

взаимодействует с драйвером (Universal) Type 4 JDBC, поддерживающим двухфазовую

фиксацию, и драйвер взаимодействует напрямую с удаленным сервером базы данных

через DRDA. Драйвер Universal Type 4 реализует функциональные возможности DRDA

Application Requester.

Для доступа к DB2 в z/OS, IBM предоставляет драйвер Type 2 и драйвер, сочетаю-

щий реализации JDBC Type 2 и Type 4. В общем, связь JDBC Type 2 используется в Java-

программах, выполняющихся в той же системе z/OS с целевой подсистемой DB2.

Связь JDBC Type 4 используется в Java-программах, выполняющихся в системе z/OS,

отличной от той, где находится целевая подсистема DB2.

Основные термины в этой главе

Ячейка CS CGI

EIS JMX™ J2EE

SR Кластер Узел

149 Контрольные вопросы

Чтобы проверить понимание материала этой главы, ответьте на следующие вопросы:

1. Перечислите шесть свойств модели приложений J2EE.

2. Перечислите три причины выполнения WebSphere Application Server в z/OS.

3. Назовите три коннектора.

4. Какое основное различие между HTTP Server и WebSphere Application Server для

z/OS?

5. Когда следует использовать коннекторы?

 Обменсообщениямииуправлениеочередями 415

Обмен сообщениями

и управление очередями

ЦельКакспециалистувсферемэйнфреймов,вамнужнопониматьтакиепонятия,

какобменсообщениямииуправлениеочередямиЭтифункциинужныдлясвязи

междуразнороднымиприложениямииплатформами

Послезавершенияработынадэтойглавойвысможете:

• объяснить,почемуиспользуетсяобменсообщениямииуправлениеочередями;

• описатьасинхронныйпотоксообщений;

• описатьфункциименеджераочередей;

• перечислитьтриадаптера,связанныхсz/OS

416 Глава15

151 Что такое WebSphere MQ

Большинство крупных организаций в настоящее время имеют наследие из информа-

ционных систем разных производителей, что часто затрудняет совместный доступ

к средствам связи и данным между системами. Многим из этих организаций требует

ся также осуществлять электронную передачу и совместное использование данных

с поставщиками и клиентами, которые могут использовать другие разнородные сис

темы. Было бы удобно иметь инструмент обработки сообщений, который получал бы

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

IBM WebSphere MQ упрощает интеграцию приложений, передавая сообщения

между приложениями и веб-службами. Этот продукт используется более чем на 35

аппаратных платформах, а также для обмена сообщениями в системе «точка-точка»

из приложений на языках Java, C, C++ и COBOL. Три четверти предприятий, приобре-

тающих системы обмена сообщениями между приложениями, выбирают WebSphere

MQ. В самой крупной инсталляции передается более 250 миллионов сообщений

ежедневно.

Существует всего несколько протоколов, способных согласовывать обновления,

удаления и синхронизацию данных, хранящихся в различных базах данных на раз-

ных системах. В смешанных средах трудно обеспечить упорядоченность; для их ин-

теграции часто требуются сложные программы.

Очереди сообщений и управляющее ими программное обеспечение, такое как

IBM WebSphere MQ для z/OS, позволяют осуществлять межпрограммную связь. В кон-

тексте оперативных приложений обмен сообщениями (messaging) и управление оче-

редями (queuing) можно понять следующим образом:

• Обмен сообщений подразумевает, что программы общаются посредством пе-

редачи друг другу сообщений (данных), а не посредством прямого обращения

друг к другу.

• Управление очередями подразумевает, что сообщения помещаются в очереди,

расположенные в памяти, так что программы могут выполняться независимо

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

расположение и без логической связи между ними.

152 Синхронная связь

На рис. 16.1 показан базовый механизм межпрограммной связи с использованием

модели синхронной связи.

Программа A готовит сообщение и помещает его в Очередь 1. Программа B полу-

чает сообщение из Очереди 1 и обрабатывает его. И Программа A, и Программа B

используют интерфейс программирования приложений (API) для помещения сооб-

щений в очередь и получения сообщений из очереди. WebSphere MQ API называется

интерфейсом очередей сообщений (Message Queue Interface, MQI).

Когда Программа A помещает сообщение в Очередь 1, Программа B может быть

еще не запущена. Очередь надежно хранит сообщение до тех пор, пока Программа B

не запустится и не будет готова получить сообщение. Подобным образом в то время,

 Обменсообщениямииуправлениеочередями 417

когда Программа B получит сообщение из Очереди 1, Программа A может уже не ра-

ботать. При использовании этой модели не требуется, чтобы две программы, общаю-

щихся друг с другом, выполнялись одновременно.

Что касается времени ожидания перед продолжением обработки Программой A,

это является вопросом проектирования. Такая структура может быть желательной

в некоторых ситуациях, однако слишком долгое ожидание в любом случае является

нежелательным. Для разрешения такой ситуации разработана асинхронная связь.

MQI

Очередь 2

Очередь 1

Рис 151 Модельсинхронногоприложения

153 Асинхронная связь

При использовании асинхронной модели Программа A помещает сообщения в Оче-

редь 1 для обработки Программой B, тогда как получением и обработкой ответов из

Очереди 2 занимается Программа C, работающая асинхронно относительно Про-

граммы A. Обычно Программа A и Программа C являются частью одного приложения.

Алгоритм работы представлен на рис. 15.2.

Асинхронная модель является естественной для WebSphere MQ. Программа A мо-

жет продолжать помещать сообщения в Очередь 1 и не блокируется необходимостью

ожидать ответа на каждое сообщение. Она может продолжать помещать сообщения

в Очередь 1 даже при отказе Программы B. В этом случае Очередь 1 надежно сохра

нит сообщения до перезапуска Программы B.

В одной из разновидностей асинхронной модели Программа A может поместить

последовательность сообщений в Очередь 1, затем может продолжить выполнение

418 Глава15

других задач, после чего возвратиться для получения и обработки ответов. Свойство

WebSphere MQ, состоящее в том, что взаимодействующие приложения не должны

быть активными одновременно, называется независимостью от времени (time inde-

pendence).

MQI

Очередь 2

Очередь

Рис 152 Модельасинхронногоприложения

154 Типы сообщений

WebSphere MQ использует четыре типа сообщений:

Датаграмма Сообщение,длякоторогонеожидаетсяответ

Запрос Сообщение,длякоторогозапрашиваетсяответ

Ответ Ответнасообщение-запрос

Отчет Сообщение,описывающеесобытие,такоекаквозникновениеошибкиилиподтверждение

полученияилидоставки

155 Очереди сообщений и менеджер очередей

Очереди сообщений используются для хранения сообщений, отправленных про-

граммами. Они определяются как объекты, принадлежащие менеджеру очередей.

Когда приложение помещает сообщение в очередь, менеджер очередей обеспечи-

вает для этого сообщения:

 Обменсообщениямииуправлениеочередями 419

• безопасное хранение;

• восстанавливаемость;

• однократную доставку целевому приложению.

Это истинно, даже если сообщение необходимо доставить в очередь, принадле-

жащую другому менеджеру очередей; это свойство WebSphere MQ называется гаран-

тированной доставкой (assured delivery).

1551 Менеджер очередей

Компонент программного обеспечения, владеющий и управляющий очередями, на-

зывается менеджером очередей (queue manager, QM). В WebSphere MQ менеджер

очередей сообщений называется MQM; он обеспечивает обмен сообщениями прило-

жений, размещение сообщений в соответствующих очередях, перенаправление со-

общений другим менеджерам очередей и обработку сообщений через общий интер-

фейс программирования Message Queue Interface (MQI).

Менеджер очередей может сохранить сообщения для последующей обработки

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

пор, пока через MQI не будет получен ответ об успешном завершении.

Между менеджерами очередей и менеджерами баз данных есть некоторые сход-

ства. Менеджеры очередей владеют и управляют очередями подобно тому, как менед-

жеры баз данных владеют и управляют своими объектами хранения данных. Они

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

безопасность, авторизацию, восстановление и администрирование.

Однако есть и важные различия. Базы данных разработаны для долгосрочного

хранения данных с использованием эффективных механизмов поиска, тогда как

очереди не имеют такого предназначения. Сообщение в очереди обычно указывает

на незавершенность бизнес-процесса; оно может представлять неисполненный за-

прос, необработанный ответ или непрочитанный отчет. На рис. 15.4 представлен ал-

горитм работы в менеджерах очередей и менеджерах баз данных.

1552 Типы очередей сообщений

Существует несколько типов очередей сообщений. В этой книге чаще всего исполь-

зуются следующие:

• Локальная очередь.

Очередь является локальной, если ею владеет менеджер очередей, с которым

связано приложение. Она используется для хранения сообщений программ,

использующих один и тот же менеджер очередей. Приложение необязательно

должно выполняться на одном компьютере с менеджером очередей.

• Удаленная очередь.

Очередь является удаленной, если ее владельцем является другой менеджер

очередей. Удаленная очередь не является реальной очередью; это всего лишь

определение удаленной очереди для локального менеджера очередей. Про-

граммы не могут считывать сообщения из удаленных очередей. Удаленные

очереди связаны с транспортной очередью.

420 Глава15

• Транспортная очередь.

Эта локальная очередь имеет специальное назначение: она используется в ка

честве промежуточного этапа при отправлении сообщений в очереди, принад-

лежащие другому менеджеру очередей. Транспортные очереди являются про-

зрачными для приложения; другими словами, они используются очередью

инициации менеджера очередей.

Эта очередь представляет собой локальную очередь, в которую менеджер оче

редей записывает (невидимым для программиста способом) триггерное сооб-

щение при возникновении определенных условий в другой локальной очере-

ди, например, при помещении сообщения в пустую очередь сообщений или

в транспортную очередь. Два приложения WebSphere MQ осуществляют мони

торинг очередей инициации и чтение триггерных сообщений: триггерный

монитор и инициатор каналов. Триггерный монитор (trigger monitor) может

запускать приложения в зависимости от сообщения. Инициатор каналов

(channel initiator) начинает передачу между менеджерами очередей.

• Очередь недоставленных сообщений.

Менеджер очередей (QM) должен быть способен обрабатывать ситуации, когда

он не может доставить сообщение, например:

если целевая очередь заполнена;

если целевая очередь не существует;

если запись сообщения в целевую очередь была запрещена;

если отправитель не имеет полномочий использования целевой очереди;

если сообщение имеет слишком большой размер;

если сообщение содержит повторяющийся последовательный номер сооб-

щения.

При возникновении какого-либо из этих условий сообщение записывается

в очередь недоставленных сообщений (dead-letter queue). Эта очередь опреде

ляется при создании менеджера очередей, и каждый QM должен иметь такую

очередь. Она используется в качестве хранилища для всех сообщений, которые

невозможно доставить.

156 Что такое канал?

Канал (channel) представляет собой логическую линию связи. Диалоговый стиль свя-

зи между программами требует наличия коммуникационного соединения между

каждой парой сообщающихся приложений. Каналы отделяют приложения от базо-

вых коммуникационных протоколов.

WebSphere MQ использует два вида каналов:

• Канал сообщений.

Канал сообщений соединяет два менеджера очередей посредством специаль

ных канальных агентов (message channel agents, MCA). Канал сообщений явля-

ется однонаправленным, содержит два канальных агента (отправитель и полу-

чатель) и коммуникационный протокол. MCA передает сообщения из транс-

 Обменсообщениямииуправлениеочередями 421

портной очереди в линию связи и из линии связи в целевую очередь. Для

двусторонней связи необходимо определить пару каналов, состоящих из от-

правителя и получателя.

• MQI-канал.

MQI-канал соединяет клиента WebSphere MQ с менеджером очередей. Клиенты не

имеют собственного менеджера очередей. MQI-канал является двунаправленным.

157 Как обеспечивается транзакционная целостность

Предприятию может требоваться синхронно обслуживать две или больше распреде-

ленных баз данных. WebSphere MQ предлагает систему, включающую несколько еди-

ниц работы (unit of work), действующих асинхронно, как показано на рис. 15.3.

Запись

Отправка

Точка

синхронизации

Получение

Запись

Точка

синхронизации

Двухфазовая

фиксация

Синхронная

модель

Единица работы

Запись

Помещение

Syncpoint

Единица работы 1

Единица работы 2

Единица работы 3

Извлечение

Запись

Синхроточка

Асинхронная

модель

Рис 153 Целостностьданных

Верхняя половина рис. 15.3 изображает структуру двухфазовой фиксации тран-

закций (two-phase commit), тогда как система WebSphere MQ, представленная в ниж-

ней половине, работает следующим образом:

• Первое приложение осуществляет запись в базу данных, помещает сообщение

в очередь и создает точку синхронизации для фиксации изменений в двух ресур

сах. Сообщение содержит данные, используемые для обновления второй базы

данных в отдельной системе. Так как очередь является удаленной, сообщение не

идет дальше транспортной очереди в единице работы. При фиксации единицы

работы сообщение становится доступным для извлечения отправляющим MCA.

• Во второй единице работы отправляющий MCA получает сообщение из транс-

портной очереди и отправляет его в получающий MCA в системе со второй

базой данных, и получающий MCA помещает сообщение в целевую очередь.