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

Термин клиент-сервер часто трактуется слишком широко. Под эту категорию на отечественном рынке попадают любые архитектуры, организующие взаимодействие компьютеров в сети. Под нее подходит и схема построения приложений с использованием менеджера записей Btrieve. И даже обычный вариант с файл-сервером и Clipper удовлетворяет этому широкому толкованию. Но в области "тяжелых" проектов архитектурой клиент-сервер принято называть схему построения приложений, обеспечивающую эффективное распределение логики программной системы между различными компьютерами в сети. Каждый элемент компьютерной сети имеет определенный набор параметров, важнейшими из которых являются аппаратные характеристики и набор системного программного обеспечения. Развитая архитектура клиент-сервер позволяет строить приложение так, чтобы у каждого компьютера максимально использовались именно сильные стороны специфических для него характеристик. Как правило, в финансовых системах это достигается трехуровневой схемой приложения (клиент-сервер-СУБД), когда клиентское приложение реализует только пользовательский интерфейс, а бизнес-логика обрабатывается сервером приложения.

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

Кроме того, использование в программе встроенных в базу данных процедур не обеспечивает переносимость программы между различными СУБД.

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

К новой технологии активных агентов фирмы Oracle (неплохой в целом технологии) применимы примерно те же соображения, что и к хранимым процедурам.

Для реализации трехуровневой схемы мы использовали монитор транзакций, позволяющий наиболее полно и гибко строить системы типа клиент-сервер. Общее описание и характеристики такой технологии хорошо представлены в источнике [1]. Для ознакомления с квалифицированным мнением о практической ценности трехзвенной технологии клиент-сервер мы рекомендуем источник [3].

Актуальность этой темы кажется нам очевидной, так как автору статьи известны несколько отечественных крупных проектов в области трехзвенной архитектуры клиент-сервер, в ходе которых создаются особо ответственные приложения, предназначенные для эксплуатации в тяжелом режиме (7х24) сотнями и тысячами пользователями. Некоторые проекты уже успешно завершены, остальные находятся в процессе разработки.

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