16.Разработка программ в архитектуре «клиент—сервер»
Распространение динамически подключаемых библиотек и ресурсов прикладных программ привело к ситуации, когда большинство прикладных программ стало представлять собой не единый программный модуль, а набор сложным образом взаимосвязанных между собой компонентов. Многие из этих компонентов либо входили в состав ОС, либо же требовалась их поставка и установка от других разработчиков, которые очень часто могли быть никак не связаны с разработчиками самой прикладной программы.
При этом среди всего множества компонентов прикладной программы можно было выделить две логически цельные составляющие: первая — обеспечивающая «нижний уровень» работы приложения, отвечающая за методы хранения, доступа и разделения данных; вторая — организующая «верхний уровень» работы приложения, включающий в себя логику обработки данных и интерфейс пользователя.
Первая составляющая, как правило, представляла собой набор компонентов сторонних разработчиков. Часто она так или иначе была связана с доступом к базам данных, которые могли предусматривать достаточно сложную организацию. Для работы ее компонентов требовалось наличие высокопроизводительной вычислительной системы.
Вторая составляющая включала в себя собственно алгоритмы, логику и весь интерфейс, созданные разработчиками программы. Она требовала наличие связи с методами доступа к данным, содержащимся в первой составляющей. Требования к вычислительным системам, необходимым для выполнения ее компонентов, были обычно существенно ниже, чем для первой составляющей.
Тогда сложилось понятие приложения, построенного на основе архитектуры «клиент—сервер». В первую (серверную) составляющую такого приложения относят все методы, связанные с доступом к данным. Чаще всего их реализует сер-
вер БД (сервер данных) из соответствующей СУБД (системы управления базами данных) в комплекте с драйверами доступа к нему. Во вторую (клиентскую) часть приложения относят все методы обработки данных и представления их пользователю. Клиентская часть взаимодействует, с одной стороны, с сервером, получая от него данные, а с другой стороны — с пользователем, ресурсами приложения и ОС, осуществляя обработку данных и отображение результатов. Результаты обработки клиент опять-таки может сохранить в БД, воспользовавшись функциями серверной части.
Кроме того, со временем на рынке СУБД стали доминировать несколько наиболее известных компаний-производителей. Они предлагали стандартизованные интерфейсы для доступа к создаваемым ими СУБД. На них, в свою очередь, стали ориентироваться и разработчики прикладных программ. Такая ситуация оказала влияние и на структуру систем программирования. Многие из них стали предлагать средства, ориентированные на создание приложений в архитектуре «клиент—сервер». Как правило, эти средства поставляются в составе системы программирования и поддерживают возможность работы с широким диапазоном известных серверов данных через один или несколько доступных интерфейсов обмена данными. Разработчик прикладной программы выбирает одно из доступных средств плюс возможный тип сервера (или несколько воз- : можных типов), и тогда его задача сводится только к созданию клиентской части , ; приложения, построенной на основе выбранного интерфейса. Создав клиентскую часть, разработчик может далее использовать и распространять ее только в комплексе с соответствующими средствами из состава системы программирования. Интерфейс обмена данными обычно входит в состав системы программирования. Большинство систем программирования предоставляют возможность распространения средств доступа к серверной части без каких-либо дополнительных ограничений.
Что касается серверной части, то возможны два пути: простейшие серверы БД требуют от разработчиков приобретения лицензий на средства создания и отладки БД, но часто позволяют распространять результаты работы без дополнительных ограничений; мощные серверы БД, ориентированные на работу десятков и сотен пользователей, требуют приобретения лицензий как на создание, так и на распространение серверной части приложения. В этом случае конечный пользователь приложения получает целый комплекс программных продуктов от множества разработчиков.
Более подробно об организации приложений на основе архитектуры «клиент-сервер» можно узнать в [9, 35, 63].
Разработка программ в трехуровневой архитектуре. Серверы приложений
Трехуровневая архитектура разработки приложений явилась логическим продолжением идей, заложенных в архитектуре «клиент—сервер». Недостатком архитектуры приложений типа «клиент—сервер» стал тот факт, что в клиентской части приложения совмещались как довольно сложные функции,
связанные с обработкой получаемых от сервера данных, так и более про функции организации интерфейса пользователя. Для выполнения этих фун к вычислительной системе должны предъявляться различные требования, и ] случае когда выполняется сложная обработка данных, эти требования со a ны «клиентской» части приложения могут быть непомерно велики. Кроме обработка данных («бизнес-логика» приложения), как правило, изменяете: значительно по мере прохождения жизненного цикла, развития приложен выхода его новых версий. В то же время интерфейсная часть может серьез» доизменяться и в предельном случае подстраиваться под требования конкр< го заказчика.
Еще одним фактором, повлиявшим на дальнейшее развитие архитектуры « ент—сервер», стало распространение глобальных сетей и всемирной сети Инте Многие приложения стали нуждаться в предоставлении пользователю воз] ности доступа к данным посредством сети. Возможностей архитектуры « ент—сервер» для этой цели стало во многих случаях недостаточно, поско клиент зачастую мог не иметь никаких вычислительных ресурсов, кроме граммы навигации по сети (браузера, browser).
Поэтому дальнейшим развитием архитектуры «клиент—сервер» стало раз; ние клиентской части в свою очередь еще на две составляющих: сервер прил ний (английские термины «application server» или «middleware»), реализую обработку данных («бизнес-логику» приложения), и «тонкий клиент» («thin clie обеспечивающий интерфейс и доступ к результатам обработки (далее «toi клиент» будем называть просто «клиентом»). Серверная часть осталась бе: менений, но теперь она получила название «сервер баз данных» («database ver»), чтобы не путаться с сервером приложений.
Разделение клиентской части на две составляющих потребовало организг взаимодействия между этими составляющими. Причем это взаимодействие д( но, с одной стороны, быть достаточно тесным, так как клиент должен выпол отображение получаемых от сервера данных за время с разумной задержкой лательно минимальной); а с другой стороны, он должен допускать обмен да! ми по протоколам, поддерживаемым глобальными сетями. Поэтому появи некоторое число стандартов, ориентированных на организацию такого рода е модействия. Стали появляться новые интерфейсы обмена данными. Среди можно выделить семейство стандартов COM/DCOM, предложенных фир Microsoft для ОС семейства Microsoft Windows [103], а также семейство с дартов CORBA (Common Object Request Broker Architecture), поддержива< широким кругом производителей и разработчиков программного обеспече для большого спектра различных ОС [99]. Детальное рассмотрение такого стандартов и принципов их организации не входит в рамки данного учебногс собия.
Системы программирования в настоящее время ориентируются на поддер средств разработки приложений в трехуровневой (трехзвенной) архитект Средства поддержки тех или иных стандартов сейчас появляются в составе i гих систем программирования [3, 35, 63, 98, 104, 105]. Принципы их использования и распространения аналогичны принципам, применяемым для средств : держки архитектуры типа «клиент—сервер». Следует заметить, что существ
системы программирования, ориентированные на разработку либо клиентской части, либо сервера приложений; и в то же время многие системы программирования стремятся предоставить разработчикам средства для создания обеих частей в трехуровневой архитектуре. Серверная часть (сервер баз данных) в трехуровневой архитектуре по-прежнему чаще всего является продуктом другого разработчика 1 .
Более подробно об организации приложений на основе трехуровневой технологии можно узнать в [2, 35, 63].
Примеры современных систем программирования
В этом разделе пособия ни в коем случае не ставится задача полного описания тех или иных систем программирования, доступных в настоящее время на рынке современных средств разработки программного обеспечения. Полное описание многих из них по объему будет значительно превышать весь материал данного пособия. Автор только дает краткий обзор наиболее известных и распространенных в настоящее время систем программирования с точки зрения их компонентов, ложащихся на общую структуру типовой системы программирования.
Для краткого описания автором были выбраны только самые известные из всего широкого спектра систем программирования, распространенные именно на рынке Российской Федерации. Информация о данных системах программирования дается как на основании соответствующей литературы, так и на основании личного опыта работы автора.
Системы программирования компании Borland/Inprise
Системы программирования компании Borland достаточно широко известны разработчикам в России. Известность и распространенность этих систем программирования определила, прежде всего, простота их использования, поскольку именно в системах программирования этой компании были впервые реализованы на практике идеи интегрированной среды программирования.
Система программирования Turbo Pascal была создана компанией Borland на основе расширения языка Pascal, получившего название Borland Pascal. Отсюда происходит и само название системы программирования.
Сам язык Pascal был предложен Н. Виртом в конце 70-х годов как хорошо структурированный учебный язык. Расширения, привнесенные в язык компанией Borland, преследовали две основные цели:
- упрощение обработки в языке структур, представляющих наиболее распро страненные типы данных — строки и файлы (например, в язык был внесен новый тип данных string);
- реализация в языке основных возможностей объектно-ориентированных язы ков программирования.