Текст книги "Основы проектирования корпоративных систем"

Самое простое, что можно применить, – это файл-сервер. Есть выделенный компьютер-клиент и другой выделенный компьютер (файл-сервер), возможно, в другом сегменте локальной сети. Файл-сервер хранит исключительно данные. Например, на нем могут храниться документы для коллективной работы с ними. У клиента есть приложение СУБД, текстовый редактор или редактор таблиц, с помощью которых он взаимодействует с этими данными. При этом клиентов может быть довольно много. Пересылка данных осуществляется по каналам локальной сети. Все остальное, кроме данных, нужно устанавливать на клиентские машины заново. Бизнес-логика, СУБД находятся у клиента. Это невыгодно для больших нагрузок и интенсивностей SQL-запросов. Возможно долгое ожидание сервера, если вычисления осуществляются на клиенте. Магистраль тоже может быть перегружена. Для разгрузки магистрали и нагрузки сервера используется клиент-серверная архитектура. Таким образом мы избавляемся от долгой и дорогостоящей настройки СУБД на каждом клиенте. СУБД находится на сервере и взаимодействует с данными на этом или другом сервере. Логически обращение происходит всегда к одному серверу. На клиенте находится только приложение (логика). Таким образом, сервер становится существенным звеном. Магистраль разгружается. Клиент становится более специализированным и дешевым. Обработка данных становится эффективнее, и количество пользователей можно увеличить. При этом в явном виде можно выделить сервер базы данных как особый уровень (рис. 6.3).

Рис. 6.3. Обработка данных СуБД: файл-сервер

Возможности, характерные для данной архитектуры таковы: во-первых, явно присутствуют клиентская и серверная части; во-вторых, сервер БД отвечает за хранение данных и предоставление доступа к БД. Общая база данных хранится на сервере и доступна всем пользователям ЛВС. Таким образом, клиент получает согласованные данные, доступные всем пользователям, хранение удешевляется, а доступ к БД становится распределенным. Отдельные фрагменты БД могут храниться на разных компьютерах в одном узле ЛВС.

Запрос на доступ к данным инициируется клиентской частью. Все клиент-серверное взаимодействие строится на стандартах. В данном случае используется язык SQL – язык структурных запросов к БД со стандартами от 1992 г. и более поздний стандарт ANSI. Они позволяют инкрементально наращивать функциональность и обеспечить взаимодействие БД, созданных разными производителями (Microsoft, Oracle). Под SQL-сервером понимается логическое имя, возможно группа компьютеров или кластер со стандартным интерфейсом в виде языка SQL. При этом в идеале любой SQL-клиент совместим с любым SQL-сервером. Если вернуться к схеме взаимодействия клиента и сервера БД, то можно видеть, что на сервер приходится большая нагрузка. В связи с этим SQL-сервер является не только центральным звеном системы БД, но и наиболее ответственным и важным звеном, узким местом всей системы, несмотря на то, что клиент сам по себе достаточно мощный. Если клиент может взять на себя часть функций прикладной логики, то он должен ее на себя взять. В этом и состоит перспектива систем управления БД – гибкая балансировка нагрузки между клиентом и сервером.

Исторически первым методом организации клиент-серверного взаимодействия была RPC. Эта архитектура значима и сегодня. На довольно низком уровне можно обеспечить распределение нагрузки. Некоторые компоненты могут располагаться на клиенте. Если ЛВС вычислительно неоднородна, то взаимодействие на уровне процедурных сервисов позволяет скрыть неоднородность сети. При этом снижается значимость аппаратной совместимости. Часть парка аппаратного обеспечения может быть заменена без критического влияния на важные системы. Принцип открытых систем сглаживает подобные неровности инкапсуляцией функциональности на прикладном уровне процедур приложений. Если говорить о SQL-сервере, то функциональное разделение производится следующим образом. СУБД работает на стороне сервера, на стороне клиента организуется лишь инициирование запросов к SQL-серверу. Вся работа по формированию запросов, обработке данных, организации транзакционного многопользовательского взаимодействия осуществляется на стороне сервера. Ряд запросов носит типовой характер. Результат этих запросов стоит кешировать в ОЗУ на сервере. Таким образом возникает возможность хранения кэша на выделенном сервере. Если клиент использует одни и те же запросы, стоит кешировать БД на локальной машине. Так можно моделировать работу сервера на клиенте и осуществлять ряд операций по обработке данных локально. В отличие от традиционной клиент-серверной архитектуры мы получаем распараллеливание и балансировку прикладных функций между клиентом и сервером. Прежде чем обсудить трехзвенную архитектуру, поговорим об особенности архитектуры сервера баз данных.

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

