О мониторах транзакций и не только о них...

Мне очень приятно, что статья о Tuxedo System была замечена и получила неплохую оценку одного из ведущих, на мой взгляд, специалистов по Oracle в нашей стране - Виталия Витальевича Сиколенко. Было очень интересно познакомиться с доброжелательным, корректным, непредвзятым, но в то же время критичным анализом, данным статье в приведенных выше "Заметках по поводу Tuxedo System". В целом я согласен со многими замечаниями и уточнениями, содержащимися в "Заметках", особенно в отношении качеств и свойств СУБД Oracle. При подготовке статьи я не располагал столь полной информацией о инновациях в Oracle и поэтому хотел бы поблагодарить Виталия Витальевича за уместные и полезные комментарии. Что же касается главной темы нашей дискуссии, касающейся различных аспектов лицензирования СУБД Oracle при использовании мониторов транзакций, то я хотел бы сделать некоторые замечания в отношении оценки, данной В.В. Сиколенко ("неверная информация, вводящая читателей в заблуждение..."), и обосновать свою позицию.

1. Режимы взаимодействия клиента и сервера

Не совсем правильно В.В. Сиколенко понял раздел, посвященный режимам взаимодействия клиента и сервера. Возможность асинхронного общения клиента и сервера - это попросту один из нескольких способов организации их взаимодействия. В репертуар же мониторов транзакций, как правило, включают и другие, более важные режимы взаимодействия: диалоговый (conversational), режим работы с очередями, режим широковещательной рассылки сообщений и ряд их модификаций, примеры которых также были приведены в статье. Сравнивая способы общения клиента и сервера в реляционных СУБД и в мониторах транзакций, мне просто пришлось отметить, что репертуар первых несколько ограничен по сравнению со вторыми. Хотелось подчеркнуть, что это вовсе не недостаток реляционных СУБД, а, скорее, особенности настоящего этапа их развития. Судя по примерам, приводимым В.В. Сиколенко в "Заметках", в СУБД Oracle постепенно расширяется спектр возможностей организации взаимодействия клиента и сервера, и это замечательно. Конечно же, асинхронный режим не рассматривался в статье, как расширение функциональности, привносимое мониторами транзакций по сравнению с реляционными СУБД. Дело не в асинхронном режиме, а во всем наборе режимов взаимодействия клиента и сервера, предоставляемых мониторами транзакций. Вот он, на мой взгляд, как раз и является важным расширением функциональности современных реляционных СУБД.

2. Управление транзакциями

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

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

Несколько слов о канале SQL/Net. Как правильно отмечает В.В. Сиколенко, эта тема вообще-то не относится к управлению транзакциями (напомним, что в статье про SQL/Net все содержалось в разделе "Управление транзакциями"), а эту тему, скорее, уместно рассматривать в контексте организации взаимодействия клиента и сервера. В ней я говорил о типичном устройстве канала SQL/Net, присущем современным реляционным СУБД (отнюдь не имея в виду конкретно Oracle). К сожалению, пока в большинстве из них взаимодействие между клиентом и сервером происходит по-прежнему по схеме "точка-точка". В этом смысле СУБД Oracle является, по-видимому, приятным исключением. То, что в третьей версии Oracle SQL*Net появятся новые возможности, которые ранее были прерогативой мониторов транзакций, лишний раз показывает, в каком направлении идет развитие механизмов сетевого взаимодействия в современных СУБД.

Говоря о закрытом характере канала SQL/Net, я также не имел в виду конкретно Oracle SQL*Net, а подразумевал типичное устройство такого канала в популярных реляционных СУБД (в этом смысле SQL/Net - это не название конкретного продукта, а некоторое обобщение). Отметим, что в моей статье, собственно, ни слова не сказано о закрытости именно SQL*Net. Напротив, мне кажется, что, если в настоящий момент мы имеем возможность работать с полностью открытой - как со стороны клиента, так и со стороны сервера - спецификацией SQL*Net, то это можно рассматривать как огромный прогресс в развитии СУБД Oracle, значительно облегчающий жизнь разработчиков.

