Оперативная обработка транзакций (OnLine Transaction Processing — OLTP) — важнейшее средство взаимодействия с информацией, находящейся в внутри «умных» железяк. Между тем, построение сложных, высокопроизводительных OLTP-систем — непростая задача. Многообразие технологий, модные веяния зачастую ставят разработчика в тупик при выборе конкретного решения или заставляют «натягивать» известные технологии на поставленную задачу, что порой ведет к непредсказуемым результатам. Когда в одном проекте фигурирует несколько платформ, задача становится на порядок сложнее.

С точки зрения прикладных задач любая интерактивная система имеет три основных уровня: хранение данных; прикладная логика; представление (интерфейс с конечным пользователем). Соответственно, с точки зрения реализации, система может включать сервер данных, сервер прикладной логики (сервер приложения) и набор интерфейсов для представления информации конечному пользователю. В качестве основы для сервера данных, как правило, используют СУБД SQL-типа, файловые структуры или специальные источники данных. С интерфейсными формами тоже все понятно: можно реализовывать графические интерфейсы, текстовые «зеленые экраны», Web-интерфейсы и т.п. А вот вопрос реализации сервера приложения не так прост, как может показаться на первый взгляд. Если посмотреть на существующие отечественные реализации систем, можно выделить две тенденции:

  • логика размещается вместе с интерфейсами («толстый» клиент);
  • логика размещается на стороне сервера данных (встречается гораздо чаще).

В последнем случае, как правило, используются СУБД SQL-типа, которые наделены некоторыми функциями поддержки сервера приложения в виде механизма хранимых процедур. Трехзвенная схема при реализации трансформируется в двухзвенную клиент-серверную архитектуру. Для небольших систем это вполне приемлемое решение, однако такой архитектуре присущ ряд недостатков, в том числе ограниченная масштабируемость. Ее реализация, даже на мощных платформах класса S/390, позволяет достичь пиковой производительности не более 200 транзакций в секунду [1].

В некоторых реализациях разработчики выделяют сервер приложений в самостоятельный компонент. Но эти реализации, как правило, представляют лишь набор прикладных программ, которые не опираются на какие-либо специальные службы, а пользуются стандартными механизмами операционной системы, что, вообще говоря, не выводит систему на иной качественный уровень по сравнению с двухзвенной архитектурой. Это справедливо практически для любой платформы, за исключением AS/400 и VM/ESA, где сами операционные системы являются транзакционным сервером. На других платформах подобная функциональность может быть достигнута только при помощи дополнительных специальных продуктов, которые в числе прочих и будут затронуты в данной статье.

Мозаика технологий

Рис.1. Мозаика технологий разработки OLTP-систем

Начиная с платформы ПК, используя на начальных этапах технологии Borland и Microsoft, наша компания реализовала несколько проектов в двухзвенной архитектуре. По мере роста размеров проектов, включения в них нескольких платформ, встал вопрос поиска и оптимизации применяемых технологий для построения систем с необходимыми потребительскими свойствами.

Опробовав различные технологии и инструменты, мы остановили свой выбор на технологиях IBM, предоставляющей широкий спектр открытых аппаратно-программных решений. Учитывая, что мы реализуем OLTP-проекты для заказчиков, которые часто уже применяют технологии Microsoft, Oracle и других компании, возможность совместного использования решений IBM и альтернативных поставщиков была весьма кстати (рис. 1).

Для реализации особо тонких системных моментов мы прибегаем также к программированию на языках С++ или Кобол, однако это занимает не более 1-2% от общего объема работ.

Монитор транзакций IBM CICS

Монитор транзакций CICS (Custom Information Control System), имеющий богатую историю, более чем за 30 лет своего существования стал в своей области лидером. Именно программное обеспечение промежуточного слоя является надежным хребтом для построения OLTP-систем.

