Файл: Технология «Клиент-Сервер».pdf

Внутренняя конкуренция призвана исправить недостатки традиционного метода ведения бизнеса. В [9] отмечается, что «Американские корпорации являются одними из самых крупных социалистических бюрократий в мире. Они характеризуются централизованным планированием, централизованным владением капитала, централизованным распределением ресурсов, субъективной оценкой труда, отсутствием внутренней конкуренции и склонностью принимать решения в ответ на политическое давление».

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

Таблица 1 - Достоинства и недостатки архитектуры клиент-сервер

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

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

Взаимодействие клиента и сервера обеспечивается коммуникационным программным обеспечением. Примерами такого программного обеспечения являются набор протоколов TCP/IP,- протоколы OSI, а также различные фирменные архитектуры, вроде SNA.

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

INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image1.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image1.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image1.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image1.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image1.jpeg" \* MERGEFORMAT INCLUDEPICTURE "/Volumes/HD2/mfpu/%D0%BA%D1%83%D1%80%D1%81%D0%BE%D0%B2%D1%8B%D0%B5/User/AppData/Local/Temp/FineReader10/media/image1.jpeg" \* MERGEFORMATINET INCLUDEPICTURE "../../../%25D0%25BA%25D1%2583%25D1%2580%25D1%2581%25D0%25BE%25D0%25B2%25D1%258B%25D0%25B5/User/AppData/Local/Temp/FineReader10/media/image1.jpeg" \* MERGEFORMAT

Рис. 2 – Общая архитектура клиент – сервер

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

Модуль услуг представления не следует путать с уровнем представления эталонной модели OSI. Уровень представления занимается форматированием данных для их корректной интерпретации каждым из двух взаимодействующих компьютеров. Модуль услуг представления имеет дело с взаимодействием пользователя и приложения, а также с функциональностью графического интерфейса пользователя.6

1.5. Базы данных

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

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

INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image2.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image2.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image2.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image2.jpeg" \* MERGEFORMAT INCLUDEPICTURE "../../User/AppData/Local/Temp/FineReader10/media/image2.jpeg" \* MERGEFORMAT INCLUDEPICTURE "/Volumes/HD2/mfpu/%D0%BA%D1%83%D1%80%D1%81%D0%BE%D0%B2%D1%8B%D0%B5/User/AppData/Local/Temp/FineReader10/media/image2.jpeg" \* MERGEFORMATINET INCLUDEPICTURE "../../../%25D0%25BA%25D1%2583%25D1%2580%25D1%2581%25D0%25BE%25D0%25B2%25D1%258B%25D0%25B5/User/AppData/Local/Temp/FineReader10/media/image2.jpeg" \* MERGEFORMAT

Рис. 3 - Архитектура клиент-сервер для баз данных

На рис. 3 предполагается, что вся прикладная логика — программы для обработки и анализа данных — располагается на клиентской стороне, тогда как сервер занимается только управлением базой данных. Приемлемость такой конфигурации зависит от стиля и задачи конкретного приложения. Предположим, например, что основная цель приложения заключается в обеспечении доступа для поиска записей в режиме подключения (on-line). Пример работы такой схемы показан на рис. 4, а. Предположим, что сервер управляет базой данных, содержащей один миллион записей (на жаргоне реляционных баз данных называемых строками), и пользователь хочет выполнить операцию поиска, результатом которой может быть нуль записей, одна запись или небольшое количество записей. Пользователь может искать эти записи по нескольким критериям поиска (например, записи, сделанные ранее 1992 года; записи, касающиеся жителей штата Огайо; записи, относящиеся к специфическим событиям или характеристикам, и т. д.). Начальный запрос клиента вызывает ответ сервера о том, что в базе данных содержится 100 000 записей, удовлетворяющих критериям поиска.

При этом пользователь задает дополнительные критерии, и посылает новый запрос. На этот раз сервер отвечает, что в базе данных содержится 1000 записей, удовлетворяющих критериям поиска. Наконец, клиент посылает третий запрос с дополнительными критериями. Результатом поиска на этот раз является одна запись, которая возвращается клиенту.8

Рис. 4 - Использование базы данных в архитектуре клиент-сервер

Данное приложение хорошо соответствует архитектуре клиент-сервер по двум причинам.

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

Рассмотрим теперь рис. 4, б, который иллюстрирует сценарий работы с той же самой базой данных, содержащей миллион записей. В этом случае в результа­те одного запроса пользователю по сети пересылается 300 000 записей. Такое может случиться, если, например, пользователь захочет определить сумму или среднее значение определенного поля в большом множестве записей или даже во всей базе данных.7

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

1.6. Классы приложений клиент-сервер

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

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

На рисунке изображены четыре класса приложений с разными вариантами распределения задач между сервером и клиентом.

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

1.7. Трехзвенная архитектура клиент-сервер

Традиционная архитектура клиент-сервер состоит из двух уровней, или звеньев: клиентского и серверного. В последние годы все большее распространение получает трехзвенная архитектура клиент-сервер (рис. 5). В данной архитектуре прикладное программное обеспечение распределено между машинами трех типов: пользовательской машиной, промежуточным сервером и сервером базы данных. Машина пользователя представляет собой клиента, и в трехзвенной модели это, как правило, «тонкий» клиент. Промежуточные машины являются, по существу, шлюзами между «тонкими» клиентами и разнообразными серверами баз данных. Промежуточные машины должны уметь преобразовывать протоколы и отображать одни типы запросов к базам данных на другие. Вдобавок промежуточные машины должны объединять результаты запросов от различных источников данных. Наконец, эти машины должны играть роль шлюзов между настольными приложениями и оставшимися у организации со старых времен системами управления базами данных, таким образом, являясь посредниками между двумя «мирами». По существу, такая архитектура означает интеграцию приложений предприятия (EnterpriseApplicationIntegration, EAI).6