Разумная экономия: выбор тонкого клиента

Насколько «тонок» клиент

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

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

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

В различных источниках приведены несколько отличающихся определений «тонкого клиента». Иногда они достаточно противоречивы (даже в пределах одного и того же источника). Приведем примеры.

1. В компьютерных технологиях тонкий клиент (thin client) — это компьютер-клиент сети с архитектурой клиент-сервер, который переносит большинство задач по обработке информации на сервер.[1]
2. В том же источнике, только его англоязычной версии приведено следующее определение: A thin client is a computer (client) in client-server architecture networks which has little or no application logic, so it has to depend primarily on the central server for processing activities. The word «thin» refers to the small boot image which such clients typically require — perhaps no more than required to connect to a network and start up a dedicated web browser or «Remote Desktop» connection such as X11, Citrix ICA or Microsoft RDP. In contrast, a thick or fat client does as much processing as possible and passes only data required for communications and archival storage to the server. [2] Во втором определении, уже указываются конкретные службы и средства доступа – WEB – браузер и (или) подключение к удаленному рабочему столу посредством клиента терминальных сервисов.
3. Тонкий клиент — это такая многопользовательская серверная модель, в которой 100% приложений выполняются на сервере [3].
4. Можно привести еще множество определений понятия «тонкого клиента», но все они либо дополняют друг друга, либо взаимоисключают друг друга.

Давайте проведем небольшой экскурс в историю. В добропорядочные времена мейнфреймов доступ к многопользовательской среде осуществлялся через терминалы, локальные и удаленные. Именно этим устройствам суждено было стать прообразом устройств, на сегодняшний день объединенных под термином «тонкий клиент». Т.е. это устройства, имеющие в своем составе устройства ввода (клавиатура, мышь, считыватель смарт-карт, флэш-карт и т.д.), устройства вывода (монитор, принтер, колонки и т.д.) и средства подключения к серверу (адаптер сети Ethernet, адаптер последовательной линии связи или модем). В качестве примера можно привести “тонкие клиенты” фирмы “AK systems”. Именно поэтому определение [3] является абсолютно обоснованным. Нo сегодня понятие “тонкого клиента” не ограничивается данным определением. Нам больше импонирует определение «тонкого клиента», данное в Free On-Line Dictionary of Computing: “A simple client program or hardware device which relies on most of the function of the system being in the server” [4] Т.е. в качестве «тонкого клиента» может выступать и полноценная рабочая станция, имеющая в своем составе ПО, иммитирующее режим «тонкого клента». С развитим WEB технологий, для доступа к WEB-узлам (серверам) стандартом де-факто стало использование Web-браузера. Именно поэтому появилось отожествление понятия «тонкого клиента» и Web-браузера.

«Толстый клиент» является антиподом «тонкого». В определениях «толстого клиента» противоречия встречаются реже. Приведем одно из них: «Толстый клиент» производит обработку информации независимо от сервера, используя последний в основном лишь для хранения данных. [1]

Не станем дальше заниматься приведением определений и поиском противоречий в них, а будем говорить ниже лишь о «толщине» тонкого клиента – степени распределения нагрузки по обработке информации между клиентским приложением и сервером СУБД в двухзвенной архитектуре и между клиентским приложением, сервером приложений и сервером СУБД в трехзвенной архитектуре. Причем, все изложение будем строить на практическом применении в системах электронного архива и документооборота.

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

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

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

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

Для дальнейшей «расстановки точек над i», позволим себе прокомментировать одно из устоявшихся мнений. Большинство пользователей (как существующих, так и перспективных) систем электронного архива и документооборота часто считают, что «тонкий клиент» обязательно должен быть реализован через WEB – браузер, считая понятия WEB – доступа и тонкого клиента абсолютно идентичными. На наш взгляд, применительно к системам электронного архива и документооборота, такое мнение не всегда корректно.

Совершенно понятным является то, почему, на первый взгляд, оптимальным клиентским приложением для реализации тонкого клиента мог бы являться Web–браузер. Действительно, в большинстве современных операционных систем он является их неотъемлемой частью и не требует дополнительной инсталляции, HTML страницы одинаково отображаются в различных операционных системах и могут передаваться по любым каналам связи. Работа через браузер удобна и привычна для большинства пользователей. Общую схему работы системы электронного архива и документооборота с использованием WEB – доступа иллюстрирует рис. 1. Подобная схема применима и к трехзвенной архитектуре (в этом случае, промежуточным звеном между сервером СУБД и клиентскими рабочими станциями является сервер приложений). Схема работает следующим образом:

• запрос с клиентской рабочей станции, формируемый через интерфейс клиентского рабочего места (в случае WEB – доступа – через WEB – браузер), поступает на сервер приложений (или WEB-сервер, в случае WEB – доступа);
• сервер приложений (в случае WEB–доступа – WEB–сервер) производит обработку запроса, при необходимости решает прикладные задачи и передает запрос серверу СУБД. Примером прикладной задачи, решаемой сервером системы WEB–доступа к системе электронного архива и документооборота TDMS, является формирование и передача СУБД запросов для маршрутизации документов между пользователями в процессе их разработки (обработки);
• СУБД отрабатывает запрос и возвращает результат серверу приложений, который отправляет клиенту результаты в понятном тому виде. В случае же WEB–доступа, Web-сервер должен дополнительно представить результаты в виде страниц, «понятных» WEB – браузеру, например, используя технологию ASP или PHP.

При отработке запроса используются специальные средства «клиент-серверных» СУБД (Oracle, Microsoft SQL Server, Interbase и прочих) – хранимые процедуры и триггеры, реализованные на специализированных расширениях языка запросов (SQL), являющиеся неотъемлемой частью СУБД (для Oracle – PL/SQL, для Microsoft SQL Server — Transact SQL). Как правило, хранимые процедуры – специальные блоки программного кода, теоретически позволяющие производить любую обработку данных на сервере. СУБД получает команду от сервера приложений на запуск той или иной хранимой процедуры.

Повторим, что для «ресурсоемких» систем с интенсивным доступом, для снятия нагрузки с сервера СУБД, далеко не всю обработку целесообразно проводить с хранимыми процедурами сервера СУБД. Необходимая часть обработки в трехзвенной архитектуре производится сервером приложений.

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

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

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

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

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

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

Несомненно, целесообразность применения трехзвенной архитектуры определяется стоящими перед системой задачами, количеством одновременно работающих клиентов, интенсивностью их доступа, «размером» базы данных, возможностями используемой СУБД и, конечно же, решаемыми задачами, определяющими степень использования ресурсов сервера. Четких количественных критериев не существует. При достаточных ресурсах сервера, полнофункциональные рабочие места системы электронного архива и документооборота, например, при оптимальной конфигурации системы, устойчиво работают при использовании СУБД Oracle на 300-600 полнофункциональных рабочих станциях. При этом в таблицах СУБД могут содержаться миллионы записей, а архитектура системы может быть двухзвенной без использования серверов приложений.

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

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

Зачем устанавливать тонкий клиент, если можно обойтись обычным ПК?

— это дешевле на начальном этапе: внутри тонкого клиента установлено меньше железа, и ему не нужно быть мощным. Если вы приобретаете оборудование с нуля, это более выгодное решение;

— это дешевле в долгосрочной перспективе: тонкий клиент в среднем потребляет 10 Ватт, и этим выгодно отличается от компьютера, которому в среднем нужно от 250 до 350 Ватт;

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

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

— так надежнее: вся пользовательская информация хранится на сервере и резервируется, что снижает риск потери всех данных при сбое;

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

Перейдем к конкретным моделях тонких клиентов.

Преимущества тонкого клиента

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

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

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

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

Где использовать

Чаще всего thin client выбираются компаниями, в которых существует разветвленная ИТ-инфраструктура и есть множество отделов, где сотрудники выполняют однотипные задачи:

• работают с БД и сбором информации;
• обновляют ассортимент интернет-магазинов и аптек;
• проводят банковские операции и т. д.

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

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

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

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

Аренда терминального сервера – отличная альтернатива покупке дорогостоящего компьютерного оборудования. Клиент приобретает готовую систему на базе Windows, предназначенную для корпоративных пользователей. Работники компании получат облачный доступ к стандартным приложениям ОС и специализированным программам (1С: Бухгалтерия, PayDox и т.д.).

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

Что же это такое – тонкий клиент?

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

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