Мониторы транзакций и средства транзакционной передачи сообщений

BEA - не родина слонов. Практически каждый из мастодонтов компьютеростроения предлагал или предлагает собственный монитор транзакций и (или) систему организации очередей: Digital - ACMS, DECmessageQ; IBM - IMS, CICS, Encina, TPF и MQSeries; NCR - TopEnd; SGI - Message Passing Library, Cray NQE Workload Management; Tandem - NonStop TS/MP, NonStop TM/MP, Pathway/TS, Pathway/XM; и так далее.

Мониторы транзакций появились ещё на "прапракомпьютерах", а это "терминал-хост", никак не "клиент-сервер" архитектура. Что же делает монитор транзакций? Многопользовательская работа в режиме "хост-терминал" предъявляет известные требования - много, а то и очень много пользователей разделяют память и процессор одной машины. Монитор транзакций в первую очередь призван экономить эти ресурсы, и уже потом - "мониторить транзакции". Монитор не "лучше операционной системы". Он не использует каких-то архиуникальных алгоритмов и планировщиков. Просто использование монитора подразумевает определенный стиль в написании приложений. Вот черты, присущие этому стилю:

• Приложение перестаёт быть монолитным, оно представлено группой сервисов (функций).
• Эти сервисы не вызываются напрямую, как функции или подпрограммы обычного приложения, фактически они вызываются run-time средой монитора, в которую они погружены. "Погружение" осуществляется, как статическая или динамическая линковка со специальными библиотеками.

За счёт чего же достигается экономия ресурсов в этом случае? Вместо того, чтобы создавать каждому пользователю его собственную копию программы, на всех, условно говоря, создаётся единственная, разделяемая. Создаётся такое количество процессов, которое в состоянии обслужить то железо, на котором работает приложение, и не более того. Интерактивные действия пользователя не приводят к немедленному выполнению какого-то прикладного кода. Вместо этого обращение к сервису укладывается в очередь, а вот что произойдёт с этим запросом потом, зависит от степени загруженности системы. Если есть свободный процесс, он обслужит запрос, и задержка будет не очень велика Если нет - запрос будет ждать.

Организация очередей - существенная компонента монитора. Используются два типа очередей: transient - быстрые, так как они находятся в оперативной памяти, но чувствительные к сбоям и притом локальные; и persistent, сохраняющие данные во вторичной памяти и поддерживающие распределённую работу. Монитор транзакций, равно как и, скажем, сервер баз данных, реализует первый тип - приходящие запросы, оформленные в виде блоков данных, должны где-то храниться до того, как их обслужат.

Системы транзакционной обработки очередей и передачи сообщений (transactional messaging queuing, далее - TMQ) реализуют только persistent, однако в некоторых реализованы также и transient. В распределённых конфигурациях TMQ могут реализовывать маршрутизацию, управляемую содержимым сообщения, запуск сервиса и т.п. Для таких мониторов, как IMS, TPF, CICS и Encina TMQ являлся неотъемлемой компонентой. Для других - появился позже самого монитора или поставляется/поставлялся отдельно, как DECmessageQ, Tuxedo /Q или TopEnd RTQ. Продукты TMQ реализуют программный интерфейс типа "положить данные в очередь - забрать данные из очереди". Что скрывает инфраструктура TQM от разработчика - это где, на каком хосте, физически хранятся эти данные.

Подведём черту. Эффективность достигается за счёт того, что исполняющая среда имеет доступ к внутренней структуре приложения. Фактически, монитор реализует нечто похожее на согласованную многозадачность (в противоположность многозадачности с вытеснением), где единицей планирования является сервис. Эффективность достигается за счёт того, что сервисы находятся в постоянной готовности - обслужив одного пользователя, сервис немедленно приступает к обслуживанию другого. Вместо тысячи процессов для тысячи пользователей запускается один-два-сто (идеальной схемой является "один процессор - один процесс" или "одна нить") разделяемых, переключения на уровне операционной системы между которыми (бесполезная с точки зрения прикладной программы работа) сведены к минимуму. Эффективность достигается за счёт того, что пользователи работают с более или менее одинаковыми приложениями (идеальный случай - единственный вид сервиса для всех пользователей). Ведь именно тогда появляется возможность повторного использования сервиса другим пользователем. Монитор хорош только для задач определённого класса. Чем дальше мы от идеальных (для него) случаев, тем меньше резонов им пользоваться.