Монитор транзакций — достаточно сложный продукт, который привносит функции контроля целостности данных при выполнении операций [2,3]. Сложная OLTP-система может иметь несколько источников данных (СУБД, файлы и т.д.); монитор транзакций позволяет прикладной программе работать с ними одновременно и изменять их состояние. При этом, если в рамках транзакции хотя бы один источник данных не будет переведен в последующее состояние, то и остальные источники будут возвращены в состояние до начала транзакции. Это гарантирует целостность данных, предотвращает рассогласование данных в источниках. Такая служба отсутствует в большинстве операционных систем. При этом источники данных могут быть как локальными, так и распределенными, находясь на различных серверах и платформах. Если в системе используется монитор транзакций, то со стороны разработчика не требуется ощутимых затрат для поддержки функций контроля целостности на уровне прикладной логики.

Будучи реализован практически для всех основных платформ, CICS позволяет построить сложную распределенную гетерогенную транзакционную среду. CICS использует интерфейс X/Open XA для взаимодействия с различными менеджерами ресурсов и организации интерфейсов с продуктами основных производителей СУБД. Применение монитора транзакций делает систему более масштабируемой по сравнению решениями, «в центр» которых помещена СУБД. Так, на базе стандартных редакций CICS можно строить системы с пиковой производительностью 500 транзакций в секунду, а при помощи специальных версий (например, ПО Transaction Processing Facility, применяемое в системах оперативного резервирования авиабилетов) и с более высокими пиковыми нагрузками.

Заметим, что TPC, отраслевые тесты на пиковую производительность СУБД (www.tpc.org), проводятся с применением мониторов транзакций, что позволяет получить наилучшие показатели. Почему? Монитор транзакций играет роль «турбонаддува» для СУБД, помимо прочего, ускоряя выполнение SQL-запросов из-за особенностей конструкции как своего ядра, так и интерфейса с СУБД (интерфейс в двухзвенной клиент-серверной архитектуре очень ограничен по производительности). Это позволяет минимизировать время на диспетчеризацию запроса перед его обработкой ядром СУБД. Кроме того, в мониторах транзакций лучше, чем в СУБД, решен вопрос с балансировкой нагрузки [4].

CICS поддерживает пять типов высокоуровневого взаимодействия между серверами, которые могут быть организованы поверх любых сетевых протоколов (TCP/IP, SNA, NetBIOS и др.).

  • Function Shipping (FS). Изменение источников данных (файлов), которые являются удаленными по отношению к локальному серверу CICS. При обращении из транзакции на локальном сервере CICS к такому источнику, он автоматически перенаправляет запрос к тому серверу, который владеет этим источником данных. Обеспечивается целостность данных в случае каких-либо сбоев.
  • Transaction Routing (TR). Перенаправление вызова транзакции между серверами CICS. Можно «переселять» транзакцию с сервера на сервер, при этом требуется лишь переопределить ссылку на сервере CICS без изменения кода программы.
  • Asynchronous Processing (AP). Асинхронный запуск транзакции на другом сервере CICS. Новая транзакция начинает «жить» самостоятельно, а управление немедленно возвращается в вызвавшую транзакцию.
  • Distributed Program Link (DPL). Вызов удаленной транзакции с возвратом управления после окончания работы вызванной транзакции. Этот тип взаимодействия в прикладных системах используется наиболее часто.
  • Distributed Transaction Processing (DTP). Диалог в оперативном режиме двух транзакций, работающих на разных серверах CICS. С точки зрения разработки и отладки это наиболее экзотический и сложный тип взаимодействия.

Все перечисленные типы взаимодействия относятся к синхронному типу: стороны должны быть активны в момент выполнения. Это не всегда удобно в случае распределенных систем с плохими коммуникациями. Для решения этой проблемы необходимо использовать программное обеспечение с асинхронным типом взаимодействия, ярким представителем которого является MQSeries [5].

Транзакционный сервер очередей MQSeries

Концепция работы программного обеспечения промежуточного слоя типа MOM, в частности MQSeries, довольно проста. Прикладная программа кладет некоторую структуру данных (сообщение) в очередь на локальном сервере MQSeries и заканчивает работу. Сохраненное сообщение из локальной очереди передается канальным агентом MQSeries (channel agent) на удаленный сервер MQSeries и сохраняется там во входной очереди. При этом из локальной очереди сообщение удаляется. MQSeries гарантирует транзакционность передачи — сообщение не будет потеряно или передано дважды (это основное преимущество перед почтовыми системами, которые нередко используются для реализации функций распределенной обработки). После получения сообщения на удаленном сервере прикладная программа может прочитать его в любой удобный момент и выполнить необходимые действия; пока приложение не прочтет это сообщение, оно будет храниться в MQSeries.

