О понятии «тонкий клиент»
В последнее время от пользователей систем электронного архива и документооборота достаточно часто приходится слышать требования, касающиеся обеспечения работы с использованием «тонкого клиента». При этом далеко не все выдвигающие подобное требование ясно представляют себе, что же такое «тонкий клиент» и чем работа с его использованием отличается от работы через
Начнем с определения. Термин «тонкий клиент» возник сравнительно недавно и поначалу относился скорее к области «компьютерного» жаргона. Искать его трактовку в толковых словарях — дело заведомо безнадежное,
Надеемся, нашим читателям знакома следующая особенность построения баз данных архитектуры «клиент-сервер» и трехзвенной архитектуры: в идеале все процессы выполняются на сервере посредством отработки хранимых процедур сервера. Обращение к серверу СУБД в архитектуре «клиент-сервер» реализуется через интерфейс клиентского места, а в случае трехзвенной архитектуры осуществляется обращение с клиентского места к серверу приложений, который в свою очередь обращается к СУБД. При этом сервер СУБД и сервер приложений физически располагаются на мощных аппаратных средствах, отличных от «клиентских» рабочих станций, что позволяет обрабатывать большое число запросов и управлять большими объемами информации БД без нагрузки на рабочие станции.
Различные источники приводят разные определения «тонкого клиента». Иногда эти определения достаточно противоречивы — даже в рамках одного и того же источника.
- В компьютерных технологиях «тонкий клиент» (thin client) — это
компьютер-клиент сети с архитектурой «клиент-сервер», который переносит большинство задач по обработке информации на сервер [1]. - В том же источнике, только его англоязычной версии, приводится следующее определение: «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-браузер и/или подключение к удаленному рабочему столу посредством клиента терминальных сервисов. - «Тонкий клиент» — это такая многопользовательская серверная модель, в которой 100% приложений выполняются на сервере [3].
Можно привести и множество других определений, но все они либо дополняют, либо взаимоисключают друг друга.
Давайте предпримем небольшой экскурс в историю. В старые добрые времена мейнфреймов доступ к многопользовательской среде осуществлялся через локальные и удаленные терминалы. Именно этим устройствам суждено было стать прообразом решений, объединенных сегодня термином «тонкий клиент». Итак, это решения, имеющие в своем составе устройства ввода (клавиатура, мышь, считыватель смарт-
Антиподом «тонкого» является «толстый» клиент, в определениях которого противоречия встречаются реже. Приведем одно из них: «„Толстый клиент“ производит обработку информации независимо от сервера, используя последний в основном лишь для хранения данных» [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 отсутствием сервера приложений. Считаем, что иллюстрировать ее отдельно не стоит. В случае двухзвенной архитектуры «клиент-сервер» запрос к серверу СУБД, формируемый через интерфейс клиентских мест, поступает «напрямую». При этом так же как и в трехзвенной архитектуре запускаются и отрабатываются обработчики сервера СУБД — триггеры и хранимые процедуры.
При интенсивном использовании информационной системы использование сервера приложений снимает нагрузку с сервера СУБД, что положительно влияет на быстродействие и качество всей системы. В ряде случаев целесообразно использование нескольких серверов приложений. С другой стороны, отсутствие элементарной информации о назначении и принципе работы серверов приложений в совокупности с рекламными акциями
Несомненно, целесообразность применения трехзвенной архитектуры определяется количеством одновременно работающих клиентов, интенсивностью их доступа, «размером» базы данных, возможностями используемой СУБД и, конечно же, решаемыми задачами, определяющими степень использования ресурсов сервера. Четких количественных критериев здесь не существует. Например, при оптимальной конфигурации системы, достаточных ресурсах сервера и использовании СУБД Oracle полнофункциональные рабочие места системы электронного архива и документооборота устойчиво работают на 300−600 полнофункциональных рабочих станциях. При этом таблицы СУБД могут содержать миллионы записей, а архитектура системы — быть двухзвенной без использования серверов приложений.
Если появилась необходимость решить для большого количества пользователей специфические и более «узкие» задачи (например, обеспечить доступ в систему электронного архива только на просмотр), целесообразно для той же базы данных использовать сервер приложений или
Надеемся, что все сказанное поможет сделать правильный выбор и сэкономить средства.
Насколько «тонок» web-доступ
Из предыдущего раздела статьи не следует делать вывод, что доступ к базе данных системы электронного архива и документооборота, организованный через окно браузера, делает ненужным рассмотрение любой системы электронного архива и документооборота, предоставляющей информацию «не в окне браузера».
Отметим явные недостатки
Производительность обработки данных на сервере при обращении к базе через браузер такая же, как через «не web"-клиента, а вот возможности отображения информации гораздо ниже и определяются следующим:
- Внешний вид
HTML-страницы ограничен стандартным для браузера набором элементов. Производительность работы при отображении ниже, чем в альтернативном клиенте, поскольку применяемыев web-браузере HTML и JavaScript не позволяют быстро «отрисовывать» динамически изменяющуюся информацию. - Как известно,
web-браузер не отображает векторные форматы, не говоря уже о сборках — многофайловых связанных структурах, получаемых в современных САПР. При просмотре однофайловых документов и чертежей можно, конечно, воспользоваться гиперссылкой и открыть файл в соответствующем приложении, проинсталлированном в системе, но такой способ исключает возможность доступа с любого компьютера. Открыть же трехмерную сборку невозможно еще и потому, что это требует инсталляции в операционной системе не только САПР (или соответствующего средства просмотра), но и специального интерфейса, позволяющего «собрать» все файлы вложенных сборок и деталей с учетом имеющихся связей. Одно только создание такого интерфейса, работающего черезweb-доступ , является достаточно трудоемкой и дорогостоящей задачей.
Существуют технологии, позволяющие частично решить указанные проблемы. Все эти технологии переносят часть процессов по обработке информации на клиентское место. Они предоставляют возможность
Использование JAVA-приложений и объектов ActiveX
Для решения некоторых задач обработки документов с использованием
К минусам использования данной технологии следует отнести и то, что в настройках
При доступе через
Не вдаваясь в технические подробности, вкратце поясним суть работы ActiveX.
Технология использует специальные приложения, хранящиеся на сервере (например, в виде OCX-файлов) и создаваемые практически в любых современных средах программирования. При написании могут использоваться
Описываемая технология имеет ряд особенностей, которые в случае систем электронного архива и документооборота правильнее назвать недостатками:
- реализовать компонент ActiveX, позволяющий полноценно решать в окне
web-браузера все задачи систем электронного архива и документооборота, — дело довольно трудоемкое и недешевое; - размер
файла-компонента ActiveX, решающего серьезные задачи, достаточно велик. Не называя конкретного продукта, дабы не навлечь на себя подозрений в антирекламе, приведем такой пример: в одной из систем размерActiveX-приложения , работающего в окнеweb-браузера , достигает 25 Mб. Напомним, что при первом обращении к странице, работающей с ActiveX, этот файл должен быть загружен на клиентскую рабочую станцию. Закачивать такой объем по низкоскоростным, в том числе и коммутируемым каналам связи, мягко говоря, неудобно. Если же канал позволяет быстро загружать такие файлы, следует вполне логичный вопрос: «А зачем в таком случаеweb-доступ и почему не использовать «не web"-клиентское приложение?»
Возможный ответ звучит так: «Но ведь все равно кроме браузера и единожды загружаемого ActiveX ничего не требуется». Ниже мы предлагаем некоторые комментарии к подобной точке зрения:
ActiveX-компонент , по сути являясь отдельным приложением, автоматически инсталлируется в операционной системе после первой загрузки. Кроме того:- возникает ограничение по используемой операционной системе клиентского места: она должна быть совместима с той, для которой создавался ActiveX;
- как уже сказано, для работы с файлами и сборками, получаемыми в двумерных и трехмерных САПР, при написании ActiveX используются
API-библиотеки этих САПР. Таким образом, для работы ActiveX на клиентском месте недостаточно одной только соответствующей операционной системы — необходимо еще и наличиеAPI-библиотек . Другими словами, должны быть проинсталлированы соответствующие САПР (а значит «толщина» клиента возрастает); - еще раз напомним, что в настройках
web-браузеров современных операционных систем загрузка и инсталляция ActiveX по умолчанию запрещены. Конечно, при наличии необходимых прав и должной квалификации пользователь может, понизив уровень безопасности, обеспечить загрузку, инсталляцию и исполнениеActiveX-компонентов в окне браузера, но тем самым он откроет доступ и вредоносным программам.
Принцип целесообразности
Таким образом, полноценная работа со всеми функциями системы электронного архива и документооборота при попытках использовать
Теперь постараемся сформулировать наши подходы к использованию
Несомненно,
Большинству пользователей системы электронного архива и документооборота, выражающих обоснованное желание работать через
Реализация web-доступа для системы управления технической информацией и документацией TDMS
Компания CSoft
Среди реализованных проектов — внедрение системы электронного архива ОАО «Гипроспецгаз», системы электронного архива ОАО «Красный Октябрь», системы электронного архива и документооборота ЗАО «ГТ-Инспект», системы электронного архива и документооборота с элементами PDM ЗАО «ЦНИИ СМ» и многие другие.
Существенное место в проводимой работе занимает реализация технологий поддержки жизненного цикла изделий и объектов. Мы неоднократно представляли наши подходы к созданию подобных систем и рассказывали об их успешных реализациях в среде TDMS, учитывающих различные задачи на разных этапах жизненного цикла (управление проектированием, строительные модели, системы логистической поддержки с элементами статистического анализа [5]).
Важной частью нашего подхода к внедрению
В связи с вопросами реализации
Руководствуясь этими принципами, компания CSoft
- после соответствующей идентификации пользователя (рис. 2) доступ осуществляется через
web-интерфейс с любой машины сети; - возможен поиск по атрибутивной информации документов;
- осуществляется полнотекстовый поиск;
- осуществляется маршрутизация документа в процессе документооборота, рассылки извещений и сообщений;
- возможно редактирование атрибутивной информации;
- допустимо редактирование части файлов документов (не требующее инсталляции дополнительных программных средств, несущих большую нагрузку на клиентскую рабочую станцию).
Использование TDMS WEB Access не исключает применения полнофункционального «не web"-клиента. Для выполнения задач, требующих реализации функций, ресурсоемких как для клиентского рабочего места, так и для бюджета, на предприятии используется «не web"-доступ в двухзвенной архитектуре «клиент-сервер».
На рис. 3 показан процесс идентификации при доступе к БД TDMS с карманного компьютера (Pocket PC). Отметим, что на карманном компьютере не потребовалось дополнительной инсталляции каких бы то ни было программных средств.
Использование терминального клиента
Постараемся ответить читателям, формулирующим следующую задачу: необходим удаленный доступ с использованием «тонкого клиента» ко всему функционалу системы электронного архива и документооборота, несмотря на то что
Вернемся к одному из определений, приведенному в начале статьи: «„тонкий клиент“ представляет собой компьютер — клиент сети, который переносит большинство задач по обработке информации на сервер», после чего внимательно изучим рис. 4, иллюстрирующий удаленный доступ к рабочему столу компьютера, на котором проинсталлирован стандартный клиент TDMS (не осуществляющий
Общая схема работы в системе электронного архива и документооборота с использованием терминального доступа показана на рис. 5 и поддерживает следующий принцип работы:
- на клиентском рабочем месте системы электронного архива и документооборота в локальной сети устанавливается серверная часть службы терминалов, являющаяся стандартным компонентом операционной системы;
- на том же клиентском рабочем месте устанавливается клиентское приложение системы электронного архива и документооборота. Оно может поддерживать или не поддерживать
web-доступ — в данном случае это совершенно ни на что не влияет; - на том же клиентском месте инсталлируются все приложения, необходимые пользователю: например, средства работы с векторными документами, двумерными и трехмерными САПР
и т.д. ; - на удаленных рабочих местах настраиваются клиенты службы терминалов;
- между клиентским рабочим местом с серверной частью службы терминалов и рабочими местами с клиентами службы терминалов организуется канал, который может быть выделенным, GPRS, ADSL, коммутируемым (модемным) соединением с корпоративной сетью или Internet.
При помощи терминальных клиентов удаленных рабочих мест осуществляется полноценное управление клиентским рабочим местом системы электронного архива и документооборота с сервером терминалов (рис. 5).
Выделим случаи наиболее целесообразного, на наш взгляд, использования доступа через клиента службы терминалов:
- при необходимости использовать сложный ресурсоемкий функционал, инсталлированный на рабочей станции, являющейся сервером терминального доступа;
- в случае невозможности изменить конфигурацию клиентского компьютера (например, когда по соображениям безопасности нельзя инсталлировать ActiveX, необходимые даже для
web-доступа , или когда используемая операционная система или ресурсы удаленной рабочей станции в принципе не позволяют выполнить необходимые инсталляции); - при необходимости повысить уровень доступа к рабочей станции — серверу терминального доступа (которая может находиться и в помещении, ограниченном для физического доступа).
Справедливости ради отметим и некоторые принципиальные недостатки данного подхода:
- в случае одновременной работы нескольких клиентов нагрузка на сервер терминального доступа может оказаться очень высокой;
- могут возникать проблемы с лицензированием как программного обеспечения электронного архива, так
и САПР-систем , поскольку одна приобретенная копия одновременно используется несколькими сотрудниками; - возрастает нагрузка на канал, так как по сети передаются не только необходимые команды и результаты, но и все действия пользователя (например, каждое движение «мыши») и весь вывод сервера (например, отрисовка 3D-модели).
Авторы выражают искреннюю благодарность О. Турецкому (НТЦ «Механотроника») за полезные советы и помощь при подготовке статьи, а также Д. Осипову (OAO «Балтийский завод»), идеи и подход которого к данной проблематике позволили взглянуть на нее под другим углом.
Источники и литература
- Википедия — проект свободной многоязычной энциклопедии.
Internet-ресурс . Открытый доступ, русскоязычный раздел (http://ru.wikipedia.org). - Википедия — проект свободной многоязычной энциклопедии.
Internet-ресурс . Открытый доступ, англоязычный раздел (http://en.wikipedia.org). - Understanding Thin-Client/Server Computing (Joel Kanter, Microsoft Press, 1998).
- Free
On-Line Dictionary of Computing. —Internet-ресурс . Открытый доступ (http://foldoc.org). - А.А. Рындин,
Л.М. Рябенький ,А.А. Тучков ,И.Б. Фертман . Ступени внедренияИПИ-технологий . — CADmaster,№ 1 /2006. - И.Б. Фертман,
А.А. Тучков ,А.А. Рындин . Ступени внедренияИПИ-технологий . Опыт реализации электронного документооборота (материалы конференции «МОРИНТЕХ-ПРАКТИК. Информационные технологии в судостроении-2006»). — СПб, 2006 (www.csoft.spb.ru/Articles/IPI_1.htm).