Технология «клиент-сервер» (Клиент- серверная архитектура)

Содержание:

ВВЕДЕНИЕ

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

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

Прогресс в сфере компьютерных технологий не стоит на месте. Результатом эволюции компьютерных технологий можно назвать компьютерные сети. Именно появление сетей стало шагом в новый этап развития компьютерных технологий.

На самом деле компьютерные сети- это не что то новое и непонятное. Компьютерные сети появились уже очень давно, но они были очень примитивными. В сравнении с современными сетевыми технологиями, в то время скорость работы сети была ничтожно мала. Но для того времени это было огромным достижением.

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

Такой технологией стала технология «клиент-сервер», которая дает право пользователю сети получить очень быстрый доступ к ресурсам.

Именно об этой технологии и пойдет речь в данной курсовой работе.

Цель моей курсовой работы – раскрыть главные черты технологии «клиент-сервер».

1. Клиент- серверная архитектура

1.1 Основные понятия

Архитектура информационной системы - концепция, которая определяет структуру , модель, выполняемые функции и взаимосвязь компонентов информационной системы.

Клиент-сервер (Client-server) — вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг (сервисов), которые называются серверами, и заказчиками услуг, называемыми клиентами.

Сервер — это программа, которая представляет какие-то услуги другим программам и которая обслуживает запросы клиентов на получение ресурсов определенного вида.

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

1.2 История

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

Обычно, любой пользователь хочет видеть свой компьютер с самыми лучшими свойствами и высокой вычислительной мощностью.

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

В связи с этим пользователям приходится знакомиться с двумя разными ОС ( на больших компьютерах, как правило, устанавливается операционная система типа: MVS, VMS, VM, UNIX. Персональные компьютеры используют в свою очередь операционную систему типа: MS DOS/MS Windows, OS/2 или Mac.).

По результатам опроса самых крупных представителей трехсот фирм США, которые в своей работе используют ПК, оказалось, 81% принимавших участие в опросе людей, используют доступ не к одному единственному ПК, а к нескольким. Для решения проблемы использования нескольких ПК, стали появляться локальные сети, объединяющие несколько ПК. Для связи и корректной работы компьютеров в сети, стали использоваться специально предназначенные операционные системы, к примеру, NetWare фирмы Novell. Данная система позволяла совместно пользоваться разными файлами, которые содержались в разных узлах всей сети. Такая технология получила название файл-сервер. Но, к сожалению, данная технология крайне наделена недостатками. Использую технологию файл-сервер, нельзя говорить о конфиденциальности доступа и целостности данных. Используя сеть, файлы, необходимые пользователю, передаются целиком, несмотря на то, что иногда для пользователя нужна только определенная часть файла. В следствие этого, сеть перегружается и снижается производительность системы. Еще одним недостатком системы файл-сервер можно считать надежность системы в целом. К примеру, в случае, какой либо аварии на одной из работающих станций, в момент передачи или записи данных, приводит к их искажению и потере. Обеспечивая непротиворечивость данных, приходится блокировать файлы, а это также способствует замедлению в работе.

Естественным желанием десяти специалистов в области вычислительной техники было совместить преимущества персональных компьютеров и мощных центральных компьютеров. Первым шагом в этом направлении было использование персональных компьютеров в качестве интеллектуальных терминалов. При таком подходе в персональном компьютере, соединенном с центральным компьютером, запускается специальное программное обеспечение, которое позволяет этому персональному компьютеру работать в режиме эмуляции терминала. При этом мы получаем архитектуру, которая реализует все достоинства архитектуры с мощным центральным компьютером, однако, кроме всего прочего, персональный компьютер может использоваться и самостоятельно, по своему прямому назначению. Теперь нет необходимости иметь на столе два дисплея,хотя большинство недостатков, которые присущи архитектуре с центральным компьютером, все еще сохраняется. Кроме того, хотя персональные компьютеры, имеющие дисплеи с картой VGA, позволяют работать с графикой, однако использовать их в качестве графического терминала большой центральной машины некомфортно. Задача выполняется в центральном компьютере и по проводам передаются графические образы экрана. Эти образы довольно велики и скорость смены изображения на экране может быть достаточно низкой. Следующим этапом в решении описанной выше проблемы явилось использование архитектуры клиент-сервер. В такой архитектуре все компьютеры сети разделены на 2 группы: клиенты и серверы. Компьютер- сервер - это мощный компьютер с большой оперативной памятью и большим количеством дискового пространства. На нем хранится база данных и выполняется сложная обработка, которая требует больших вычислительных ресурсов. На компьютерах-клиентах выполняются первичная обработка данных при вводе, форматирование данных, а также окончательная (финишная) обработка данных, которые извлечены из сервера. В качестве компьютеров-клиентов обычно используются персональные 11 компьютеры типа IBM PC или Macintosh. Преимущества архитектуры клиент-сервер очевидны. Каждый тип компьютера используется по своему назначению, а это значит, что обеспечивается более полное использование возможностей компьютеров. На компьютерах-клиентах работают знакомые пользователям PC пакеты, которые позволяют предоставлять результаты работы всей системы в удобном для анализа и принятия решений виде. На этих компьютерах легко можно реализовать дружественный пользовательский интерфейс приложения, которые используют графику, цвет, звук, работу с окнами и мышью и т.д. Компьютер-клиент позволяет быстро выполнять ввод и первичный контроль данных. Для финишной обработки данных могут использоваться те редакторы или пакеты электронных таблиц, которые пользователь считает наиболее удобными. В качестве компьютеров - клиентов могут одновременно использоваться компьютеры разных типов с различными операционными системами. Архитектура клиент-сервер позволяет реализовать распределенную обработку, поскольку часть работы (интерфейс с пользователем, финишная обработка) выполняется на компьютере-клиенте, а часть - на компьютере- сервере. Это позволяет уменьшить загрузку сервера и улучшить его работу, а также увеличить число клиентов, которые одновременно работают с сервером. Наиболее часто архитектура клиент-сервер применяется для приложений, которые созданы с использованием систем управления базами данных (СУБД). Дальнейшим развитием архитектуры клиент-сервер явилось использование в сети не одного, а нескольких серверов баз данных. Это позволило перейти от работы с локальной БД к работе с распределенной БД. Причем работа с распределенной базе данных (БД) "прозрачна" для пользователя, т.е. он работает с ней так же, как с локальной БД, не задумываясь о том, на каком сервере лежат его данные. Пользователь 12 обращается к одному из серверов, тот, не найдя у себя нужных данных, автоматически обращается к другим серверам. Многосерверная архитектура сегодня представляется очень перспективной. Она позволяет заменить одну мощную центральную машину на несколько менее мощных и, следовательно, более дешевых, и еще больше распараллелить обработку данных. Кроме того, такая архитектура повышает надежность системы, поскольку при выходе из строя одного из серверов все приложения, которые работают с данными других серверов, могут продолжать работу. При выходе из строя части локальной или глобальной сети система может попытаться найти иной путь к нужному серверу (по другим ветвям сети). Кроме того, на локальных серверах могут храниться данные, которые наиболее часто используются в данном узле, что позволяет свести к минимуму передачу данных по сети от сервера к серверу.