MQSeries может быть подключен к монитору транзакций CICS наравне с СУБД. В этом случае CICS выступает как внешний координатор транзакций (External Transaction Coordinator — ETC), что исключает ситуации, когда при каком-либо сбое данные в СУБД были изменены, а сообщение не отправлено или наоборот — данные не изменились, а сообщение об изменении было отправлено. Это, в конечном счете, приводит к ситуации рассогласования данных на распределенных узлах OLTP-системы. Использование монитора транзакций позволяет избежать таких ситуаций.

Возглавляя рынок MOM (более 70%), MQSeries дополняет CICS возможностью построения сложной гетерогенной распределенной транзакционной среды с асинхронным типом взаимодействия.

DB2 Universal Database

DB2 [6] — флагманская СУБД корпорации IBM. Ее применение в качестве основы сервера данных OLTP-систем позволяет реализовать сложную обработку данных и хранение больших массивов. Эти функции перекладываются на сервер данных, разгружая сервер приложения. Но если необходимо сделать систему, где хранение и обработка данных не очень сложны, а требования к производительности и минимизации ресурсов выходят на первый план (код ядра СУБД требует значительных ресурсов), то можно использовать файловые структуры, подключенные к транзакционному серверу CICS. Например, многие известные крупные западные OLTP-системы для мэйнфреймов S/390 построены на базе CICS и VSAM.

WebSphere Application Server

Семейство программных продуктов, обозначаемых маркой WebSphere Application Server, включает три версии — Standard, Advanced и Enterprise. Если говорить о поддержке транзакционности, то версия Standard этой службы не имеет, версия Advanced поддерживает службу Java Transaction Service (JTS), равно как и спецификации Enterprise JavaBeans, а версия Enterprise содержит специальные коннекторы для взаимодействия с «полноприводными» транзакционными системами наподобие CICS.

Говоря о WebSphere, часто имеют в виду только Internet-составляющую этого продукта — Application Server [7], мощный кросс-платформный сервер приложений, поддерживающий практически все известные спецификации и протоколы.

В реальных проектах мы избегаем программирования бизнес-логики средствами языка Java, поскольку реализация сервера приложения, например, в формате Enterprise JavaBeans, приводит к значительному снижению производительности приложения и заставляет вести разработку на языке третьего поколения, что менее эффективно по сравнению с инструментарием VisualAge Generator. Однако применение Web-браузеров на рабочих местах дает определенные преимущества для интерактивных систем: не надо платить за дополнительные лицензии для клиентских машин; имеется возможность отображать графическую информацию; нет необходимости копировать приложение по клиентским местам.

Обеспечение соединения браузеров с мощными системами «заднего плана» (back-end) требует применения Internet-серверов. WebSphere Application Server можно рассматривать как своего рода адаптер, который позволяет коду из браузера через вызов сервлета (servlet) обратиться к транзакции в CICS и, получив результат, возвратить его в браузер, создав на ходу интерфейсную HTML-страницу.

Заметим, что для OS/390 поддерживается интерфейс CICS Web Support, посредством которого браузер может напрямую подсоединиться к серверу CICS. Но для унификации архитектуры между платформами и, учитывая, что средство разработки приложений VisualAge Generator строит системы с использованием WebSphere Application Server, мы применяем этот продукт и на S/390. Это помогает решить проблемы переноса кода таких приложений между платформами.

Разработка на VisualAge Generator

VisualAge Generator — средство быстрой разработки приложений. Именно этот продукт является тем «клеем», который позволяет достаточно просто соединить все перечисленные выше технологии в единую картину.

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

Рис. 2. Цикл разработки приложений в классических средах

