распределительные системы. Тема_1._Распределенные_системы_и_клиент-серверные_приложения. Тема Распределенные системы и клиентсерверные приложения
 Скачать 0.94 Mb.
|
|
1 Тема 1. Распределенные системы и клиент-серверные приложения Оглавление Принципы построения распределенных систем ......................................................................... 2 Типы моделей «клиент–сервер» в системах баз данных ........................................................... 7 Двухуровневые модели ................................................................................................................. 9 Модель сервера приложений ...................................................................................................... 13 Распределенные системы нужны для повышения производительности (т.е. вычислительной мощности и доступного объема хранимых данных) и надежности отдельных компьютеров. Разделение ресурсов между группой компьютеров позволяет отдельным пользователям получать совместный доступ к ресурсам, гарантируя, что их должно хватить для выполнения крупной текущей задачи. Распределенные системы позволяют достичь высокой производительности с меньшими затратами, чем при построении высокопроизводительной системы на основе одного компьютера, но они гораздо сложнее в реализации и обслуживании. Проектирование распределенных систем имеет много общего с проектированием ПО в общем, но все же следует учитывать некоторые специфические особенности. Существует шесть основных преимуществ распределенных систем: • системы допускают совместное использование как аппаратных, так и программных ресурсов; • возможно расширение системы путем добавления новых ресурсов; • в системах несколько процессов могут одновременно выполняться на разных компьютерах в сети. Эти процессы могут взаимодействовать во время их выполнения; • в системах есть возможность добавления новых свойств и методов; • системы позволяют дублирование информации и устойчивость к некоторым аппаратным и программным ошибкам. Распределенные системы в случае ошибки могут поддерживать частичную функциональность. Полный сбой в работе системы происходит только при сетевых ошибках; • пользователям предоставляется полный доступ к ресурсам в системе, в то же время от них скрыта информация о распределении ресурсов. Распределенные системы обладают и рядом недостатков. Намного труднее понять и оценить свойства распределенных систем в целом, их сложнее проектировать, тестировать и обслуживать. Также производительность системы зависит от скорости работы сети, а не отдельных процессоров. Перераспределение ресурсов может существенно изменить скорость работы системы. Обычно доступ к системе можно получить с нескольких разных машин, сообщения в сети могут просматриваться и перехватываться. Поэтому в распределенной системе намного труднее поддерживать безопасность. Система может состоять из разнотипных компьютеров, на которых могут быть установлены различные версии операционных систем. Ошибки на одной машине могут распространиться непредсказуемым образом на другие машины. Реакция распределенных систем на некоторые события непредсказуема и зависит от полной загрузки системы, ее организации и сетевой нагрузки. Так как эти параметры могут постоянно изменятся, поэтому время ответа на запрос может существенно отличаться от требуемого времени. Из этих недостатков можно увидеть, что при проектировании распределенных систем возникает ряд проблем, которые надо учитывать разработчикам. Ресурсы в распределенных системах располагаются на разных компьютерах, поэтому систему имен ресурсов следует продумать так, чтобы пользователи могли без труда открывать необходимые им ресурсы и ссылаться на них. Примером может служить 2 система URL (унифицированный указатель ресурсов), которая определяет имена Web- страниц. Универсальная работоспособность Internet и эффективная реализация протоколов TCP/IP в Internet для большинства распределенных систем служат примером наиболее эффективного способа организации взаимодействия между компьютерами. Однако в некоторых случаях, когда требуется особая производительность или надежность, возможно использование специализированных средств. Для дальнейшего рассмотрения вопросов проектирования распределенных систем сформулируем основные принципы построения распределенных систем. Принципы построения распределенных систем Построение распределенных систем высокого качества является одной из наиболее сложных задач разработки программного обеспечения. Технологии типа J2EE и .NET создаются как раз для того, чтобы сделать разработку широко встречающихся видов распределенных систем – так называемых бизнес-приложений, поддерживающих решение бизнес-задач некоторой организации, – достаточно простой и доступной практически любому программисту. Основная задача, которую пытаются решить с помощью распределенных систем – обеспечение максимально простого доступа к возможно большему количеству ресурсов как можно большему числу пользователей. Наиболее важными свойствами такой системы являются прозрачность, открытость, масштабируемость и безопасность. Прозрачность (transparency) Прозрачностью называется способность системы скрыть от пользователя физическое распределение ресурсов, а также аспекты их перераспределения и перемещения между различными машинами в ходе работы, репликацию (т.е. дублирование) ресурсов, трудности, возникающие при одновременной работе нескольких пользователей с одним ресурсом, ошибки при доступе к ресурсам и в работе самих ресурсов. Технология разработки распределенного ПО тоже может обладать прозрачностью настолько, насколько она позволяет разработчику забыть о том, что создаваемая система распределена, и насколько легко в ходе разработки можно отделить аспекты построения системы, связанные с ее распределенностью, от решения задач предметной области или бизнеса, в рамках которых системе предстоит работать. Степень прозрачности может быть различной, поскольку скрывать все эффекты, возникающие при работе распределенной системы, неразумно. Кроме того, прозрачность системы и ее производительность обычно находятся в обратной зависимости – например, при попытке преодолеть отказы в соединении с сервером большинство Web-браузеров пытается установить это соединение несколько раз, а для пользователя это выглядит как сильно замедленная реакция системы на его действия. Открытость (openness) Открытость системы определяется как полнота и ясность описания интерфейсов работы с ней и служб, которые она предоставляет через эти интерфейсы. Такое описание должно включать в себя все, что необходимо знать для того, чтобы пользоваться этими службами, независимо от реализации данной системы и платформы, на которой она развернута. Один из основных элементов описания службы – ее контракт. Открытость системы важна как для обеспечения ее переносимости, так и для облегчения использования системы и возможности построения других систем на ее основе. Распределенные системы обычно строятся с использованием служб, предоставляемых другими системами, и в то же время сами часто являются составными элементами или поставщиками служб для других систем. 3 Именно поэтому использование компонентных технологий при разработке практически полезного распределенного ПО неизбежно. Масштабируемость (scalability) Масштабируемость системы – это зависимость изменения ее характеристик от количества ее пользователей и подключенных ресурсов, а также от степени географической распределенности системы. В число значимых характеристик при этом попадают функциональность, производительность, стоимость, трудозатраты на разработку, на внесение изменений, на сопровождение, на администрирование, удобство работы с системой. Для некоторых из них наилучшая возможная масштабируемость обеспечивается линейной зависимостью, для других хорошая масштабируемость означает, что показатель не меняется вообще при изменении масштабов системы или изменяется незначительно. Система хорошо масштабируема по производительности, если параметры задач, решаемых ею за одно и то же время, можно увеличивать достаточно быстро (лучше – линейно или еще быстрее, но это возможно не для всех задач) при возрастании количества имеющихся ресурсов, в частности, отдельных машин. Однако, очень плохо, если внесение изменений в систему становится все более трудоемким при ее росте, даже если этот рост линейный, – желательно, чтобы трудоемкость внесения одного изменения почти не возрастала. Для функциональности же, опять, чем быстрее растет число доступных функций при росте числа вовлеченных в систему элементов, тем лучше. Большую роль играет административная масштабируемость системы – зависимость удобства работы с ней от числа административно независимых организаций, вовлеченных в ее обслуживание. При реализации очень больших систем (поддерживающих работу тысяч и более пользователей, включающих сотни и более машин) хорошая масштабируемость может быть достигнута только с помощью децентрализации основных служб системы и управляющих ею алгоритмов. Вариантами такого подхода являются следующие. Децентрализация обработки запросов за счет использования для этого нескольких машин. Децентрализация данных за счет использования нескольких хранилищ данных или нескольких копий одного хранилища. Децентрализация алгоритмов работы за счет использования для алгоритмов: не требующих полной информации о состоянии системы; способных продолжать работу при сбое одного или нескольких ресурсов системы; не предполагающих единого хода времени на всех машинах, входящих в систему. Использование, где это возможно, асинхронной связи – передачи сообщений без приостановки работы до прихода ответа. Использование комбинированных систем организации взаимодействия, основанных на следующих схемах. Иерархическая организация систем, хорошо масштабирующая задачи поиска информации и ресурсов. Репликация – построение копий данных и их распределение по системе для балансировки нагрузки на разные ее элементы. Частным случаем репликации является кэширование, при котором результаты наиболее часто используемых запросов запоминаются и хранятся как можно ближе к клиенту, чтобы переиспользовать их при повторении запросов. Взаимодействие точка-точка (peer-to-peer, P2P) обеспечивает независимость взаимодействующих машин от других машин в системе. Безопасность (safety) 4 Так как распределенные системы вовлекают в свою работу множество пользователей, машин и географически разделенных элементов, вопросы их безопасности получают гораздо большее значение, чем при работе обычных приложений, сосредоточенных на одной физической машине. Это связано как с невозможностью надежно контролировать доступ к различным элементам такой системы, так и с ее доступностью для гораздо более широкого и разнообразного по своему поведению сообщества пользователей. Понятие безопасности включает следующие характеристики: 1. Сохранность и целостность данных. При обеспечении групповой работы многих пользователей с одними и теми же данными нужно обеспечивать их сохранность (т.е. предотвращать исчезновение данных, введенных одним из пользователей) и в тоже время целостность, т.е. непротиворечивость, выполнение всех присущих данным ограничений. Это непростая задача, которая не имеет решения, удовлетворяющего все стороны во всех ситуациях, – при одновременном изменении одного и того же элемента данных разными пользователями итоговый результат должен быть непротиворечив и поэтому часто может совпадать только с вводом одного из них. Как будет обработана такая ситуация и возможно ли ее возникновение вообще, зависит от дополнительных требований к системе, от принятых протоколов работы, от того, какие риски – потерять данные одного из пользователей или значительно усложнить работу пользователей с системой – будут сочтены более важными. 2. Защищенность данных и коммуникаций. При работе с коммерческими системами, содержащими большие объемы персональной и бизнес-информации, а также с системами обслуживания пользователей государственных ведомств очень важна защищенность как информации, постоянно хранящейся в системе, так и информации одного сеанса работы. Для распределенных систем обеспечить защищенность гораздо сложнее, поскольку нельзя физически изолировать все элементы системы и разрешить доступ к ней только проверенным и обладающим необходимыми знаниями и умениями людям. 3. Отказоустойчивость и способность к восстановлению после ошибок. Одним из достоинств распределенных систем является возможность построения более надежно работающей системы из не вполне надежных компонентов. Однако для того, чтобы это достоинство стало реальным, необходимо тщательное проектирование систем с тем, чтобы избежать зависимости работоспособности системы в целом от ее отдельных элементов. Иначе достоинство превращается в недостаток, поскольку в распределенной системе элементов больше и выше вероятность того, что хотя бы один элемент выйдет из строя и хотя бы один ресурс окажется недоступным. Еще важнее для распределенных систем уметь восстанавливаться после сбоев. Уровни этого восстановления могут быть различными. Обычно данные одного короткого сеанса работы считается возможным не восстанавливать, поскольку такие данные часто малозначимы или легко восстанавливаются (иначе стоит серьезно рассмотреть необходимость восстановления сеансов). Но так называемые постоянно хранимые (persistent) данные чаще всего требуется восстанавливать в их последнем непротиворечивом состоянии. Перед разработчиками систем, удовлетворяющих перечисленным свойствам, встает огромное количество проблем. Решать их все сразу просто невозможно в силу ограниченности человеческих способностей. Чтобы хоть как-то структурировать эти проблемы, их разделяют по следующим аспектам 1. Связь. Организация связи и передачи данных между элементами системы. В связи с этим аспектом возникают следующие задачи: • Какие протоколы использовать для передачи данных. 5 • Как реализовать обращения к процедурам и методам объектов одних процессов из других. • Какой способ передачи данных выбрать – синхронный или асинхронный. В первом случае сторона, инициировавшая передачу, приостанавливает свою работу до прихода ответа другой стороны на переданное сообщение. Во втором случае первая сторона имеет возможность продолжить работу, пока данные передаются и обрабатываются другой стороной. • Нужно ли, и если нужно, то как, организовать хранение (асинхронных) сообщений в то время, когда и отправитель и получатель сообщения могут быть неактивны. • Как организовать передачу непрерывных потоков данных, представляющих собой аудио-, видеоданные или смешанные потоки данных. Заметные человеку прерывания в передаче таких данных приводят к значительному падению качества предоставляемых услуг. 2. Именование. Поддержка идентификации и поиска отдельных ресурсов внутри системы. • По каким правилам присваивать имена и идентификаторы различным ресурсам. • Как организовать поиск ресурсов в системе по идентификаторам и атрибутам, описывающим какие-нибудь свойства ресурсов. • Как размещать и находить мобильные ресурсы, изменяющие свое физическое положение в ходе работы. • Как организовывать и поддерживать в рабочем состоянии сложные ссылочные структуры, необходимые для описания имеющихся в распределенной системе ресурсов. Как, например, находить и удалять ресурсы, ставшие никому не доступными. 3. Процессы. Организация работ в рамках процессов и потоков. • Разделить работы в системе по отдельным процессам и машинам. • Нужно ли определять различные ролей процессов в системе, например, клиентские и серверные, и как организовывать их работу? • Как организовать работу исполняемых агентов – процессов, способных перемещаться между машинами и выполнять свои задачи в любой подходящей среде. 4. Синхронизация. Синхронизация параллельно выполняемых потоков работ требует ответов на следующие вопросы: • Как синхронизовать действия отдельных процессов и потоков, работающих в системе, для получения нужных результатов? • Как организовать работу многих процессов на разных машинах в том случае, если в системе нельзя непротиворечиво определить глобальное время? • Как организовать выполнение транзакций – таких наборов действий, которые надо либо все выполнить, либо не выполнить ни одного из них? 5. Целостность. Для поддержки целостности данных и непротиворечивости вносимых изменений следует выбрать и обосновать: • Способ обеспечения целостности данных. • Модели непротиворечивости. Модель непротиворечивости определяет, на основе каких требований формируются результаты выполняемых одновременно изменений и что доступно клиентам, выполнявшим эти изменения. • Протоколы обеспечения непротиворечивости, создания и согласования реплик и КЭШей, которые следует использовать для выполнения требований этих моделей. 6. Отказоустойчивость. Организация отказоустойчивой работы системы требует определения необходимых процедур и профилей стандартов для решения следующих задач: • Организовать отказоустойчивую работу одного процесса. • Обеспечить надежную связь между элементами системы. • Выбрать и обосновать протоколы, которые следует использовать для реализации надежной двусторонней связи или надежных групповых рассылок. 6 • Выбрать и обосновать протоколы, которые следует использовать для записи промежуточных состояний и восстановления данных и работы системы после сбоев. Одним из достоинств распределенных систем является возможность построения более надежно работающей системы из не вполне надежных компонентов. Однако для того, чтобы это достоинство стало реальным, необходимо тщательное проектирование систем с тем, чтобы избежать зависимости работоспособности системы в целом от ее отдельных элементов. Иначе достоинство превращается в недостаток, поскольку в распределенной системе элементов больше и выше вероятность того, что хотя бы один элемент выйдет из строя и хотя бы один ресурс окажется недоступным. Еще важнее для распределенных систем уметь восстанавливаться после сбоев. Уровни этого восстановления могут быть различными. Обычно данные одного короткого сеанса работы считается возможным не восстанавливать, поскольку такие данные часто малозначимы или легко восстанавливаются (если это не так – стоит серьезно рассмотреть необходимость восстановления сеансов). Но так называемые постоянно хранимые (persistent) данные чаще всего требуется восстанавливать до последнего непротиворечивого их состояния. Организация отказоустойчивой работы требует учета следующих вопросов: • как организовать отказоустойчивую работу одного процесса; • как обеспечить надежную связь между элементами системы; • какие протоколы использовать для реализации надежной двусторонней связи или надежных групповых рассылок; • какие протоколы использовать для записи промежуточных состояний и восстановления данных и работы системы после сбоев. 7. Защита. Для организации защищенности данных и коммуникаций следует рассмотреть следующие технические, организационные и психологические вопросы: • Для организации защиты системы в целом следует определить процедуры проведения работ, обеспечивающих нужный уровень защищенности, и правила соблюдения людьми этих процедур. • Организовать защиту данных от несанкционированного доступа. • Обеспечить защиту каналов связи с двух сторон – воспрепятствовать несанкционированному доступу к передаваемой информации и не дать подменить информацию в канале. • Выбрать протоколы аутентификации пользователей, подтверждения идентичности и авторства. При работе с коммерческими системами, с системами, содержащими большие объемы персональной и бизнес-информации, с системами обслуживания пользователей государственных ведомств очень важна защищенность, как информации, постоянно хранящейся в системе, так и информации одного сеанса работы. Для распределенных систем обеспечить защищенность гораздо сложнее, поскольку нельзя физически изолировать все элементы системы и разрешить доступ к ней только проверенным и обладающим необходимыми знаниями и умениями людям. Организация защищенности данных и коммуникаций предполагает решение следующих задач: • Как организовать защиту системы в целом. При этом большее значение, чем технические аспекты, имеют организационные и психологические факторы – проблемы определения процедур проведения работ, обеспечивающих нужный уровень защищенности, и проблемы соблюдения людьми этих процедур. • Как организовать защиту данных от несанкционированного доступа. • Как обеспечить защиту каналов связи с двух сторон – воспрепятствовать несанкционированному доступу к передаваемой информации и не дать подменить информацию в канале. • Какие протоколы аутентификации пользователей, подтверждения идентичности и авторства использовать. 7 Из перечисленных тем отдельного рассмотрения заслуживают вопросы организации передачи сообщений и транзакций, тем более что все рассматриваемые далее технологии используют эти механизмы. Практически любая распределенная система сейчас строится на основе программного обеспечения промежуточного уровня (middleware). Это программное обеспечение, предназначенное для облегчения интеграции ПО, размещенного на нескольких машинах, в единую распределенную систему и поддержки работы такой системы. Типы моделей «клиент–сервер» в системах баз данных При описании взаимодействия между элементами программных систем инициатор взаимодействия, т.е. компонент, посылающий запрос на обработку, обычно называется клиентом, а отвечающий компонент, тот, что обрабатывает запрос – сервером. «Клиент» и «сервер» в этом контексте обозначают роли в рамках данного взаимодействия. В большинстве случаев один и тот же компонент может выступать в разных ролях – то клиента, то сервера – в различных взаимодействиях. Лишь в небольшом классе систем роли клиента и сервера закрепляются за компонентами на все время их существования. Основной принцип технологии «клиент–сервер» применительно к технологии баз данных заключается в разделении функций стандартного интерактивного приложения на 5 групп, имеющих различную природу: функции ввода и отображения данных – презентационная логика (Presentation Logic); прикладные функции, определяющие основные алгоритмы решения задач приложения – бизнес-логика, или логика собственно приложения (Business Logic); функции обработки данных внутри приложения (Database Logic); функции управления информационными ресурсами (Database Manager System); служебные функции, играющие роль связок между функциями первых четырех групп. Структура типового приложения, работающего с базой данных приведена на рис.1: Рис.1 – Структура типового интерактивного приложения, работающего с базой данных Презентационная логика (Presentation Logic) как часть приложения определяется тем, что пользователь видит на своем экране, когда работает приложение. Сюда относятся все интерфейсные экранные формы, которые пользователь видит или заполняет в ходе работы приложения, к этой же части относится все то, что выводится пользователю на экран как результаты решения некоторых промежуточных задач либо как справочная информация. Поэтому основными задачами презентационной логики являются: 8 формирование экранных изображений; чтение и запись в экранные формы информации; управление экраном; обработка движений мыши и нажатие клавиш клавиатуры. Некоторые возможности для организации презентационной логики приложений предоставляет знако-ориентированный пользовательский интерфейс, задаваемый моделями CICS (Customer Control Information System) и IMS/DC фирмы IBM и моделью TSO (Time Sharing Option) для централизованной main-фреймовой архитектуры. Модель GUI – графического пользовательского интерфейса поддерживается в операционных средах Microsoft’s Windows, Windows NT, в OS/2 Presentation Manager, X-Windows и OSF/Motif. Бизнес-логика, или логика собственно приложений (Business processing Logic), – это часть кода приложения, которая определяет собственно алгоритмы решения конкретных задач приложения. Обычно этот код пишется с использованием раз личных языков программирования, таких как C, C++, Cobol, SmallTalk, VisualBasic. Логика обработки данных (Data manipulation Logic) – это часть кода приложения, которая связана с обработкой данных внутри приложения. Данными управляет собственно СУБД (DBMS). Для обеспечения доступа к данным используются язык запросов и средства манипулирования данными стандартного языка SQL. Обычно операторы языка SQL встраиваются в языки 3-го или 4-го поколения (3GL, 4GL), которые используются для написания кода приложения. Процессор управления данными (Database Manager System Processing) – это собственно СУБД, которая обеспечивает хранение и управление базами данных. В идеале функции СУБД должны быть скрыты от бизнес-логики приложения, однако для рассмотрения архитектуры приложения нам надо их выделить в отдельную часть приложения. В централизованной архитектуре (Host-based processing) эти части приложения располагаются в единой среде и комбинируются внутри одной исполняемой программы. В децентрализованной архитектуре эти задачи могут быть по-разному распределены между серверным и клиентским процессами. В зависимости от характера распределения можно выделить следующие модели распределений: распределенная презентация (Distribution presentation, DP); удаленная презентация (Remote Presentation, RP); распределенная бизнес-логика (Remote business logic, RBL); распределенное управление данными (Distributed data management, DDM); удаленное управление данными (Remote data management, RDA). 9 Рис. 2 – Распределение функций приложения в моделях «клиент–сервер» Эта условная классификация показывает, как могут быть распределены отдельные задачи между серверным и клиентскими процессами. В этой классификации отсутствует реализация удаленной бизнес-логики. Действительно, считается, что она не может быть удалена сама по себе полностью. Считается, что она может быть распределена между разными процессами, которые в общем-то могут выполняться на разных платформах, но должны корректно кооперироваться (взаимодействовать) друг с другом. Двухуровневые модели Двухуровневая модель фактически является результатом распределения пяти указанных функций между двумя процессами, которые выполняются на двух платформах: на клиенте и на сервере. В чистом виде почти никакая модель не существует, однако рассмотрим наиболее характерные особенности каждой двух уровневой модели. Модель удаленного управления данными. Модель файлового сервера Модель удаленного управления данными также называется моделью файлового сервера (File Server, FS). В этой модели презентационная логика и бизнес-логика располагаются на клиенте. На сервере располагаются файлы с данными и поддерживается доступ к файлам. Функции управления информационными ресурсами в этой модели находятся на клиенте. Распределение функций в этой модели представлено на рис.3. 10 Рис. 3 – Модель файлового сервера В этой модели файлы базы данных хранятся на сервере, клиент обращается к серверу с файловыми командами, а механизм управления всеми информационными ресурсами, собственно база метаданных, находится на клиенте. Достоинства этой модели в том, что мы уже имеем разделение монопольного приложения на два взаимодействующих процесса. При этом сервер (серверный процесс) может обслуживать множество клиентов, которые обращаются к нему с запросами. Собственно СУБД должна находиться в этой модели на клиенте. Алгоритм выполнения запроса клиента в данном случае будет следующим. Запрос клиента формулируется в командах ЯМД. СУБД переводит этот запрос в последовательность файловых команд. Каждая файловая команда вызывает перекачку блока информации на клиента, далее на клиенте СУБД анализирует полученную информацию, и если в полученном блоке не содержится ответа на запрос, то принимается решение о перекачке следующего блока информации и т. д. Перекачка информации с сервера на клиента производится до тех пор, пока не будет получен ответ на запрос клиента. Недостатки этой модели: высокий сетевой трафик, который связан с передачей по сети множества блоков и файлов, необходимых приложению; узкий спектр операций манипулирования с данными, который определяется только файловыми командами; отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы). Модель удаленного доступа к данным В модели удаленного доступа (Remote Data Access, RDA) база данных хранится на сервере. На сервере же находится ядро СУБД. На клиенте располагается презентационная логика и бизнес-логика приложения. Клиент обращается к серверу с запросами на языке SQL. Структура модели удаленного доступа приведена на рис. 4. Рис. 4 – Модель удаленного доступа (RDA) 11 Преимущества данной модели: перенос компонента представления и прикладного компонента на клиентский компьютер существенно разгрузил сервер БД, сведя к минимуму общее число процессов в операционной системе; сервер БД освобождается от несвойственных ему функций; процессор или процессоры сервера целиком загружаются операциями обработки данных, запросов и транзакций (это становится возможным, если отказаться от терминалов, не располагающих ресурсами, и заменить их компьютерами, выполняющими роль клиентских станций, которые обладают собственными локальными вычислительными ресурсами); резко уменьшается загрузка сети, так как по ней от клиентов к серверу передаются не запросы на ввод-вывод в файловой терминологии, а запросы на SQL, и их объем существенно меньше. В ответ на запросы клиент получает только данные, релевантные запросу, а не блоки файлов, как в FS-модели. Основное достоинство RDA-модели – унификация интерфейса «клиент–сервер», стандартом при общении приложения- клиента и сервера становится язык SQL. Недостатки данной модели: все-таки запросы на языке SQL при интенсивной работе клиентских приложений могут существенно загрузить сеть; так как в этой модели на клиенте располагается и презентационная логика, и бизнес-логика приложения, то при повторении аналогичных функций в разных приложениях код соответствующей бизнес-логики должен быть повторен для каждого клиентского приложения – это вызывает излишнее дублирование кода приложений; сервер в этой модели играет пассивную роль, поэтому функции управления информационными ресурсами должны выполняться на клиенте. Действительно, например, если нам необходимо выполнять контроль страховых запасов товаров на складе, то каждое приложение, которое связано с изменением состояния склада, после выполнения операций модификации данных, имитирующих продажу или удаление товара со склада, должно выполнять проверку на объем остатка, и в случае, если он меньше страхового запаса, формировать соответствующую заявку на поставку требуемого товара. Это усложняет клиентское приложение, с одной стороны, а с другой – может вызвать необоснованный заказ дополнительных товаров несколькими приложениями. Модель сервера баз данных Для того чтобы избавиться от недостатков модели удаленного доступа, должны быть соблюдены следующие условия: 1. Необходимо, чтобы БД в каждый момент отражала текущее состояние предметной области, которое определяется не только собственно данными, но и связями между объектами данных, т. е. данные, которые хранятся в БД, в каждый момент времени должны быть непротиворечивыми. 2. БД должна отражать некоторые правила предметной области, законы, по которым она функционирует (business rules). Например, завод может нормально работать только в том случае, если на складе имеется некоторый достаточный запас (страховой запас) деталей определенной номенклатуры: деталь может быть запущена в производство только в том случае, если на складе имеется в наличии достаточно материала для ее изготовления, и т. д. 3. Необходим постоянный контроль за состоянием БД, отслеживание всех изменений и адекватная реакция на них: например, при достижении некоторым измеряемым параметром критического значения должно произойти отключение определенной аппаратуры; при уменьшении товарного запаса ниже допустимой нормы должна быть сформирована заявка конкретному поставщику на поставку соответствующего товара. 12 4. Необходимо, чтобы возникновение некоторой ситуации в БД четко и оперативно влияло на ход выполнения прикладной задачи. 5. Одной из важнейших проблем СУБД является контроль типов данных. В настоящий момент СУБД контролирует синтаксически только стандартно-допустимые типы данных, т. е. такие, которые определены в DDL (data definition language) – языке описания данных, который является частью SQL. Однако в реальных предметных областях у нас действуют данные, которые несут в себе еще и семантическую составляющую, например координаты объектов или единицы различных метрик, так, рабочая неделя в отличие от реальной имеет сразу после пятницы понедельник. Данную модель поддерживают большинство современных СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server. Основу данной модели составляет механизм хранимых процедур как средство программирования SQL-сервера, механизм триггеров как механизм отслеживания текущего состояния информационного хранилища и механизм ограничений на пользовательские типы данных, который иногда называется механизмом поддержки доменной структуры. Модель сервера баз данных представлена на рис. 5. Рис. 5 – Модель активного сервера БД В этой модели бизнес-логика разделена между клиентом и сервером. На сервере бизнес-логика реализована в виде хранимых процедур – специальных программных модулей, которые хранятся в БД и управляются непосредственно СУБД. Клиентское приложение обращается к серверу с командой запуска хранимой процедуры, а сервер выполняет эту процедуру и регистрирует все изменения в БД, которые в ней предусмотрены. Сервер возвращает клиенту данные, релевантные его запросу, которые требуются клиенту либо для вывода на экран, либо для выполнения части бизнес-логики, которая расположена на клиенте. Трафик обмена информацией между клиентом и сервером резко уменьшается. Централизованный контроль в модели сервера баз данных выполняется с использованием механизма триггеров. Триггеры также являются частью БД. Термин «триггер» взят из электроники и семантически очень точно характеризует механизм отслеживания специальных событий, которые связаны с состоянием БД. Триггер в БД является как бы некоторым тумблером, который срабатывает при возникновении определенного события в БД. Ядро СУБД проводит мониторинг всех событий, которые вызывают созданные и описанные триггеры в БД, и при возникновении соответствующего события сервер запускает соответствующий триггер. Каждый триггер представляет собой также некоторую программу, которая выполняется над базой данных. Триггеры могут вызывать хранимые процедуры. Механизм использования триггеров предполагает, что при срабатывании одного триггера могут возникнуть события, которые вызовут срабатывание других триггеров. Этот мощный инструмент требует тонкого и согласованного применения, чтобы не получился бесконечный цикл срабатывания триггеров. 13 В данной модели сервер является активным, потому что не только клиент, но и сам сервер, используя механизм триггеров, может быть инициатором обработки данных в БД. И хранимые процедуры, и триггеры хранятся в словаре БД, они могут быть использованы несколькими клиентами, что существенно уменьшает дублирование алгоритмов обработки данных в разных клиентских приложениях. Для написания хранимых процедур и триггеров используется расширение стандартного языка SQL, так называемый встроенный SQL. Недостатком данной модели является очень большая загрузка сервера. Действительно, сервер обслуживает множество клиентов и выполняет следующие функции: осуществляет мониторинг событий, связанных с описанными триггерами; обеспечивает автоматическое срабатывание триггеров при возникновении связанных с ними событий; обеспечивает исполнение внутренней программы каждого триггера; запускает хранимые процедуры по запросам пользователей; запускает хранимые процедуры из триггеров; возвращает требуемые данные клиенту; обеспечивает все функции СУБД: доступ к данным, контроль и поддержку целостности данных в БД, контроль доступа, обеспечение корректной параллельной работы всех пользователей с единой БД. Если мы переложили на сервер большую часть бизнес-логики приложений, то требования к клиентам в этой модели резко уменьшаются. Иногда такую модель называют моделью с «тонким клиентом» в отличие от предыдущих моделей, где на клиента возлагались гораздо более серьезные задачи. Эти модели называются моделями с «толстым клиентом». Для разгрузки сервера была предложена трехуровневая модель. Модель сервера приложений Эта модель является расширением двухуровневой модели и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Архитектура трехуровневой модели приведена на рис. 6. Этот промежуточный уровень содержит один или несколько серверов приложений. Рис. 6 – Модель сервера приложений В этой модели компоненты приложения делятся между тремя исполнителями: Клиент обеспечивает логику представления, включая графический пользовательский интерфейс, локальные редакторы; клиент может запускать локальный код приложения клиента, который может содержать обращения к локальной БД, расположенной на компьютере-клиенте. Клиент исполняет коммуникационные функции front-end части приложения, которые обеспечивают клиенту доступ в локальную или глобальную сеть. Кроме того, реализация взаимодействия между клиентом и сервером 14 может включать в себя управление распределенными транзакциями, что соответствует тем случаям, когда клиент также является клиентом менеджера распределенных транзакций. Серверы приложений составляют новый промежуточный уровень архитектуры. Они спроектированы как исполнения общих незагружаемых функций для клиентов. Серверы приложений поддерживают функции клиентов как частей взаимодействующих рабочих групп, поддерживают сетевую доменную операционную среду, хранят и исполняют наиболее общие правила бизнес-логики, поддерживают каталоги с данными, обеспечивают обмен сообщениями и поддержку запросов, особенно в распределенных транзакциях. Серверы баз данных в этой модели занимаются исключительно функциями СУБД: обеспечивают функции создания и ведения БД, поддерживают целостность реляционной БД, обеспечивают функции хранилищ данных (warehouse services). Кроме того, на них возлагаются функции создания резервных копий БД и восстановления БД после сбоев, управления выполнением транзакций и поддержки устаревших (унаследованных) приложений (legacy application). Отметим, что эта модель обладает большей гибкостью, чем двухуровневые модели. Наиболее заметны преимущества модели сервера приложений в тех случаях, когда клиенты выполняют сложные аналитические расчеты над базой данных, которые относятся к области OLAP-приложений (On-line analytical processing). В этой модели большая часть бизнес-логики клиента изолирована от возможностей встроенного SQL, реализованного в конкретной СУБД, и может быть выполнена на стандартных языках программирования, таких как C, C++, SmallTalk, Cobol. Это повышает переносимость системы, ее масштабируемость. Функции промежуточных серверов могут быть в этой модели распределены в рамках глобальных транзакций путем поддержки XA-протокола (X/Open transaction interface protocol), который поддерживается большинством поставщиков СУБД. |