Замечания о возможности шифрования данных при передаче между клиентом и сервером. Tuxedo не предлагает никаких особых подходов к криптозащите данных. Просто Tuxedo System обладает полностью открытым API, предоставляющим неограниченные возможности для встраивания легальных, сертифицированных ФАПСИ алгоритмов шифрования данных в процесс взаимодействия клиента и сервера. В статье также утверждалось, что стандартные алгоритмы шифрования, используемые в том числе и в Oracle SQL*Net, вряд ли будут сертифицированы ФАПСИ. На мой взгляд, это утверждение не нуждается в доказательствах. И дело вовсе не в сложности совмещения требований по сертификации с коммерческой тайной фирмы (о чем пишет В.В. Сиколенко), а, как мне кажется, в том, что, как известно, алгоритмы и программные средства шифрования данных в США запрещены для экспорта, а в России - для импорта. Таким образом, в отечественных разработках для государственных структур мы обязаны пользоваться программными средствами шифрования данных, сертифицированными ФАПСИ. Именно поэтому нам приходится выбирать открытые сетевые протоколы прикладного уровня (такие как Tuxedo System ATMI или Oracle SQL*Net).

3. Баланс загрузки

Мне трудно судить о том, можно ли рассматривать баланс загрузки, как функциональность, привносимую мониторами транзакций, если иметь в виду, что аналогичные механизмы встроены в некоторые (думаю, что не во все) современные СУБД. К сожалению, мне очень мало известно о внутреннем устройстве баланса загрузки в СУБД Oracle, поэтому готов согласиться, что сказанные в статье слова об "уникальности" Tuxedo в этом смысле - некоторый перебор. Все же, на мой взгляд, что вряд ли правомерно сопоставлять механизмы баланса загрузки в мониторах транзакций и в СУБД. Несмотря на кажущееся сходство целей (динамическое распределение запросов для оптимизации пропускной способности) имеется масса различий, являющихся следствием разной природы запросов (в мониторах транзакций запрос - это, фактически, несколько модифицированный RPC, а в СУБД - это именно SQL-запрос).

Не совсем ясно, почему В.В. Сиколенко упоминает в этом контексте механизм двухфазной (или двухфазовой) фиксации (или завершения) транзакций, поскольку он не имеет никакого отношения к балансу загрузки. Несмотря на то что в Tuxedo System алгоритм двухфазной фиксации транзакции организован несколько иначе, чем в современных реляционных СУБД, готов согласиться, что в этом контексте мониторы транзакций не привносят ничего принципиально нового. Только с одной оговоркой - они обеспечивают синхронное завершение транзакций, затрагивающих несколько различных менеджеров ресурсов. Это означает, что рамках одной транзакции можно гарантированно обновить данные в базах данных Oracle, Informix, CA-OpenIngres, Sybase и, как это не удивительно, - теперь уже и Microsoft SQL Server.

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

4. Динамическое распределение загрузки

Пример, приведенный в этом разделе, носит, как верно заметил В.В. Сиколенко, иллюстративный характер несмотря на то, что возник он из реальной жизненной задачи. Рабочая схема потребовала бы более детальной проработки, касающейся прежде всего свойств Oracle Parallel Server и учета особенностей его использования в различных режимах. В примере предполагалось (просто в статье об этом не сказано явно), что узлы кластера работают в режиме синхронного тиражирования друг друга. На это как раз и обратил внимание В.В. Сиколенко.

Мне сложно судить, насколько удачным является применение монитора транзакций в данном конкретном случае (Sun SPARCcluster PDB и Oracle Parallel Server). Вообще говоря, мониторы транзакций (не обязательно Tuxedo System) в различных вариантах широко применяются в кластерных архитектурах и вообще в системах высокой готовности. Собственно, создание таких систем - одна из ключевых областей использования мониторов транзакций. Видимо, можно согласиться с тем, что для данного конкретного случая можно подобрать более удачное и технически совершенное решение, опирающееся только на механизмы СУБД Oracle и не требующее привлечения иных программных систем, и я бы с удовольствием обсудил с В.В. Сиколенко такое решение. С другой стороны, вряд ли можно считать разумным использование подхода к построению систем высокой готовности, основанного на применении только механизмов реляционных СУБД (пусть даже таких совершенных, как Oracle).

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

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