Цикл разработки приложения средствами VisualAge Generator выглядит несколько иначе (рис. 3). В основе этой среды разработки лежит универсальная виртуальная машина Universal Virtual Machine (UVM), которая является базой для таких сред разработки, как VisualAge for Smalltalk и VisualAge for Java, поверх которых устанавливается VisualAge Generator.

Для запуска и отладки приложения нет необходимости производить компиляцию и сборку приложения. Для отладки работы логики и интерфейсных форм пользуются «малым» циклом (операции 1 и 2), что сокращает время разработки и не требует наличия целевой платформы. В этом цикле производится 80-90% работ и можно обойтись компьютером с Windows NT или OS/2, на котором может быть установлен VisualAge Generator Developer.

После того, как приложение отлажено, можно перейти к созданию кода времени выполнения (runtime) как для серверных, так и для клиентских платформ. При этом целевая платформа нужна только на момент выполнения операции 3. Замечу, что хотя в VisualAge Generator можно создавать приложения любой архитектуры, основное его предназначение — это разработка многоуровневых систем с четким разделением сервера данных, сервера приложения и уровня представления. В качестве клиентских интерфейсов поддерживаются графические, текстовые и Web-ориентированные интерфейсы. Цикл генерации исполняемого кода клиента значительно короче, чем для серверных компонентов. Фактически эта генерация производится в один этап, в результате которого создаются все необходимые компоненты для запуска приложения на клиентской стороне.

В качестве целевой платформы для сервера приложения поддерживаются более 20 платформ, включая CICS и MQSeries. После создания серверного кода времени исполнения его можно отлаживать из среды VisualAge Generator, т.е. проверить работоспособность окончательного кода (большой цикл из операций 3, 4, 5, 6).

В составе VisualAge Generator отсутствуют инструменты для разработки и программирования серверов данных, например, СУБД. Но, имея готовую структуру базы данных, можно автоматически создать всю структуру приложения, включая серверные и клиентские компоненты при помощи средства VisualAge Generator Templates (VAGT), которое входит в поставку. Предопределив некоторые условия, можно автоматически создать практически полную инфраструктуру приложения, что составляет до 80% работ по программированию. Это избавляет разработчика от «ручного» создания таких элементов, как серверные программы, процессы, бизнес-объекты, элементы форм, обработчики исключительных ситуаций и т.д. Учитывая, что в реальных проектах такие элементы исчисляются сотнями и тысячами, VAGT значительно сокращают время создания кода приложения. Далее необходимо лишь наполнить приложения соответствующей бизнес-логикой, которая пишется на языке 4GL.

«Обобщающее обобщение»

На рис. 4 показана общая архитектура распределенной OLTP-системы, которая базируется на описанных технологиях.

Основой системы является CICS (CICS A, например, на платформе Windows NT, CICS B — на платформе S/390). Два этих транзакционных сервера могут взаимодействовать как синхронно (TR, AC, FS, DPL, DTP), так и асинхронно, через MQSeries (менеджеры MQ1 и MQ2 для соответствующих платформ). Менеджеры очередей подсоединены к соответствующим серверам CICS через интерфейс XA. Также к серверам CICS подсоединены различные источники данных (на Windows NT — DB2 и/или СУБД Oracle и Microsoft SQL Server, на S/390 — DB2 и файловые структуры VSAM, которые определены в CICS через Resource Definition Online).

WebSphere Application Server (WSAS) играет роль конвертора вызовов от Web-клиентов к системе «заднего плана» (транзакции P1, P2, P3), написанной на VisualAge Generator.

VisualAge Generator Server (VAGen Srv) — платформнозависимый продукт, необходимый для запуска программ, разработанных на VisualAge Generator.

Возможны прямые соединения с CICS для клиентов с графическим или текстовым интерфейсом пользователя. При этом программы P1, P2 в CICS A могут быть определены как удаленные, тогда их вызовы в CICS A будут автоматически перенаправлены методом TR в CICS B и там запущены. P3 — локальная транзакция в CICS A, которая может посылать сообщения в CICS B через MQSeries.