Рассмотрим основы многопроцессорной и многопоточной архитектуры. При каждом сеансе связи пользователя с сервером осуществляется создание нового экземпляра приложения (Oracle). При этом преимуществом является масштабируемость, что требует большого объема памяти. Многопоточный подход (Microsoft, Sybase) заключается в том, что на один экземпляр приложения запускается несколько потоков, это требует меньше ресурсов. При многопроцессорном подходе ОС ориентируется на разделение времени между экземплярами приложений, при каждом соединении создается новый процесс.

Вернемся к вопросу о балансировке нагрузки между клиентом и сервером. Речь идет о выделении третьего уровня прикладной логики. Верхний уровень, связанный с логикой работы приложения, расщепляется на два. Трехуровневая архитектура включает в себя презентационную логику (PL), бизнес-логику (BL) и логику доступа к ресурсам (AL). BL можно размещать как на сервере, так и на клиенте, а также выделить на отдельный сервер, тогда появляется понятие сервера приложений. Тонкий клиент – легкий клиент с презентационной логикой, например браузер. Толстый клиент (remote data access, RDA) объединяет бизнес-логику и презентационную логику. Сервер приложений можно выделить в отдельный программный уровень.

Под толстым клиентом (RDA) понимается объединение на клиентской части логики, связанной с презентацией, и бизнес-логики. Только логика доступа к ресурсам оставлена на сервере (рис. 6.4).

Рис. 6.4. Модель трехуровневой архитектуры клиент – сервер: толстый клиент

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

Рис. 6.5. Модель трехуровневой архитектуры клиент – сервер: тонкий клиент

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

Рис. 6.6. Модель трехуровневой архитектуры клиент – сервер: сервер приложений

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

Толстые клиенты преимущественно распространены в системах, не требующих частой коррекции. Если часть бизнес-логики переносится на логический сервер, выделяется уровень приложений (Application Layer, AL). При этом на сервере БД работает только та часть бизнес-логики, которую можно вынести в бизнес-правила уровня предприятия или целой группы логически связанных прикладных программ. Тонкие клиенты работают на компьютерах пользователей, сервер БД освобождается от бизнес-логики и работает только на передачу данных серверу приложений и пользователям. Реализация сервера приложений может быть как в виде SQL-сервера, так и в виде персональной СУБД.

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

При использовании тонкого клиента вся бизнес-логика, которая была сосредоточена на каждом из сотен тысяч клиентов, переносится на сервер и централизованно управляется там. Она взаимодействует с данными и SQL-серверами. Клиент снабжается только пользовательским интерфейсом. Администрирование и централизованная миграция производятся на сервере, поэтому изменения с точки зрения сроков и стоимости происходят более эффективно. Бизнес-логика может быть расположена на одном и том же сервере с БД, а может быть перенесена на один или несколько серверов. Коррективы в таких системах можно вносить как на нижнем уровне, так и на более высоком. Например, в семействе Oracle Applications на нижнем уровне расположен сервер базы данных Oracle Server, а на более высоком уровне существует Application Server, на котором и располагаются все компоненты, выполняющие прикладные задачи. Это ERP-системы Oracle Applications или Oracle Business Suit, которые осуществляют прикладную логику: учет, планирование и управление основными видами корпоративных ресурсов.