Статья [1] была подготовлена компанией The Standish Group и опубликована в марте 1994 года. В ней были систематизированы характеристики мониторов транзакций и подробно рассказано о преимуществах применения технологии мониторов транзакций по сравнению с традиционной технологией реляционных СУБД. Помимо прочего, большой раздел в статье был посвящен "опасной" теме экономии на приобретении лицензии на СУБД, достигаемой при использовании мониторов транзакций. Была даже приведена таблица, в которой конкретно указывалось, сколько можно сэкономить, если использовать пару "монитор транзакций плюс СУБД" вместо только СУБД - как раз те самые 50%, о которых сказано в моей статье. Правда, авторы статьи [1], будучи людьми осторожными, не называли конкретных имен - они говорили о неких "абстрактных" СУБД и мониторах транзакций.

И тем не менее она была замечена и вызвала немалую обеспокоенность производителей СУБД. Некоторые из них срочно внесли в лицензии положение об учете числа подключений клиентов к СУБД в условиях, когда в системе применяются мониторы транзакций или иные программные или аппаратные решения, мультиплексирующие запросы к базам данных. Честно говоря, мне ничего не известно о том, присутствовало ли ранее положение, которое цитирует В.В. Сиколенко, в документе "Global License Terms", или оно было внесено в него именно в те времена. Мне данный документ знаком, еще задолго до написания статьи я внимательно изучил цитируемые фразы. Насколько помню, это было единственное место в документе, где упоминались мониторы транзакций.

Мне кажется, что в этих фразах нет никакого противоречия с практикой применения мониторов транзакций. Действительно, ведь речь идет об одновременных подключениях к базам данных в один момент времени. Пусть у нас имеется система, организованная в соответствии с трехзвенной схемой "клиент - приложение - менеджер ресурсов", причем приложение выполняется под управлением монитора транзакций, который ведает также подключением клиентов. Будем для простоты считать всех клиентов и все процессы однородными - то есть каждый процесс приложения может выполнить любой запрос клиента. Пусть общее число клиентов равно N, а общее число процессов приложения - M, причем M < N. Все процессы приложения имеют по одному подключению к базе данных; будем считать для простоты эти подключения постоянными. Следовательно, мы имеем M одновременных подключений к базе данных и должны оформить лицензию на M подключений. Пусть в какой-то момент запросы к приложению поступили от n клиентов (очевидно, что n < N). Если n < M, и все запросы равномерно распределились (по одному) между процессами приложения, а клиенты получили доступ к базе данных, и лицензия никак не нарушена. Если n > M, то M запросов успешно распределяются между M процессами, а n-M запросов распределяются в очереди к процессам и не выполняются до тех пор, пока не будут отработаны предшествующие запросы, - опять же, лицензия не нарушается.

В чем же причина? Почему все-таки В.В. Сиколенко пишет о нарушении лицензии с юридической точки зрения? На мой взгляд, противоречие состоит в том, авторы "Global License Terms", во-первых, включили в него фразу, смысл которой они до конца не продумали, во-вторых, они не предусмотрели в документе соответствующих технических разъяснений, а ограничились излишне жесткой и несколько противоречивой декларацией. Читаем первую фразу: "Максимальное число устройств ввода, имеющих доступ к программам в любой выделенный момент времени", - все соответствует схеме, приведенной выше, и никакого нарушения лицензии нет. Читаем вторую фразу: "В случае использования мультиплексирующих программных или аппаратных средств это число должно быть определено на входе мультиплексора". Сразу же возникает вопрос - а как определено, каким образом? Если говорить о применении мониторов транзакции в этом контексте, то очевидно, что в каждый конкретный момент времени исполняется только один запрос к базе данных, а все остальные (если они есть) находятся в очереди запросов и не исполняются, следовательно, нет доступа к базе данных. Почему же тогда надо учитывать эти запросы? Где здесь логика?