Надо сказать, что экземпляры CICS, подобные CICS A и CICS B (в CICS их обозначают термином «регион») могут находиться не только на разных машинах, но и на одном сервере или в кластере. Работа регионов изолирована и «падение» одного из них не влияет на работу других. Это так же дает преимущества в масштабируемости, позволяя разделить задачи по регионам с точки зрения специализации. Такой подход наиболее часто практикуется на системах S/390, особенно в кластерах Sysplex. Реальные системы имеют несколько сотен регионов и десятки тысяч транзакций.

Однако сама по себе технология без соответствующих инструментов не дает ожидаемого «выхлопа». Скажем, CICS очень хорош, но если вы попробуете реализовать систему на С++ или Коболе, то это потребует от разработчика бизнес-логики хорошего знания как языка программирования, так и API-интерфейсов CICS, которые сродни API-интерфейсам операционных систем. Масса времени будет потрачена на создание инфраструктурных элементов (описание функций, переменных и т.д.) и отладку такого проекта. Но если взять VisualAge Generator, это избавит разработчика бизнес-логики от необходимости знать CICS, позволив ему сосредоточиться на своих прямых задачах. Конечно, для реализации сложных проектов требуется владение CICS, но это требование уже распространяется не на всех разработчиков, а на двух-трех специалистов, отвечающих за среду выполнения приложения.

«Сплав» технологий и инструментов как раз и дает оптимальный результат; рассмотрение же отдельных продуктов вне системного прикладного контекста для разработчиков сложных не «коробочных» решений не имеет большого смысла. Точно так же мало проку судить о СУБД вне рамок прикладной задачи. Скажем, вы большой поклонник Oracle. Но что делать, если заказчик требует приложение для целевой платформы AS/400? Или у вас большая любовь к DB2, а прикладная система заказчика на S/390 использует VSAM и заказчика полностью устраивает, и речь идет лишь о замене «зеленого» экрана на Web-браузер, чтобы, к примеру, показывать не только алфавитно-цифровые данные.

Реализация OLTP-системы для Внешторгбанка

Сложность этого проекта была не столько в объеме написанного кода (код прикладной логики предоставил заказчик), сколько в знании технической глубины работы различных механизмов транзакционных систем. Этот проект характеризуется как широким спектром платформ и технологий, так и необходимым знанием работы специфических механизмов, необходимым для интеграции с некоторыми готовыми прикладными пакетами.

В качестве центрального узла OLTP-системы используется S/390; возможно использование кластера Sysplex. В качестве «банковской машины» применяется пакет от Altel, реализованный на базе CICS TS, VSAM и имеющий «зеленый» интерфейс формата 3270. Кроме центрального узла банк имеет несколько десятков периферийных узлов, в которых используются серверы AS/400 и Windows NT (рис. 5).

Взаимодействие серверов осуществляется посредством MQSeries. Для того чтобы разработчики прикладной логики были изолированы от механизмов вызова транзакций из серверных процессов, написанных на 4GL в VisualAge Generator, была использована методика и набор программ («оборачивающие» транзакции), при помощи которых можно обращаться к функциям из 4GL. Стремясь унифицировать интерфейсы доступа к данным и снизить расходы на рабочие места, заказчик выдвинул требование использования Web-интерфейсов. При этом работа через Web-браузер должна вестись не по принципу «один к одному», как через терминалы 3270, а через HTML-страницу, создаваемую несколькими экранами 3270. При этом необходимо было обеспечить совместимость с системой безопасности. Все это порождало ряд проблем, которые пришлось решать в комплексе.

Проблема № 1. Для вызова транзакции CICS, которая работает с «зеленым экраном», используется протокол EPI (External Presentation Interface), работающий с потоком 3270. При активизации такой транзакции CICS использует терминальное устройство — структуру, которая идентифицирует соединение и является основным атрибутом для транзакции. Так, эта структура содержит четырехсимвольное поле TERMID (идентификатор терминала), которое используется транзакциями для собственной системы безопасности. Такой тип соединения в CICS называют терминальным.

