Файл: Общетеоретический сектор.pdf

- возможность, в множестве случаев, распределить функции вычислительной программные детали между несколькими независимыми ПК в локальной сети;

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

- поддержка многопользовательской работы;

- гарантия целостности данных.

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

• неработоспособность ПК сервера может сделать неработоспособной всю вычислительную сеть;
• администрирование данной программные детали требует квалифицированного профессионала;
• значительная стоимость оборудования;
• бизнес логика программных средств осталась в клиентском ПО.

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

Увеличение масштабов информационной программные детали не порождает метод идеальных проблем. Обычным решением является замена аппаратуры ПК сервера (и, может быть, аппаратуры рабочих станций, если требуется преобразование к локальному кэшированию баз данных). В любом случае практически не затрагивается прикладная сектор информационной программные детали.

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

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

2.6. Многозвенная уровневая архитектурная система «клиент-сервер».

Multitier architecture - разновидность архитектуры клиент-сервер, в которой функция спец обработки данных вынесена на один или несколько отдельных серверов. Это позволяет секторить функции сохранения, спец обработки и представления данных для более эффективного использования возможностей серверов и клиентов.

Среди многоуровневой архитектуры клиент-сервер наиболее распространена трехуровневая архитектурная система (трехзвенная архитектурная система, threetier), предполагающая наличие следующих деталей приложения: клиентское программа (обычно говорят "тонкий клиент" или терминал), подключенное к серверу программных средств, который в свою очередь подключен к серверу БД.

Схематически такую архитектурную системную часть можно представить, как показано на рис 2.2.3.1.

Рис. 2.2.3.1. Представление многоуровневой архитектуры "клиент-сервер"

Терминал – это интерфейсный (обычно графический) компонент, который представляет первый степень, собственно программа для конечного владельца. Первый степень не должен иметь прямых связей с базой данных (по востребованиям безопасности), быть нагруженным основной бизнес-логикой (по востребованиям масштабируемости) и хранить состояние приложения (по востребованиям надежности). На первый степень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка,

группировка, подсчет значений) с информациями, уже загруженными на терминал.

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

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

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

Плюсами данной архитектуры являются: клиентское ПО не нуждается в администрировании; масштабируемость; конфигурируемость – изолированность степеней друг от друга позволяет быстро и простыми деталими переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из степеней; значительная безопасность; значительная надежность; низкие востребования к скорости канала (локальной сети) между терминалами и сервером программных средств; низкие востребования к производительности и техническим характерный параметристикам терминалов, как следствие снижение их финансовой стоимости.

Минусами данной архитектуры являются: растет трудность серверной части и, как следствие, затраты на администрирование и обслуживание; более значительная трудность создания программных средств; сложнее в разворачивании и администрировании; высокие востребования к производительности серверов программных средств и ПК сервера БД, а, значит, и значительная стоимость серверного оборудования; высокие востребования к скорости канала (локальной сети) между сервером БД и ПК серверами программных средств.

Начало процессу развития корпоративного программного обеспечения в многозвенной архитектурной системному средству было положено еще в рамках технологии "клиент- сервер". В них наряду с клиентской секторную приложения и сервером баз данных появились серверы программных средств (Application Servers).

В идеале: пакет программ-клиент реализует GUI, передает запросы серверу программных средств и принимает от него ответ, сервер программных средств реализует бизнес-логику и обращается с запросами к серверу "третьего уровня" (например, серверу БД за информациями), сервер третьего уровня обслуживает запросы ПК сервера программных средств. Пакет программ-клиент, таким образом, может быть "тонкой".

Преимущества такой архитектуры очевидны: изменения на каждом из звеньев можно осуществлять независимо; снижаются нагрузки на сеть, поскольку звенья не обмениваются между собой большими объемами данных; обеспечивается масштабирование и простая модернизация оборудования и программного обеспечения, поддерживающего каждое из звеньев, в том числе обновление серверного парка и терминального оборудования, СУБД и т.д.; приложения могут создаваться на стандартных языках третьего или четвертого поколения (Java, C/C++).

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

Основной проблемой систем, основанных на двухзвенной архитектурной системному средству "клиент-сервер",или тем более на многозвенной архитектурной системному средству, является то, что от них требуется мобильность в как можно более широком классе аппаратно-программируемых сред. Даже если ограничиться UNIX-ориентированными локальными сетями, в разных сетях применяется разная аппаратура и документы протоколы связи. Попытки создания систем, поддерживающих все возможные документы протоколы, подводит к их перегрузке сетевыми деталями в ущерб функциональности. Еще более сложный аспект этой препятствия связан с возможностью использования разных представлений данных в разных узлах неоднородной локальной локальной сети. В разных ПК может существовать различная адресация, представление чисел, кодировка символов и т.д. Это особенно существенно для серверов высокого уровня: телекоммуникационных, вычислительных, баз данных.

Общим решением препятствия мобильности такого рода систем является использование технологий, реализующие документы протоколы удаленного вызова процедур (RPC - Remote Procedure Call) стандартизованным и платформа-независимым способом. При использовании таких технологий обращение к сервису в удаленном секторе выглядит как обычный вызов процедуры (методов удаленных предметов). Детали RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной локальной сети и сетевых документах протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и документах протоколов скрыта от прикладного программиста.

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

Некоторые авторы представляют многозвенную архитектурную системную часть (трехзвенную) в виде пяти степеней

1.Представление;

2.Степень представления;

3.Степень логики;

4.Степень данных;

5.Данных.

Пять степеней многозвенной архитектуры "клиент-сервер"

К представлению относится вся информация, непосредственно отображаемая пользователю: сгенерированные html-страницы, таблицы стилей, изображения.

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

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

2.7. Виды клиент-сервер.

Существует, по меньшей мере, три виды клиент-сервер:

1.вид способа к удаленным информациям (RDA-вид);

2.вид ПК сервера БД (DBS-вид);

3.вид ПК сервера программных средств (AS-вид).

Первые две виды являются двухзвенными и не могут рассматриваться в качестве базовой виды распределенной программные детали. Третья вид — трехзвенная. Она (как и все многозвенные виды) хороша тем, что в ней интерфейс работы с пользователем полностью независим от компонента спец обработки данных. Собственно, трехзвенной ее можно считать постольку, поскольку в ней явно выделены: компонент интерфейса с пользователем; ПО промежуточному слою (middleware); компонент управления информациями.

Middleware — это главный компонент трехзвенных назначенных систем. Он выполняет функции управления транзакциями и коммуникациями, транспортировки запросов, управления именами и иные функции.

Существует фундаментальное различие между технологией типа "сервер запросов — клиент запросов" и трехзвенными технологиями. В первом случае клиент явным образом запрашивает данных, зная структуру БД (имеет место так называемая "поставка данных" клиенту). Клиент передает СУБД, например, SQL-запрос,а в ответ получает данных. Осуществляется жесткая связь типов, для воплощения которой все СУБД используют закрытый SQL-канал. Он строится двумя процессами: SQL/Net на ПК-клиенте и SQL/Net на ПК-сервере и порождается по инициативе владельца оператором connect. Канал называется закрытым в том смысле, что невозможно, например, написать программу, которая будет шифровать SQL-запросы по специальному алгоритму или другим образом будет вмешиваться в процесс передачи данных между клиентских и серверных программ.