Если следовать данной фразе напрямую, буквально, то лицензия на Oracle должна определяться так: нужно подсчитать общее число станций в компании, с которых потенциально возможен одновременный доступ к мультиплексирующим средствам, - полученный результат и будет искомым числом. Вряд ли стоит говорить о том, насколько далека эта схема от реальной жизни. На мой взгляд, в настоящий момент имеется некоторое рассогласование юридической и технологической сторон в документах Oracle, и касается оно применения средств мультиплексирования. В этом и заключается причина нашего расхождения во взглядах с В.В. Сиколенко. Еще раз хотелось бы отметить, что я вовсе не берусь ничего утверждать - мне казалось разумным обозначить проблему, задать вопрос, на который пока нет четкого и однозначного ответа.

6. Так нужны ли мониторы транзакций?

Мне бы хотелось сформулировать этот вопрос несколько иначе: "Так нужно ли программное обеспечение промежуточного слоя (middleware), в том числе и мониторы транзакций?" Дело в том, что в своей статье я использовал Tuxedo System в качестве удачного и понятного примера middleware, стараясь дать читателю подробную информацию об этом виде программного обеспечения (данная статья в существенно переработанном виде послужила основой для [5]).

Совершенно согласен с В.В. Сиколенко, что необходимо очень осторожно подходить к оценке тех или иных программных продуктов, аккуратно анализируя их возможности и особенности в контексте конкретных задач. В этом смысле лучшим критерием все-таки остается практика. Я не совсем согласен с В.В. Сиколенко, когда он говорит о преимущественном использовании мониторов транзакций в гетерогенной среде хранения данных. Практика двух завершенных проектов, разработанных и реализованных сильнейшими коллективами разработчиков АКБ ДиалогБанк [2] и Русского Продовольственного Банка [3], [4], свидетельствует о том, что Tuxedo System - продукт многоплановый и многосторонний, и его преимущества могут проявиться в самых различных задачах, начиная от задач управления финансовыми сообщениями и заканчивая созданием автоматизированной банковской системы.

В.В. Сиколенко также прав, говоря об использовании мониторов транзакций для увеличения производительности систем с удаленным доступом клиента к серверу за счет экономии сетевого трафика. Очевидно, что API мониторов транзакций предоставляет здесь больше возможностей, в том числе и за счет работы на уровне транзакций, а не сессий. Безусловно, альтернативой мониторам транзакций, как правильно отмечает В.В. Сиколенко, может послужить продукт Oracle Mobile Agents - и практика подтверждает это. В одном из наших проектов мы рассматривали два варианта реализации удаленного доступа - с помощью Tuxedo System ATMI или с использованием Oracle Mobile Agents.

7. Заключение

Должен согласиться с В.В. Сиколенко, что некоторые оценки, прозвучавшие в моей статье, были излишне категоричными. Видимо, не стоит противопоставлять традиционные подходы к организации взаимодействия клиент-сервер, характерные для реляционных СУБД, и подходы, реализованные в мониторах транзакций. С другой стороны, все же мне очень хотелось бы убедить читателей в необходимости применения middleware (не обязательно мониторов транзакций) в проектах корпоративных информационных систем. На мой взгляд, все те инновации в СУБД Oracle, о которых пишет В.В. Сиколенко, как раз и свидетельствуют о том, что средства сетевого взаимодействия в Oracle становятся все более разнообразными и изощренными и постепенно мигрируют в направлении middleware. Так или иначе, но наша дискуссия могла бы быть продолжена на страницах журнала. Мне кажется, что ее тема является ключевой для судьбы многих широкомасштабных проектов корпоративных информационных систем. Хотелось бы в этом контексте услышать мнения других специалистов в области СУБД и middleware.

Если же моя статья хотя бы в какой-то степени нанесла ущерб бизнесу компании Oracle в России, то я выражаю искреннее сожаление.

Литература

1. The Standish Group. "Client-Server Goes Business Critical Transaction Processing Monitors. Key to Next Generation of Applications".

2. Севрюгин С. "Система обработки финансовых сообщений", # 6, 1996.

3. Москаленко О.М. "Опыт разработки автоматизированной банковской системы в АКБ РПБ". - JetInfo, # 6, 1995.

4. Москаленко О.М. "Опыт проектирования и разработки банковской системы для трехуровневой архитектуры клиент-сервер". - СУБД, # 3, 1996.

5. Ладыженский Г.М. "Tuxedo System - ключевой компонент корпоративных информационных систем". - JetInfo, # 14/15, 1996.