Вначале был IBM. Отличительной возможностью всех мониторов IBM являются не только TQM, но и встроенное хранилище данных. Так, IMS DB - иерархическая СУБД, а TPFDF, Encina SFS, и CICS transient data (на S390 это VSAM) - файлы записей (а не поток байтов!) с возможностью индексации. И в том, что IBM всегда называл их "серверами приложений", а не "мониторами транзакций", не было подвоха или терминологической путаницы. Любой из них - полная среда, а монитор транзакций - чётко обозначенная внутри неё компонента. Здесь никак не приемлем термин ПО промежуточного слоя ("middleware"). Промежуточного между чем и чем? Всё внутри!

Уже потом мониторы транзакций становятся "связующим ПО". Они связывают разные компьютеры распределённой системы. Они объединяют в единое пространство и разнородные СУБД. Здесь и показывают себя CICS, Encina, TopEnd и Tuxedo, не будучи, в то же самое время в силах вытеснить IMS или TPF, оптимизированных для обработки чудовищного количества транзакций в централизованной конфигурации. Замечу, что к "клиент-серверу" это всё ещё не имеет никакого отношения - и на UNIX штатным клиентом долгое время был алфавитно-цифровой терминал.

Попутно отметим ещё одну очень важную функцию монитора, проявляющую себя, когда он работает на нескольких хостах - это равномерное распределение загрузки между ними, а также перенаправление вызовов на резервный хост в случае отказа основного - борьба с тем, что называется "single point of failure".

Клиент-сервер разрушил весь заведённый порядок вещей. Компьютер с мегабайтом (поначалу) ОЗУ в состоянии выполнять работу локально, и нужны особые резоны, чтобы запускать что-то на сервере. Серверы баз данных сами умеют координировать распределённые транзакции, а также поддерживают хранимые процедуры. Областей, где без мониторов нельзя обойтись, становится всё меньше.

А потом стали появляться визуальные средства быстрого программирования. А что же мониторы? Отсутствие препроцессоров для популярных интегрированных оболочек. Ручное программирование обращений к сервисам. Отсутствие проверки корректности кода на стадии компиляции. Всё это усугубило ситуацию. Какой радости ради надо платить дополнительные деньги и усложнять разработку, возвращаясь в этом смысле на 5 лет назад, так и не имея чёткого ответа на вопрос "зачем вбивать между клиентом и сервером третье звено?"

Мониторы транзакций так и не вышли на массового пользователя, хотя кое-кому, как мы помним, очень хотелось. Мониторы "последней волны" - Encina, TopEnd и Tuxedo - были установлены на 5-6 тысячах серверов каждый, а количество заказчиков измерялось сотнями. Это ничтожно мало, учитывая масштабы компьютеризации на западе.

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

Здесь, правда, надо сделать уточнение. Во времена "последней волны" создан стандарт X/Open Distributed Transaction Processing. Он оговаривал, как прикладной компонент должен взаимодействовать с менеджером транзакций (TX) и как менеджер транзакций должен взаимодействовать с менеджером ресурса (XA), которым в большинстве случаев является сервер баз данных. Менее известны XA+, протокол, по которому менеджер транзакций взаимодействует с менеджером коммуникаций и CSI, по которому с последним общается приложение. Поддержка XA была реализована практически всеми последними модификациями TP-мониторов, а также СУБД "большой четвёрки", "пятёрки" и "шестёрки". XA+ и CSI, насколько мне известно - только в TopEnd. Протокол TX должен был бы помочь обеспечить переносимость приложений, написанных для одного монитора транзакций, на другой, хотя бы на уровне исходных текстов. Однако различия были чересчур радикальны, и такой портируемости не наблюдалось. Именно это я и имел в виду, говоря об отсутствии стандартов. В то же время важность XA несомненна. Если сервер приложений поддерживает XA, то это означает, что он может работать с разнородными ресурсами в распределённой среде.

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

Назад | Содержание | Вперед