2. Клиент-серверная архитектура применительно к базам данных

2.1 Понятие архитектуры клиент-сервер.

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

Говоря о системе файл- сервер, можно сказать, что она также использует технологию клиент- сервер, но, если смотреть со стороны архитектуры прикладных программ, самым важным является то, какого именно рода ресурсы предоставляет клиентам сервер. В файл-серверной системе данные хранятся на файловом сервере (к примеру, Novell NetWare или Windows NT Server), а их обработка происходит на рабочих станциях, на которых, как правило, функционирует одна из, так называемых, "настольных СУБД" - Access, FoxPro, Paradox и т.д. Приложение на рабочей станции "отвечает за все", а именно, за логическую обработку данных, формирование пользовательского интерфейса, и за непосредственное манипулирование данными. Файловый сервер предоставляет услуги только самого низкого уровня - открытие, закрытие и модификацию файлов, именно файлов, а не базы данных. База данных существует только в "мозгу" рабочей станции. Исходя из этого, непосредственным манипулированием данными занимается несколько независимых и несогласованных между собой процессов. Однако, кроме того, чтобы осуществить любой обработки (поиск, модификация, суммирование и т.д.) все данные необходимо передать по сети с сервера на рабочую станцию.

Рисунок 1 - Архитектура файл-сервер

В системах управления предприятием такое понятие архитектуры как клиент-сервер связывается с разделением любой прикладной программы на 3 основных слоя или компонента.

К эти трем компонентам относятся:

- компонент представления (визуализации) данных

- компонент прикладной логики

- компонент управления БД

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

2.2 Двухуровневая клиент-серверная архитектура

Двухуровневая клиент- серверная архитектура получила свое распространение в начале 1990-х годов в связи с ростом рынка персональных компьютеров и в следствие снижения спроса на мэйнфреймы. Первое время вышеперечисленные системы основывались на классической двухуровневой клиент-серверной архитектуре (Two-tier architecture). Под клиент-серверным приложением в этом случае понимается информационная система, которая основана на использовании серверов баз данных. Схематически такую архитектуру можно представить, как показано на рисунке 2.

Рисунок 2 - Классическое представление архитектуры "клиент-сервер"

Компанией Gartner Group, которая специализируется в области исследования информационных технологий, была предложена следующая классификация двухзвенных моделей взаимодействия клиент-сервер (двухзвенными эти модели называются из-за того, что три компонента приложения различным образом распределяются между двумя узлами):

Рисунок 3 - Двухзвенная модель клиент- сервер

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

- возможность централизованного администрирования прикладных функций

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

К недостаткам относятся:

- ограниченность средств разработки хранимых процедур по сравнению с языками общего назначения (C и Pascal).

На практике, как правило, принято использовать смешанный подход:

- простейшие прикладные функции выполняются хранимыми процедурами на сервере;

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

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

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

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

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

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

К минусам данной архитектуры относятся:

-неработоспособность сервера может сделать неработоспособной всю вычислительную сеть;

-администрирование данной системы требует квалифицированного профессионала;

-высокая стоимость оборудования;

-бизнес логика приложений осталась в клиентском ПО.

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

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

2.3 Многоуровневая архитектура клиент-сервер