Для производства корпоративных приложений нужно эффективно пользоваться специализированными инструментальными средствами, которые этот цикл поддерживают. Речь идет о средствах автоматизированного проектирования корпоративных приложений, или CASE-средствах. При этом если говорить о базах данных, необходимы специфические CASE-средства. В чем же заключаются эти особенности применительно к распределенным системам клиент-серверного типа? Эти средства являются достаточно универсальными, так как обеспечивают возможность соединения с различными серверами БД и позволяют разрабатывать графические интерфейсы (формы ввода данных, отчеты), чтобы пользователи могли взаимодействовать с данными в этих графических интерфейсах. Речь идет о том, что взаимодействие с базой данных может осуществлять не только программист, но и опытный пользователь, системный, бизнес-аналитик. Более того, если правильно построить цикл разработки корпоративной системы, можно обеспечить возможность взаимодействия этого бизнес-аналитика с существующей системой и развитие этой системы бизнес– аналитиком. Он сможет строить в терминах бизнес-логики, почти естественных языковых терминах, необходимые запросы и отчеты. При этом в почти автоматическом режиме происходит соединение с сервером БД, и графический интерфейс во многом набирается из тех примитивов, которые есть в распоряжении такого продвинутого пользователя.

Особенность систем проектирования взаимодействия корпоративных систем с базами данных – это в первую очередь объектная ориентированность. Речь идет о наборе компонентов для взаимодействия с серверами, основанных на технологиях ODBC (Object Database Connectivity), соединении с базами данных на основе объектных технологий либо более старой технологии OLE (Object Linking and Embedding). Кроме того, это визуализация, основанная на объектных библиотеках, средство командной разработки (например, Visual Studio Team System/Team Suit), а также языки четвертого поколения, которые поддерживают возможность написания программ в терминах скрипт-языков или во многом визуальной разработки.

К CASE-поддержке систем с базами данных можно отнести такие средства, как:

• Oracle Developer;

• Borland Delphi;

• MS Visual Studio (MSVS);

• Sybase PowerBuilder.

В Oracle Developer есть расширения для создания веб-приложений Oracle Web Developer, кроме того, также как и в MSVS, в нем может быть использовано подключение к другим базам данных на основе открытых интерфейсов (например, ODBC). Эти средства являются конвейерами для интеграции с различными SQL-серверами.

Средства, поддерживающие разработку персональных СУБД, с которых начинались небольшие системы, – это были, по сути, CASE-средства и серверы базы данных в миниатюре. Они также поддерживают SQL-запросы и разработку бизнес-логики, независимую работу клиентского приложения и в ряде случаев имеют специализированные форматы хранения данных, основанные на специфических СУБД (например, в семействе приложений Lotus на основе Lotus Domino сервера и персональной СУБД Lotus Approach речь может идти о нереляционной БД, многозначной структуре данных, когда речь идет о неатомарных атрибутах в БД). Рассмотрим основы того, из чего выросли современные средства. Атрибутами настольных систем были легкий удобный графический интерфейс, интеграция с пакетами офисных приложений (MS Office в том числе), визуальные средства, которые позволяют вести быстрое построение приложений и отчетов. В MS Access есть набор визардов для экспресс-построения отчетов, и среда реализации основана на объектном подходе (ODBC, COM, OLE). В MS Access можно встроить макросы на Visual Basic, который во многом является объектным. Эти средства хоть и в нестандартном виде используют язык SQL, с помощью которого осуществляется запрос к локальной БД.

Усовершенствование этих средств и выделение явного уровня клиента и сервера привели к появлению определенных особенностей в двух– и трехуровневой архитектурах клиент – сервер.

Если говорить о двухуровневой архитектуре клиент – сервер, можно выделить следующие особенности применительно к сетевым средам Интернет и интранет. Интернет важен для корпоративных сетей. В данном случае мы разделяем уровни веб-браузера и вебсервера. Речь идет о взаимодействии по протоколу HTTP. Сервер предоставляет клиенту HTML-страницу, а браузер отображает страницу, обрабатывая HTML-теги (рис. 6.7).

Рис. 6.7. Двухуровневая архитектура клиент – сервер в сетях Интернет/интранет

