Дальнейшая спецификация функций приводит к выделению серверов телекоммуникационных, вычислительных и дисковых (файл-серверов), кэш-серверов. Также есть серверы БД, обрабатывающие множество запросов. Для этого выделяется кластер для обработки SQL-запросов. Здесь четко разделены роли сервера и клиента. Сервер предоставляет ресурсы клиентам, клиентами могут выступать и другие серверы.
Основные принципы архитектуры клиент – сервер: выделенный программный интерфейс, четко определенные протоколы взаимодействия (рис. 6.2). В физически разных местах присутствуют независимо взаимодействующие с одним сервером, не знающие друг о друге клиенты. При этом клиент никак не может определить, сколько еще клиентов взаимодействуют с сервером, протоколы, функции, количество параметров четко определены в описаниях компонентов. На этой основе мы можем независимо постепенно наращивать функциональность клиента и сервера.
Рис. 6.2. Обработка данных СуБД: клиент – сервер
В больших корпоративных сетях есть относительно старые части, которые используют свои средства кодировки шифрования и передачи. Одним из стандартных решений является применение Remote Procedure Call (RPC). Обращение к серверу сводится к вызову функции. Все детали реализации остаются для разработчика сервера неважными, поэтому приложения на основе RPC легко переносятся в среды с открытыми интерфейсами.
Далее речь пойдет о базах данных корпоративных систем, их особенностях и разновидностях. Корпоративные базы данных бывают достаточно разнородными. БД можно назвать приборной доской бизнеса – по ней видны бизнес-успехи, текучесть кадров, динамика движения средств.
Базы данных – неотъемлемая часть информационных систем. В корпорациях уже имеются петабайты данных, и эти объемы растут, удваиваясь каждые пять лет. В корпорациях необходимо распределенное управление БД. В основе подобных технологий лежат распределенные СУБД, основанные на концепции открытых систем. Стандарты взаимодействия в таких системах фиксированы, и имеется возможность масштабируемости и плавного наращивания функциональности. В основе архитектур, которые поддерживают корпоративные информационные системы с базами данных, лежит разделение систем по функциям на клиентскую и серверную части. В развитие этой идеи выделяются специализированные серверы для телекоммуникаций, баз данных, осуществления прикладной логики, шифрования. В связи с такой специализацией традиционная двухзвенная архитектура преобразуется в трехзвенную, в которой выделяются три уровня – презентационная логика, бизнес-логика и логика доступа к ресурсам. В зависимости от балансировки этих трех уровней логики осуществляется дальнейшая конкретизация трехзвенной архитектуры клиент – сервер до моделей с толстым клиентом, тонким клиентом и явным выделением сервера приложений.
Речь идет о больших и сложных БД, поэтому стоит рассмотреть особенности применения архитектуры клиент – сервер к БД. Важно, что явно выделяется приложение клиент – frontend и серверное приложение – backend. Для пользователя, работающего через веб-браузер, все происходит незаметно. Один из примеров графического интерфейса – это банкомат. Ограничения целостности достигаются тем, что БД находятся на сервере. В случае заказа билетов через терминал речь идет о возможности покупки билета на одно и то же место. Здесь есть достаточно важный ряд вопросов и ограничений. Эти ограничения стоит хранить как можно ближе к серверу, производящему общение с базой данных, при этом запросы будут обрабатываться существенно быстрее.
Преимущества лучших черт предыдущих архитектур обеспечивают централизованное администрирование, в том числе и баз данных, безопасность, надежность и отказоустойчивость и файл-серверов, обеспечивающих достаточно низкую стоимость реализации и распределение обработки данных с использованием клиентских компьютеров. Современные клиентские компьютеры, как правило, достаточно мощные. Вспомним, что Windows Vista налагает серьезные требования на вычислительную мощность и объемы памяти современных компьютеров (1Гб RAM). Ряд ресурсов клиента можно использовать.
Рассмотрим, как осуществляется обработка данных в различных архитектурах. Самый простой, исторически первый подход – персональный компьютер. Здесь все происходит локализованно и достаточно просто. Система управления БД и приложение клиент находятся на одном компьютере. В корпоративных системах такое невозможно, поскольку, во-первых, объемы данных исчисляются петабайтами, во-вторых, консолидированные отчеты требуют сбора данных из большего количества компаний из разных стран. Локальные приложения для корпоративных приложений неприменимы.