Multitier architecture (Многоуровневая архитектура клиент-сервер) - это разновидность архитектуры клиент-сервер, в которой функция обработки данных вынесена на один или некоторое количество отдельных серверов. Это позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов. Среди многоуровневой архитектуры клиент-сервер самой распространенной считается трехуровневая архитектура (трехзвенная архитектура, threetier), которая предполагает наличие следующих компонентов приложения: клиентское приложение (обычно говорят "тонкий клиент" или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных. Схематически такую архитектуру можно представить, как показано на рисунке 4.

Рисунок 4 – Многоуровневая архитектура "клиент-сервер"

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

- клиентское ПО не нуждается в администрировании

-масштабируемость

- конфигурируемость – изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней

-высокая надежность

-высокая безопасность

-низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости

-низкие требования к скорости канала (сети) между терминалами и сервером приложений

К недостаткам данной архитектуры относятся:

-увеличение сложности серверной части и, как следствие, затраты на администрирование и обслуживание

-более высокая сложность создания приложений

- сложнее в разворачивании и администрировании

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

-высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений

Еще в рамках технологии «клиент-сервер» было положено начало процессу развития корпоративного ПО в многозвенной архитектуре. В них наряду с клиентской частью приложения и сервером баз данных появились серверы приложений (Application Servers). В идеале:  программа-клиент реализует GUI, передает запросы серверу приложений и принимает от него ответ,  сервер приложений реализует бизнес-логику и обращается с запросами к серверу "третьего уровня" (например, серверу базы данных за данными),  сервер третьего уровня обслуживает запросы сервера приложений. Программа-клиент, таким образом, может быть "тонкой". Плюсами такой архитектуры являются:

- изменения на каждом из звеньев можно осуществлять независимо; - снижаются нагрузки на сеть, поскольку звенья не обмениваются между собой большими объемами информации;- обеспечивается масштабирование и простая модернизация оборудования и программного обеспечения, поддерживающего каждое из звеньев, в том числе обновление серверного парка и терминального оборудования, СУБД и т.п.; - приложения могут создаваться на стандартных языках третьего или четвертого поколения (Java, C/C++). Далее следующим логическим шагом является дальнейшее увеличение количества звеньев, причем возрастет не только за счет разбиения, когда "утоньшается" каждое из известных технических звеньев, но вся бизнес-модель строится как многозвенная. На данный момент времени, современные корпоративные программные системы представляют собой, как правило, сложные системы взаимодействующие между собой на разных уровнях компонентов, каждые из которых могут являться клиентами для одних компонентов и серверами для других. Главной проблемой систем, которые основаны на двухзвенной архитектуре "клиент-сервер", или тем более на многозвенной архитектуре, является то, что от них необходима мобильность в как можно более широком классе аппаратно-программных сред. Даже если ограничиться UNIXориентированными локальными сетями, в различных сетях используется разная аппаратура и протоколы связи. Попытки создания систем, поддерживающих все возможные протоколы, приводит к их перегрузке сетевыми деталями в ущерб работоспособности. Еще более трудный аспект этой проблемы связан с возможностью использования разныличных представлений данных в разных узлах неоднородной локальной сети. В разных компьютерах может существовать различная адресация, представление чисел, кодировка символов и т.п. В особой степени это важно для серверов высокого уровня: баз данных ,телекоммуникационных, вычислительных. Общим решением проблемы мобильности такого рода систем является использование технологий, которые реализуют протоколы удаленного вызова процедур (RPC - Remote Procedure Call) стандартизованным и платформо- независимым способом. Используя такие технологии обращение к сервису в удаленном узле выглядит как стандартный вызов процедуры (методов удаленных объектов). Средства RPC, в которых, конечно же, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Это позволяет скрыть от прикладного программиста специфику сетевой среды и протоколов. Вызывая удаленную процедуру, программы RPC производят преобразование форматов данных клиента в промежуточные машино- независимые форматы, и потом преобразование в форматы данных сервера. Передавая ответные параметры- осуществляется обратное преобразование. Это значит, в случае если система реализована на основе стандартного пакета RPC, она может быть с легкостью перенесена в различные открытые среды. Некоторые авторы представляют многозвенную архитектуру (трехзвенную) в виде пяти уровней (рисунок 5) 1. Представление; 2. Уровень представления; 3. Уровень логики; 4. Уровень данных; 5. Данные.

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

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

2.4 Модели клиент-сервер

По меньшей мере, три модели клиент-сервер существует на сегодняшний день:

-модель доступа к удаленным данным (RDA-модель)

-модель сервера базы данных (DBS-модель)

- модель сервера приложений (AS-модель)

Первые две модели относятся к двухзвенными и не могут рассматриваться в качестве базовой модели распределенной системы. Третья модель — трехзвенная. Ее плюсом (как и всех многозвенных моделей) является то, что в ней интерфейс работы с пользователем в полной мере не зависит от компонента обработки данных. А это значит, трехзвенной ее можно считать из за того, что в ней явно выделены:

-компонент интерфейса с пользователем

-программное обеспечение промежуточного слоя (middleware) компонент управления данными

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

2.5 Клиент-серверная архитектура применительно к ИС

"Клиент-сервер" - это архитектура программного комплекса, в которой его функциональные части взаимодействуют по схеме "запрос-ответ". Если рассмотреть две части этого комплекса , которые взаимодействуют между собой, то одна из них (клиент) выполняет активную функцию, т. е. инициирует запросы, а другая (сервер) пассивно на них отвечает. По мере развития системы роли могут изменяться, к примеру какой-то программный блок будет одновременно выполнять функции сервера по отношению к одному блоку и клиента по отношению к другому. Любая информационная система должна иметь, как минимум, три основные функциональные части - модули хранения данных, их обработки и интерфейса с пользователем. Каждая из этих частей может быть использована независимо от двух других. Вот к примеру, не меняя программ, которые используются для хранения и обработки данных, можно изменить интерфейс с пользователем таким образом, что одни и те же данные будут выводиться на экран в виде таблиц, графиков или гистограмм. Не изменяя программ представления данных и их хранения, можно поменять программы обработки, к примеру, изменив алгоритм полнотекстового поиска. И, наконец, не меняя программ представления и обработки данных, можно изменить программное обеспечение для хранения данных, перейдя, к примеру, на другую файловую систему. В классической клиент-серверной архитектуре три основные части приложения приходится распределять по двум физическим модулям. Как правило, программное обеспечение хранения данных располагается на сервере (например, сервере базы данных), интерфейс с пользователем - на стороне клиента, а обработку данных приходится распределять между клиентской и серверной частями. Это и является главным недостатком двухуровневой архитектуры, из которого следуют несколько неприятных особенностей, которые достаточно усложняют разработку клиент-серверных систем. А именно, при разбиении алгоритмов обработки данных необходимо синхронизировать поведение обеих частей системы. Все разработчики должны знать и понимать полную информацию о изменениях, которые произошли в последнее время, и которые внесены в систему, а также понимать эти изменения. Все это создает огромные сложности во время разработки клиент- серверных систем, их установке и сопровождении, так как нужно затрачивать достаточно много услилий на координацию действий разных групп специалистов. В работе разработчиков часто возникают разногласия, и это тормозит развитие системы и вынуждает изменять уже готовые и проверенные элементы. Дабы избежать несогласованности различных элементов архитектуры, стараются выполнять обработку данных на одной из двух физических частей - либо на стороне клиента ("толстый" клиент), либо на сервере ("тонкий" клиент, или архитектура, называемая "2,5- уровневый клиент-сервер"). Каждый подход имеет свои минусы. В первом случае неоправданно перегружается сеть, так как по ней передаются необработанные, а это значит, с большой ненадобностью данные. Кроме всего прочего, усложняется поддержка системы и ее изменение, поскольку замена алгоритма вычислений или правка ошибки требует одновременной полной замены всех интерфейсных программ, по-другому же, могут возникнуть ошибки или несогласованность данных. В случае если же вся обработка информации выполняется на сервере (когда такое вообще возможно), то появляется проблема описания встроенных процедур и их отладки. Все дело в том, что язык описания встроенных процедур , как правило, является декларативным и, следовательно, в принципе не допускает пошаговой отладки. Помимо всего прочего, систему с обработкой информации на сервере абсолютно невозможно перенести на другую платформу, что является серьезным минусом.

2.6 Толстый и тонкий клиенты

Обозначение в словаре Free Online Dictionary of Computing, тонкий клиент – это такое клиентское устройство (либо программа), которое передает большую часть исполняемых им функций серверу. Толстый клиент определить достаточно просто - это все клиенты, которые не являются тонкими. Тонкий клиент (thin client) — терминал сети без жестких дисков, вычислительная мощность которого и объем памяти определяются задачами пользователя (рисунок 7). Все программы и приложения, которые хранятся на сервере, становятся легко доступными для пользователя при включении его устройства и выполнении процедуры регистрации на сервере. Тонким клиентом называют также ПК (в том числе и мобильный) с минимальной мощностью процессора, оперативной и внешней памятью, которая позволяет пользователю, осуществлять ввод и отображение данных за счет выполнения вычислений и хранения данных на более мощном ПК или сервере, с которыми он может осуществлять связь при помощи каналов средней пропускной способности. К тонкому клиенту могут подключаться внешние устройства ввода/вывода данных (сканеры, мониторы, принтеры и проекторы). Клиент называется тонким, если он не содержит совсем или содержит очень маленькую часть бизнес-логики, то есть представляет собой исключительно презентационный слой.

Рисунок 7 – Архитектура «Тонкий клиент»

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

Рисунок 8 – Архитектура «Толстый клиент»

Достоинства тонкого клиента:

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

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

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

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

- повышение производительности труда операторов. Сведение всех сервисных операций на сервер заметно повышает производительность труда операторов.

- снижение стоимости эксплуатации оборудования. Имея не слишком большое различие в стоимости оборудования тонкий клиент заметно дешевле в эксплуатации.

Технология «тонкий клиент-сервер» основывается на трех главных составляющих:

- стопроцентное выполнение прикладных задач на терминальном сервере

- многопользовательская операционная система

- технология распределенного отображения пользовательского интерфейса приложений.

Пользователи получают возможность в одно и то же время заходить в систему и выполнять приложения на сервере в различных, защищенных друг от друга сессиях сервера. В системе ,которая использует тонкого клиента по сети или коммутируемой телефонной линии, на сервер передаются сигналы, которые отражают нажатие на какую либо клавишу или какое-то движение мыши. Сервер же, в свою очередь, производит соответствующие действия и формирует изменения экрана пользователя и передаѐт эти изменения тонкому клиенту. Тонкий клиент получает от сервера изменѐнные образы экрана и отображает их на дисплее (в современных системах может передаваться не весь изменѐнный экран, а лишь какие-либо части изображения с определенными командами, на основании которых программное обеспечение тонкого клиента формирует изменѐнную картинку). В роли клиента может выступать любой ПК. Но, так как на нем практически не выполняются операции по обработке данных, в качестве тонких клиентов можно использовать и дешевые терминалы, которые имеют низкую производительность, и не содержат компоненты с движущимися частями (жесткие диски, вентиляторы), оснащенные, обычно, устройствами с достаточно ограниченным объемом памяти (ОЗУ). Работая в терминальной системе все прикладные программы, которые даны и параметры настроек хранятся на терминальном сервере. Является это преимуществом в плане начального развѐртывания рабочих мест (нет нужды устанавливать программное обеспечение на каждом терминале), более удобного проведения резервного копирования данных (надо копировать только содержимое сервера), восстановления сессий после сбоев (все пользовательские сессии автоматически сохраняются на сервере). Еще одно преимущество технологии тонких клиентов заключается в том, что она ориентирована на сотрудников, которые пользуются дистанционным доступом. Если какое-то время сотрудникам компании нужно работать не в офисе (к примеру, в командировке, в другом офисе или дома), эта проблема легко и просто решается с помощью систем на базе тонких клиентов. Технология тонких клиентов обеспечивает высокую производительность даже на рабочих местах с низкой производительностью, за счѐт использования вычислительных ресурсов терминального сервера. В случае необходимости повышения вычислительной мощности всей системы, достигается замена всего лишь одного устройства – терминального сервера, все рабочие места автоматически переходят на высший уровень производительности без необходимости замены каких-либо устройств.

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

Плюсы толстого клиента:

- широкий функционал в отличие от тонкого

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

-предоставляет возможность работы даже при обрывах связи с сервером - имеет возможность подключения к банкам без использования сети Интернет

- высокое быстродействие

Минусы:

- большой размер дистрибутива

-многое в работе клиента зависит от того, для какой платформы он разрабатывался

- при работе с ним возникают проблемы с удаленным доступом к данным

- довольно сложный процесс установки и настройки

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

1. "Толстый" клиент: сложность администрирования; усложняется обновление ПО, поскольку его замену нужно производить одновременно по всей системе; усложняется распределение полномочий, так как разграничение доступа происходит не по действиям, а по таблицам; перегружается сеть вследствие передачи по ней необработанных данных; слабая защита данных, поскольку сложно правильно распределить полномочия.

2. "Толстый" сервер: усложняется реализация, так как языки типа PL/SQL не предназначены для разработки подобного ПО, и нет хороших средств отладки; производительность программ, которые написаны на языках типа PL/SQL, намного ниже, чем те, которые созданы, на других языках, а это имеет огромное значение для сложных систем; программы, написанные на СУБД-языках, как правило, работают не очень надежно; ошибка в них может привести к выходу из строя всего сервера баз данных; получившиеся таким образом программы полностью непереносимы на другие системы и платформы. Для решения вышеперечисленных проблем применяются многоуровневые (три и более уровней) архитектуры клиент-сервер. Разберем следующие компоненты: презентационная логика (Presentation Layer - PL); бизнес-логика (Business Layer - BL); логика доступа к ресурсам (Access Layer - AL). Таким образом, можно придти к нескольким моделям клиент-серверного взаимодействия : - "Толстый" клиент. Достаточно часто встречающийся вариант применения архитектуры клиент-сервер в уже внедренных и активно используемых системах. Такая модель подразумевает в себе объединение в клиентском приложении как PL, так и BL. Серверная часть, при описанном подходе, представляет собой сервер баз данных

- реализующий AL. К описанной модели часто применяют аббревиатуру RDA - Remote Data Access. "Тонкий" клиент.

- модель, которая начала активно использоваться в корпоративной среде из-за распространения Internet-технологий и, в первую очередь, Web-браузеров. В данном случае клиентское приложение обеспечивает реализацию PL, а сервер объединяет BL и AL.

- сервер бизнес-логики. Модель с физически выделенным в отдельное приложение блоком BL. Варианты, которые рассматриваются в этой части разделения функциональности между клиентом и сервером считаются "классическими", дальше будет использоваться не только устоявшаяся традиционная, но и более новая терминология, которая возникла из-за распространения в корпоративных средах Internet/intranet-технологий и стандартов. Хоть и в качестве серверной части, в общем случае, выступает менеджер многопользовательского доступа к информационным ресурсам, в этой статье будет сохраняться ориентация на серверы баз данных, как законченное серверное звено. Модели, которые основаны на Internet-технологиях и применяются для построения внутрикорпоративных систем, называются internet. Хоть и internet-системами на сегодняшний день называется все, что в какой то мере использует стек протоколов TCP/IP, с ними скорее следует связать использование Web браузеров в качестве клиентских приложений. Важно отметить при этом тот факт, что браузер не обязательно является HTML-"окном", но, в не меньшей степени, представляет собой универсальную среду загрузки объектных приложений/компонент -Java или ActiveX. Три модели, которые описаны выше, организации клиент-серверных систем в определенной степени считаются ориентирами в задании жесткости связей между различными функциональными компонентами, чем строго описываемыми программами в реальных проектах. Жесткость связей в схеме взаимодействия компонент системы зачастую определяется отсутствием (или наличием) транспортного или сетевого уровня (Transport Layer - TL), который обеспечивает обмен информацией между разными компонентами.

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

К первой группе пользователей относятся операторы информационных систем (ввод и редактирование информации), а также рядовые сотрудники и менеджеры, которые обращаются к поисковым и справочным механизмам (поиск и чтение данных). Ко второй группе пользователей относятся эксперты, аналитики и менеджеры управляющего звена, которым требуются как специфические возможности отбора информации, так и развитые средства ее анализа и представления. С точки зрения реализации моделей нужно обеспечить прозрачность взаимодействия между разными компонентами системы, а, это значит, обратиться к уже существующим стандартам такого взаимодействия. Любая прикладная система, не зависимая от выбранной модели взаимодействия, требует такой инструментарий, который смог бы существенно ускорить сам процесс создания системы и, одновременно с этим, обеспечить прозрачность и наращиваемость кода. На фоне разработки и внедрения систем корпоративного масштаба явно присутствует тенденция использования объектно-ориентированных компонентных средств разработки. Соответственно, полноценное применение объектов в распределенной клиент-серверной среде требует и распределенного объектно-ориентированного взаимодействия, то есть возможности обращения к удаленным объектам. Исходя из всего вышесказанного, мы приходим к анализу существующих распределенных объектных моделей. В настоящий момент наибольшей проработанностью отличаются COM/DCOM/ ActiveX и CORBA/DCE/Java. Если в первом случае механизмы, которые требуют поддержки модели, являются важной частью операционной платформы Win32 (Windows 95/NT/CE), то во втором случае предусмотрена действительная кроссплатформенность (к примеру, повсюду, где есть виртуальная машина Java). Предприняв попутку объективно оценить (хотя любая такая попытка во многом субъективна) перспективы использования этих моделей, то для этого нужно понять требования к операционным платформам, которые выдвигаются разными функциональными компонентами системы. Недостаточно обходиться разделением на три основных части PL, BL, AL , когда строишь реальные системы корпоративного масштаба. Ведь бизнес-логика является блоком, более емким и специфичным для каждого проекта, именно ее приходится делить на более мелкие составляющие. Такими составляющими могут быть, к примеру, функциональные компоненты обработки транзакций (Transaction Process Monitoring), обеспечения безопасности (Security) при наличии разграничения прав доступа и выходе в Internet (Fire-wall), публикование информации в Internet (Web-access), подготовки отчетов (Reporting), отбора и анализа данных в процессе принятия решений (Decision Support), асинхронного уведомления о событиях (Event Alerts), тиражирования данных (Replication), почтового обмена (Mailing) и др. Наличие большого числа функций, которые закладываются в блоки поддержки бизнес-логики, появляется определение сервера приложений (Application Server - AS). Причем, сервер приложений не просто является каким-то единым универсальным средним BL-звеном между клиентской и серверной частью системы, но AS существует во множественном варианте, как частично изолированные приложения, которые выполняют специальные функции, обладают открытыми интерфейсами управления и поддерживают стандарты объектного взаимодействия. Появление информационных технологий в сфере бизнеса в качестве неотъемлемого условия успешного управления приводит к тому, что системы корпоративных масштабов требуют сочетания разных клиент- серверных моделей в зависимости от задач, которые решаются на разных конкретных направлениях деятельности предприятия. Упомянув, опять, о правиле 20/80 можно придти к выводу, что наиболее оптимальным выбором, с точки зрения управляемости и надежности системы, считается сочетание различных моделей взаимодействия клиентской и серверной части. По сути, мы приходим даже не к трехуровневой, а многоуровневой (N-tier) модели, которая объединяет различные по "толщине" клиентов, серверы баз данных и множество специализированных серверов приложений, которые взаимодействуют на базе открытых объектных стандартов. Облегчением в использовании многоуровневых гетерогенных систем является активная работа ряда производителей программного обеспечения, направленная на создание переходного программного обеспечения. В отличие от продуктов middleware, которые обеспечивают верхний транспортный уровень (универсальные интерфейсы доступа к данным ODBC, JDBC, BDE; Message Oriented Middleware - MOM; Object Request Broker - ORB;), переходное ПО несет ответственность за трансляцию вызовов в рамках одного стандарта обмена в вызовы другого - мосты ODBC/JDBC и BDE/ODBC, COM/CORBA, Java/ActiveX.

3. Клиент-серверные вычисления

Эпоха централизованных вычислений на мэйнфреймах IBM, которые занимают более 70% в компьютерном бизнесе мира, пришлась на 1970-е и 1980-е года. На мэйнфреймах IBM выполнялись бизнес транзакции, деятельности и базы данных, запросы и техническое обслуживание. Этап перехода к клиент-серверным вычислениям показал другую совершенно концепцию и технологию реорганизации всего делового мира. «Волной будущего» называли вычислительные парадигмы 1990-х годов. Как правило, машина-клиент управляет интерфейсами процессов, таких как графический интерфейс (графический пользовательский интерфейс), отправкой запросов на сервер программ, проверкой данных, которые введены пользователями, а также управляет местными ресурсами, пользователи, в свою очередь, взаимодействуют с такими ресурсами, как монитор, клавиатура, рабочие станции, процессора и других периферийные устройства. Если посмотреть с другой стороны, сервер выполняет запрос клиента, используя службы. После того как сервер получил запросы от клиентов, он выполняет поиск базы данных, обновления и управляет целостностью данных и отправляет ответы на запрос клиентов. Целью клиент-серверных вычислений является разрешение каждой сетевой рабочей станции (клиента) и принимающей (сервера) быть доступными, в случае необходимости приложения, и так же обеспечивать доступ к уже существующему программному обеспечению и аппаратным компонентам от разных поставщиков для совместной работы. Когда эти два условия объединены, становится очевидным преимущества клиент-серверной архитектуры, такие как повышение производительности, экономия средств, использование ресурсов, повышение гибкости. Клиент-серверные вычисления имеют три составляющих компонента: клиентского процесса, запрашивающего обслуживание и серверного процесса предоставления запрашиваемых услуг, с Middleware между ними для их взаимодействия.

Как правило, пользовательским интерфейсом частей приложения, проверкой данных, введенных пользователем, отправкой запросов на сервер программы обычно управляет машина клиент. Помимо этого, клиентский процесс также управляет местными ресурсами, что в свою очередь позволяет пользователю взаимодействовать с монитором, клавиатурой, рабочими станциями, процессорами и другими периферийными устройствами. Сервер Машина - Сервер выполняет служебные запросы клиента. Поиск базы данных, обновления, управление целостностью данных и отправка ответов на запросы клиентов производит сервер после того как получает запросы от клиентов. На другой машине в сети может работать серверный процесс. В таком случае, сервер используется как файловая система услуг и приложений сервисов. Иногда в некоторых случаях, другой рабочий стол машины обеспечивает применение услуг. Сервер выступает в роли программного обеспечения двигателя, который управляет общим ресурсам, таким как базы данных, принтеры, линии связи, или процессоров высокой мощности. Основная цель серверного процесса это выполнение фоновых задач, являющимися общими для приложений. Самая простая форма серверов - это дисковый сервер и файл-сервер. В случае, когда клиент передает запросы на файл или группы файлов по сети на файловый сервер, эта форма обслуживания данных требует большой пропускной способности и может сделать медленнее сеть с большим количеством пользователей. Продвинутые более формы серверов - это серверы баз данных, сервер транзакций и серверов приложений. Middleware Middleware позволяет приложениям прозрачно взаимодействовать с другими программами или про цессами независимо от местоположения. Основным элементом Middleware считается NOS (Network Operating System), предоставляющая такие услуги, как маршрутизация, распределение, обмен сообщениями и управления сервисной сети. Опирается NOS на коммуникацию протоколов предоставления конкретных услуг. И прежде чем пользователь может получить доступ к услугам сети, клиент-серверный протокол требует установку физического соединения и выбор транспортных протоколов. Клиент-серверный протокол диктует, каким образом клиенты запрашивают информацию и услуги от сервера, а также как сервер отвечает на эту просьбу.

3.1 Пирамида модели «клиент-сервер»

Председатель Butler Group - Мартин Батлер, предложил иные рамки для реализации клиент-серверной стратегии. Это модель. Которая состоит из 5 слоев под названием VAL (Value Added Layers) Модель. Основная структура напоминает по форме пирамиду, со слоями Инфраструктура и Middleware в нижней части пирамиды, а приложения, хранилища и бизнес модели на вершине.

Характеристики каждого слоя:

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

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

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

Четвертый уровень – Хранилище. Роль хранилища - изоляция бизнес-модели / спецификации от технологических инструментов, которые используются для ее осуществления.

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

3.2 Важность сети

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

3.3 Открытые системы и стандарты

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

- OSF (Open Software Foundation) - некоммерческий консорциум компьютерных производителей, разработчиков программного обеспечения и поставщиков чипов для разработок, основанных на стандартах программного обеспечения.

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

- OMG - международные организации системы поставщиков, разработчиков программного обеспечения и пользователей, сторонники развертывания объекта управления технологиями в разработке программного обеспечения. Применяя общую основу для всех объектно-ориентированных приложений, организации смогут управлять гетерогенными средами. CORBA (Common Object Request Broker Architecture), разработанная OMG, DEC, NCR, HP и SUN является новым механизмом, который позволяет объектам (приложениям) называть друг друга по сети.

- SQL Access Group - это промышленный консорциум работает над определением и осуществления технических условий для гетерогенного доступа SQL данных с использованием принятых международных стандартов.

4. Модель клиент - сервер в Интернете

Взаимодействие клиента и сервера в Интернете осуществляется при помощи запросов, которые посылаются клиентом серверу, и ответов сервера на запрос клиента. Идея распределенных систем это связь между процессами, которые реализуют не только взаимодействие компьютеров, но и частей (уровней) приложений. Взаимодействие частей приложений реализуется с помощью протоколов, которые описывают состав и формат данных, пересылаемых соответствующими частями клиентских и серверных приложений друг другу для решения поставленной задачи. В интернете разделение приложений на части осуществляется на базе стека протоколов TCP/IP. В данной модели разработчики имеют большую свободу в определении того, какие части клиент-серверного приложения будут на клиентском компьютере и какие на сервере. Логика пользовательского интерфейса существовала почти исключительно на сервере. Мы можем снова приступить к использованию более эффективных и хорошо структурированных клиент- серверных моделей. Конечно же, есть еще технические вопросы, но мы в состоянии лучше строить истинные клиент-серверные приложений в настоящее время.

Рисунок 9 – Простейшая схема Intranet с архитектурой «Клиент – сервер»

Клиент-серверную модель можно разделить на три части :

- User Interface - пользовательский интерфейс

- Business or Application Logic - бизнес и логика приложения

- Data Management - управление данными.

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

- неудовлетворительное распределение обработки - с большим числом клиентов, делает все обработки на сервере неэффективно

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

- трудная модель программирования - программирование пользовательского интерфейса через клиент-сервер достаточно сложно.

Если правила доступа распространяются через пользовательский код интерфейса, то при росте кода пользовательского интерфейса возникают новые векторы атаки. Сложное управления на серверах. Offline трудности. Код пользовательского интерфейса должен выполняться на клиенте и в автономном ситуациях. Снижение возможностей для взаимодействия. Когда клиент-сервер состоит из передачи внутренней части пользовательского интерфейса в браузере, бывает очень трудно понять эту связь и использовать ее для других приложений. Нужно решить, какой код должен работать на клиенте, а какой на сервере. Коду пользовательского интерфейса лучше работать на браузере, а бизнес-логике и управлению данными лучше работать на стороне сервера. Хороший дизайн включает в себя создание объектов, которые инкапсулируют большую часть своего поведения и минимальной площади поверхности. Он должен быть понятным и легко взаимодействовать с хорошо разработанным интерфейсом объекта. Помимо этого, клиент-серверное взаимодействие должно быть построено на хорошо продуманном интерфейсе. Проектирование модульных удаленных интерфейсов часто называют сервис-ориентированной архитектурой (SOA). Клиент-серверная реализация высокого качества должна иметь простой интерфейс между клиентом и сервером. На стороне клиента обязан инкапсулировать презентации и код взаимодействия с пользователем. Код на стороне сервера должен инкапсулировать правила поведения и взаимодействия данных. Веб-приложения должны быть разделены на два основных элемента, веб-сервис и пользовательский интерфейс.

Плюсы чистой модели клиент-сервер:

- масштабируемость. Чем больше клиентов, использующих приложения, тем больше клиентских машин, которые доступны, в то время как сервер остается постоянным.

- мгновенный ответ пользователя. Клиентский код может немедленно отзываться на действия пользователя, но не ждать для передачи данных по сети.

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

Автономные приложения. В том случае, когда большая часть кода для приложений уже сконструирована, чтобы работать на клиенте, создание автономной версии приложения будет легче, скорее всего.

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

5. Развитие

5.1 Клиент-серверные вычисления

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

5.2 Трехуровневая архитектура

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

В трехуровневой архитектуре клиент, как правило, не перегружен функциями обработки данных, а выполняет свою главную роль системы представления информации, которая поступает с сервера приложений. Такой интерфейс можно использовать с помощью стандартных средств Web-технологии - браузера, CGI и Java. Это уменьшает тот объем данных, который передается между клиентом и сервером приложений, а это, в свою очередь, позволяет подключать клиентские компьютеры даже по самым медленным линиям типа телефонных каналов. Кроме того, клиентская часть может быть настолько простой, что в большинстве случаев ее реализуют с помощью универсального браузера. Но если менять ее все-таки придется, то эту процедуру можно осуществить быстро и безболезненно.

Сервер приложений – это программное обеспечение, которое является промежуточным слоем между клиентом и сервером.

Рисунок 10 - Сервер приложений

Существует несколько категорий продуктов промежуточного слоя:

- Message orientated – яркие представители MQseries и JMS;

- Object Broker – яркие представители CORBA и DCOM;

- Component based – яркие представители.NET и EJB.

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

Существует несколько серверов приложений от таких знаменитых компаний как Sun Microsystem, Borland, IBM, Oracle и каждый из них отличается набором предоставляемых сервисов (производительность в данном случае учитывать не будем). Эти сервисы облегчают программирование и развертывание приложений масштаба предприятия. Обычно сервер приложений предоставляет следующие сервисы:

- WEB Server – чаще всего включают в поставку самый популярный и мощный Apache;

- WEB Container – позволяет выполнять JSP и сервлеты. Для Apache таким сервисом является Tomcat;

- CORBA Agent – может предоставлять распределенную директорию для хранения CORBA объектов;

- Messaging Service – брокер сообщений;

- Transaction Service – уже из названия понятно, что это сервис транзакций;

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

- Java Mail – данный сервис может предоставлять сервис к SMTP;

- JMS (Java Messaging Service) – обработка синхронных и асинхронных сообщений;

- RMI (Remote Method Invocation) - вызов удаленных процедур.

Многоуровневые клиент-серверные системы достаточно легко можно перевести на Web-технологию - для этого достаточно заменить клиентскую часть универсальным или специализированным браузером, а сервер приложений дополнить Web-сервером и небольшими программами вызова процедур сервера. Для разработки этих программ можно использовать как Common Gateway Interface (CGI), так и более современную технологию Java.

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

Из всего вышесказанного можно сделать вывод, что двухуровневая архитектура сильно уступает многоуровневой архитектуре, поэтому в настоящее время используется только многоуровневая архитектура «Клиент – сервер», в которой различают три модификации - RDA, DBS и AS, о которых мы говорили выше.

ЗАКЛЮЧЕНИЕ

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

В данной курсовой работе мы рассмотрели различные архитектуры клиент-серверных технологий. Выявили их плюсы и минусы.

Разобрались в понятиях толстый и тонкий клиент. Определили слои, из которых складывается пирамида модели «клиент-сервер».

Узнали какую роль играет клиент – серверная архитектура в интернет технологиях.

Цель курсовой работы в рассмотрении технологии «клиент-сервер» полностью достигнута.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Л. Калиниченко. Стандарт систем управления объектными базами данных ODMG 93: краткий обзор и оценка состояния. - СУБД, 1, 1996.
2. Д. Брюхов, В. Задорожный, Л. Калиниченко и др. Интероперабельные информационные системы: архитектуры и технологии. - СУБД, 4, 1995.
3. Вудворд Дж. «Технология совместной работы»
4. Волков В.Б. Понятный самоучитель работы в Windows XP, СПб, Питер, 2004

5.http://www.feip.ru/2008/12/27/arkhitektura-klient-server.html 6.http://www.osp.ru/text/print/302/142618.html 7.http://mf.grsu.by/other/lib/klients/tonk_kl.htm 15.http://www.pcmag.ru/issues/detail.php?ID=8196