Однако соединение, которое строится для работы Web-браузера, НЕ является терминальным, т. е. для этого соединения НЕ существует такой структуры (в понимании транзакции 3270), что сразу приведет к сбою выполнения транзакции.

Для вызова транзакций 3270 из нетерминальных соединений или из других транзакций CICS, которые были вызваны через протокол ECI (External Call Interface), в мониторе CICS для OS/390 был реализован механизм, называемый 3270 Bridge. Была добавлена новая команда EXEC CICS START BREXIT и при активизации транзакции 3270 через эту команду, CICS создает специальную структуру, называемую Bridge Facility, так называемый суррогатный терминал, который «предъявляется» транзакции 3270 в момент ее инициализации. Но при создании суррогатного терминала CICS самостоятельно генерирует идентификатор для поля TERMID по своей внутренней логике. Этот сгенерированный TERMID никак не связан с реальным идентификатором пользовательского соединения. Это и порождает проблему № 2.

Команда EXEC CICS START BREXIT не поддерживается и со стороны VisualAge Generator — нельзя установить такие параметры, чтобы он сгенерировал команду вызова, так как она появилась только в последних версиях CICS (начиная с версии 1.3). Для решения этой проблемы на Коболе была написана программа, принимающая необходимые параметры и активизирующая транзакцию через эту новую команду. Это пример использования Кобола как языка третьего поколения для реализации тонких системных функций. Программу на Коболе можно вызывать из прикладных транзакций, написанных на 4GL в VisualAge Generator.

