Файл: Варианты архитектуры клиент-сервер (Стандартизация).pdf

Глава I. Основные понятия клиент-серверной архитектуры.

1.1 Двухуровневая модель

Использование двухзвенной архитектуры клиент-сервер, подразумевает организацию сети и выполнение каким-либо компьютером в ней роли сервера. Компания Gartner Group предлагает следующие варианты двухзвенной архитектуры:

Рис.1. Варианты двухзвенной архитектуры по Gartner Group

Основные модели взаимодействия клиента и сервера в рамках двухзвенной архитектуры:

• файл-сервер — доступ к удаленной базе данных и файловым ресурсам;
• сервер терминалов — распределенное представление данных;
• сервер базы данных — удаленное представление данных;
• сервер приложений — удаленное приложение.

Первой была реализована модель сервера терминалов. Она базировалась на мэйнфрейме, выступавшего в роли сервера, с подключенными терминалами. Пользователи выполняли ввод данных с периферийный устройств (клавиатуры терминала, устройства считывания перфокарт или перфоленты), которые затем передавались на мэйнфрейм и там выполнялась их обработка, включая формирование «картинки» с результатами. Эта «картинка» и возвращалась пользователю на экран терминала или на принтер.

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

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

Вся тяжесть вычислительной нагрузки при доступе к БД ложится на приложение клиента, так как при выдаче запроса на выборку информации из таблицы вся таблица БД копируется на клиентскую машину и выборка осуществляется на клиенте. Таким образом, очень не оптимально расходуются ресурсы и сервера и клиентской машины. В результате возрастает сетевой трафик и увеличиваются требования к аппаратным мощностям пользовательского компьютера, так как базы данных могут содержать в себе таблицы с большим объемом данных, что приводит к переполнению оперативной памяти локальных станций, к переполнению места на диске для временных файлов базы данных. Для решения данной проблемы, был разработан подход, работающий с отдельными строками (записями) или участками таблицы, а не со всей таблицей целиком.

---

В файл-серверной архитектуре, под базой данных зачастую понимался набор слабо связанных таблиц, и изменения в них можно было вносить из инструментальных средств (например, из Database Desktop фирмы Borland для файлов Paradox и dBase). Все это говорит о низком уровне безопасности с точки зрения внесения ошибочных изменений.

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

С проектированием и выходом на рынок специализированных СУБД появилась возможность реализации другой модели доступа к удаленной базе данных — сервера баз данных. При такой архитектуре решения, система управления базой данных запускается на сервере, прикладная программа на клиенте, а протокол обмена описан языком SQL (Structured Query Language). Такой подход к архитектуре, в сравнении с файл-серверным, уменьшает загрузку локальной сети. Также, унифицируется интерфейс между клиентом и сервером. Однако, сетевой трафик остается достаточно высоким, кроме того, по прежнему невозможно удовлетворительное администрирование приложений, поскольку в одной программе совмещаются различные функции.

С разработкой и внедрением на уровне серверов баз данных механизма хранимых процедур появилась концепция активного сервера БД. В этом случае часть функций прикладного компонента реализованы в виде хранимых процедур, выполняемых на стороне сервера. Остальная прикладная логика выполняется на клиентской стороне. Протокол взаимодействия — соответствующий диалект языка SQL. Преимущества очевидны:

• возможно централизованное администрирование прикладных функций;
• снижение стоимости владения системой (TOC, total cost of ownership) за счет аренды сервера, а не его покупки;
• значительное снижение сетевого трафика (т.к. передаются не SQL-запросы, а вызовы хранимых процедур).

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

1.2 Многоуровневая архитектура

---

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

Проблемы двухзвенной архитектуры следующие:

• при тонком клиенте возникают проблемы с производительностью и масштабируемостью системы;
• при толстом клиенте возникают проблемы с управляемостью системы;

Поэтому следующий шаг очень логичен, хоть и появился не сразу:

• Представление (отображение) данных, обработка действий пользователя остается на стороне клиентского приложения;
• Логика работы системы (бизнес-логика) остается на сервере приложений;
• Работа с данными отдается СУБД.

Таким образом каждый слой остается независимым и легко разделяемым между инфраструктурой. Клиентскому приложению остается небольшая часть функций и можно рассматривать (а в настоящий момент не иметь web-интерфейс считается моветоном) web-браузер в качестве клиента. Клиентская часть не знает о том, сколько и каких серверов обрабатывает ее запросы или хранит данные за отображением которых она обращается. Например, клиент может находиться в Европе, а данные которые он запросит могут легко находиться в ЦОДе через океан. Сервер приложений тоже не знает, сколько физически серверов будет обрабатывать и хранить данные за которыми он обращается. Для него это логическая прослойка “Сервер базы данных” к которой будут направлены его запросы.

