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

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 на коммуникацию протоколов предоставления конкретных услуг. И прежде чем пользователь может получить доступ к услугам сети, клиент-серверный протокол требует установку физического соединения и выбор транспортных протоколов. Клиент-серверный протокол диктует, каким образом клиенты запрашивают информацию и услуги от сервера, а также как сервер отвечает на эту просьбу.