Проблема № 2. Для вызова транзакции 3270 используется механизм 3270 Bridge, который создает суррогатный терминал. Но некоторые поля, включая TERMID, CICS инициализирует сам, никак не привязываясь к клиентскому соединению, из которого вызывается эта транзакция. CICS для каждого такого вызова ставит TERMID в значение из интервала с ?{AAA? по ?{999?, увеличивая его последовательно. Использует стратегию безопасности, которая пришла еще со времен до эпохи SQL — каждому клиенту присваивается для входа через VTAM (Virtual Telecommunication Access Method) восьмисимвольный идентификатор, называемый LU (Logical Unit), который проверяет VTAM. Четыре последних символа из LU берутся для генерации TERMID. Транзакция, отвечающая за идентификацию пользователя, принимает с клавиатуры имя пользователя и его пароль, берет TERMID и смотрит в свой внутренний файл, в котором ищет соответствие имени пользователя и TERMID. Это гарантирует, что данный пользователь может обращаться к системе только с определенного компьютера, так как при конфигурировании SNA-соединения на стороне сервера прописывается и MAC-адрес сетевой платы клиентского компьютера. Но web-соединения идут в обход VTAM и не имеют терминального устройства. Каким образом передавать TERMID или нечто, заменяющее его, чтобы минимизировать переделку транзакций?

Эта проблема была решена путем задействования пользовательской области терминала (Terminal Control Table User Area — TCTUA), нашей собственной транзакции 3270 первичной аутентификации пользователя и инициализации TCTUA, написанной на VisualAge Generator. Это привело к минимизации переделок в транзакции, которая свелась к замене слова ?TERMID? на ?TCTUA? в «кобольных» текстах.

Помимо этого, были проблемы с реализацией вызова последовательности 3270-транзакций в рамках одной 4GL-транзакции с промежуточной обработкой результатов: было необходимо обрабатывать и передавать параметры («экраны») для каждого вызова 3270.

Распределенная OLTP-система с интеграцией унаследованных программ

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

Компания Panasonic использует программу PSI для AS/400 и для Windows NT. При этом на AS/400 программа использовала в качестве структуры данных собственные таблицы и таблицы из ERP-системы J.D. Edwards, работающей на этом сервере. Сервер AS/400 находится в Хельсинки, а серверы NT — в Москве и Киеве, причем связаны между собой не очень надежными линиями. Между тем, логика работы программы PSI должна обеспечивать доставку информации к узлам через сервер AS/400. Существующая версия использовала механизм репликации баз данных, что в условиях плохих линий связи было неприемлемо.

Для решения этой проблемы была предложена модель транспортной системы между серверами на базе MQSeries. При этом не требовалось изменять код существующего приложения PSI, которое отвечало за взаимодействие с конечным пользователем, а предлагалось задействовать триггерные механизмы баз данных. Т. е., на необходимые таблицы «подсаживались» триггеры, которые для каждой операции (вставка, удаление, редактирование) посылали соответствующие сообщения в систему MQSeries. Эти сообщения, попав на AS/400, рассылались во все остальные узлы системы.

Это решение поддерживает использование нескольких баз данных (в среде NT) и библиотек (в среде AS/400) для возможности отладки или других целей. При этом при помощи специальных утилит можно назначить, откуда и куда будут передаваться данные для конкретной таблицы. Набор и структура таблиц в базе данных жестко заданы. Для реализации этого проекта были задействованы как MQSeries и VisualAge Generator, так и программирование на C++. На NT были реализованы триггерные мониторы MQSeries в виде служб NT, а на AS/400 — триггеры DB2.

В данном проекте, на первом этапе, каждая операция в базе порождала одно сообщение с соответствующим кодом операции (I — insert, D — delete, U — update), которое расшифровывалось на удаленных узлах. Но в реальности оказалось, что программа PSI изменяет ключевые поля, что вообще-то не рекомендуется. Это делает невозможным выполнение операции U («изменить») на удаленном узле, так как записи с измененным ключевым полем там еще не существует и СУБД не может ее найти. Вставить в структуру таблиц собственные ключевые поля было нельзя, так как использовались таблицы приложения J.D. Edwards, структуру которых менять нельзя. После анализа ситуации, с тем, чтобы решить проблему с минимальными переделками, было предложено вместо одного сообщения с кодом U соответствующий триггер стал посылать пару сообщений: первое — с кодом D («удалить») и старым значением ключа; второе — с кодом I («вставить») и новым значением ключа.

Эта система пропускает в сутки около 60 тыс. сообщений средней длины около 2 Кбайт. Проект был реализован за 8 недель силами 4 инженеров.

Литература

[1] Masaharu Murozumi, A Challenge To A High Transaction Volume Client/Server DB2 Data Shared OLTP System. IBM, 2000

[2] Г. Ладыженский, Технология «клиент-сервер» и мониторы транзакций. «Открытые системы», 1994, № 3

[3] М. Рузинкевич, А. Цикоцки, Определение и выполнение потоков транзакций. «СУБД», 1995, № 2

[4] E. Cobb, J. Hamilton, G. Sharman, Do I Need A Transaction Processing Monitor and a Database? IBM, 1996

[5] Николай Игнатович, IBM MQSeries: архитектура системы очередей сообщений. «Открытые Системы», 1999, № 9-10

[6] Николай Игнатович, Интеграция технологий управления данными в DB2. «Открытые системы», 2001, № 7-8

[7] P. Wakelin, S. Day, S. Read, F. McKenna, CICS Transaction Gateway V3.1. The WebSphere Connector for CICS. SG24-6133-00, IBM, 2001

Илья Афанасьев (afanasyev@digemp.com) — генеральный директор компании «Диджитал Эмпайр», (Москва).

Основные типы программного обеспечения промежуточного слоя

  • Монитор распределенной обработки транзакций (distributed transaction processing monitor). Контроль выполнения интенсивного потока транзакций в системах оперативной обработки транзакций в многоплатформенной среде.
  • Удаленный вызов процедур (remote procedure call — RPC). Синхронизация взаимосвязи процессов, путем их удаленного вызова. Транзакционность не поддерживается.
  • Взаимосвязь баз данных (database connectivity). SQL-запрос, направленный через это программное обеспечение, может обработаться несколькими СУБД от разных производителей.
  • Обработчик объектных запросов (object request broker — ORB). Обмен программными объектами между различными платформами и по различным протоколам.

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

ПО промежуточного слоя, основанное на передаче сообщений (message oriented middleware — MOM). Асинхронный обмен сообщениями между приложениями, которые могут выполняться на различных платформах. Обмен производится с гарантированной доставкой; при потере соединения операция будет автоматически возобновлена после восстановления.