Многие информационные системы сейчас сохранили “толстого” клиента, но это скорее для сохранения “обратной совместимости” или необходимости проведения интенсивных вычислений или визуализации на клиентском компьютере (например CAD/CAM системы). Некоторые крупные информационные системы имеют только web-интерфейс, например NetSuite. Одна из крупнейших платформ имеет в своем составе множество отраслевых решений, имеет только web-интерфейс и предоставляется только по модели SaaS.

Преимущества подобного архитектурного подхода трудно переоценить, но конечно есть и недостатки:

• большая сложность разработки информационной системы, а следовательно и большая стоимость в том числе и стоимость поддержки и развития;
• низкие требования к клиентскому “железу” формируют высокие требования к инфраструктуре сервера приложений и сервера баз данных, а следовательно к их стоимости;
• также низкие требования к каналу связи между клиентом и сервером приложений, формируют требования к высокопроизводительному каналу связи между сервером приложений и сервером баз данных, а следовательно к стоимости их реализации и поддержки.

---

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

Почему же так долго системы эволюционировали до казалось бы столь ясного и логичного подхода к архитектуре? Во первых необходимо сюда отнести инерцию человеческого мышления. Во вторых трудозатраты на разработку двухзвенной и трехзвенной архитектуры могут отличаться на порядки, а в самом начале и отличались ввиду полного отсутствия стандартизации, готовых фрейворков разработки и собственно сами языки программирования не давали такой широкой возможности. Она появилась наверное только с распространением объектно-ориентированных языков программирования. Отсутствие стандартов в данных областях, подразумевало, что каждый будет выдумывать свои протоколы общения между СУБД и сервером приложений (например). Современные платформы для построения информационных систем такого уровня могут использовать в качестве СУБД, например, Oracle, IBM DB2, MS SQL Server, PostgreSQL Server, что называется “из коробки”. Языки программирования, например C#, Java, имеют готовые фреймворки для работы с СУБД. Методология программирования также стандартизировала паттерны проектирования, например, MVC - Model, View, Controller. Где, Model - данные, View - отображение, Controller - отражает действия пользователя из View в Model. При этом бизнес-логика приложения может находиться как в Model, так и в Controller.

Требования к распределенным системам можно свести в следующий перечень:

• Локальность автономии. Это означает, что функционирование данного узла сети управляется этим узлом и не зависит от функционирования другого узла сети. Под локальной автономией подразумевается также, что все узлы сети рассматриваются как равные.
• Непрерывность функционирования. Подразумевается, что даже в случае неисправности отдельного узла работа системы продолжается, хотя и на более низком уровне.
• Независимость от расположения. Пользователям не следует знать, в каком физическом месте хранятся данные, наоборот, с логической точки зрения пользователям следует обеспечить такой режим, при котором создается впечатление, что все данные хранятся на их собственном локальном узле.
• Независимость от аппаратного обеспечения и операционной системы. Данные должны интегрироваться на компьютерах с различными техническими характеристиками, архитектурами и операционными системами, чтобы для пользователя создавалось представление единой системы.
• Независимость от сети. Система должна поддерживать не только узлы с разным аппаратным обеспечением и разными операционными системами, но и разные типы сетей.
• Независимость от СУБД. Различные СУБД на различных узлах сети должны быть интегрируемы друг с другом.

---

Глава II. Современные реализации клиент-серверной архитектуры

2.1 Стандартизация

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

Таким образом, мы приходим к анализу существующих распределенных объектных моделей. На настоящий момент наибольшей проработанностью отличаются COM/DCOM/ActiveX и CORBA/DCE/Java. И COM, и CORBA — современные программные технологии, которые могут быть использованы для создания крупных корпоративных систем.

CORBA (Common Object Request Broker Architecture) — это набор открытых спецификаций интерфейсов, определяющий архитектуру технологии межпроцессного и платформонезависимого манипулирования объектами. Разработчиками данных интерфейсов являются OMG и X/Open.
Реализовать технологию в соответствии со спецификациями может кто угодно.

Рис. 2. Модели COM и CORBA

Функции CORBA и COM — это функции промежуточного программного обеспечения объектной среды. Для того чтобы обеспечить взаимодействие объектов и их интеграцию в цельную систему, архитектура промежуточного уровня должна реализовать несколько базовых принципов.

• Независимость от физического размещения объекта. Компоненты программного обеспечения не обязаны находиться в одном исполняемом файле, выполняться в рамках одного процесса или размещаться на одной аппаратной системе.
• Независимость от платформы. Компоненты могут выполняться на различных аппаратных и операционных платформах, взаимодействуя друг с другом в рамках единой системы.
• Независимость от языка программирования. Различия в языках, которые используются при создании компонентов, не препятствуют их взаимодействию друг с другом.

---