При переходе к трехуровневой системе возникает промежуточный слой, связанный с JSP (Java Server Pages) или ASP (Active Server Pages). Промежуточный слой в виде веб-сервера, сервер БД, осуществляющий SQL-взаимодействие с БД, и клиент в виде веб-браузера.

Основные протоколы – HTTP, или HTTPS. Преимуществами являются снижение трафика, большая взаимозаменяемость компонентов за счет стандартных интерфейсов и протоколов, а также увеличение безопасности. Недостаток связан с тем, что HTTP – это протокол без состояния (stateless). В связи с этим сложно организовать транзакционную обработку БД, что крайне важно для систем корпоративного размера, поскольку многопользовательская работа подразумевает транзакционность и изоляцию пользователя. Осуществляется псевдопараллельная работа со сложным управлением транзакциями.

При трехуровневой архитектуре обобщенное взаимодействие между клиентом и сервером выглядит следующим образом (рис. 6.8). Клиент в виде веб-браузера отсылает серверу запрос на доставку веб-страниц, данных в рамках протокола HTTP. Выполняется передача данных в определенном формате. После того как веб-сервер получает запрос на отображение веб-страницы от сервера БД, он передает после перекодирования HTML-страницы клиенту. Вебсервер – это промежуточное звено между клиентом и БД. Он получает от клиента в сыром виде запрос на получение информации и обращается к серверу БД по средствам запросов. Существуют программы расширения серверной части, которая получает от вебсервера запрос на получение данных и общается с сервером БД. Она принимает запрос, переформулирует его на языке SQL и передает его серверу БД. Сервер БД специализируется исключительно на выполнении SQL-запросов. Он выполняет запрос в форме определенного количества записей из БД программе-расширению. После чего происходит передача информации веб-серверу с преобразованием в формат веб-браузера. Затем происходит передача клиенту страницы с результатом. Таким образом, происходит двухуровневое взаимодействие.

В трехзвенном клиент-сервере взаимодействие происходит более сложным образом. Между веб-сервером и источником данных появляется еще один уровень, реализующий прикладную логику на основе программных расширений. Информация в формате HTML от веб-браузера преобразуется к виду, который может быть транслирован в SQL-запрос, который выполняет SQL-сервер. После этого происходит обратное преобразование в HTML и передача его клиенту. Используются программы-расширения CGI-скрипты, API. Основная цель для трехзвенной клиент-серверной архитектуры – за счет взаимодействия по стандартным протоколам осуществить специализацию деятельности компонентов. И за счет этой специализации ускоряется обработка запросов. Отдельно выделяется задача поддержания соединения с БД для минимизации сетевого трафика. Кроме того, для обеспечения масштабируемости необходимо поддерживать резерв в соединении с БД для того, чтобы в пиковый период увеличить нагрузку. Стандартизация компонентов дает возможность инкрементально наращивать функциональность отдельных систем.

Рис. 6.8. Трехуровневая архитектура клиент – сервер в сетях Интернет/интранет

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

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

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

GRID-системы – это системы распределенных вычислений, отличные от традиционных корпоративных СУБД. В ряде корпораций уже есть примеры использования таких систем. Под этим термином понимается глобально распределенная сеть, которая в отличие от корпоративных систем должна обеспечивать очень высокую производительность, дающую возможность обычным компьютерам соперничать в производительности с супер-ЭВМ. В ряде отраслей знания есть потребность хранения и обработки терабайтных объемов данных. Это нужно в биологии для анализа ДНК, в медицине для компьютерной томографии в реальном времени и анализа развития онкологических заболеваний, в геофизике для анализа спутниковых данных об атмосферных явлениях, в астрономии для анализа динамики космических тел, в физике элементарных частиц для анализа данных с ускорителей, в криптографии, вычислениях (константы пи). Характерные скорости поступления информации в таких системах – 100 Мб/с.

Необходима возможность подключения к одной сети множества компьютеров, соединенных оптоволоконными линиями. Для реализации GRID объединяются организации, обладающие высоким потенциалом с точки зрения количества единиц современной вычислительной техники. Примером могут служить ЦЕРН (Европейский центр ядерных исследований) или МИФИ (GRID-центр).

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