CADmaster

О понятии «тонкий клиент»

В последнее время от пользователей систем электронного архива и документооборота достаточно часто приходится слышать требования, касающиеся обеспечения работы с использованием «тонкого клиента». При этом далеко не все выдвигающие подобное требование ясно представляют себе, что же такое «тонкий клиент» и чем работа с его использованием отличается от работы через 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].

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

Давайте предпримем небольшой экскурс в историю. В старые добрые времена мейнфреймов доступ к многопользовательской среде осуществлялся через локальные и удаленные терминалы. Именно этим устройствам суждено было стать прообразом решений, объединенных сегодня термином «тонкий клиент». Итак, это решения, имеющие в своем составе устройства ввода (клавиатура, мышь, считыватель смарт- и флэш-карт и т.д.), устройства вывода (монитор, принтер, колонки и т.д.) и средства подключения к серверу (адаптер сети Ethernet, адаптер последовательной линии связи или модем). В качестве примера можно привести «тонкие клиенты» фирмы AK systems. Именно поэтому третье из приведенных определений является абсолютно обоснованным. Правда, сегодня понятие «тонкого клиента» этим определением не исчерпывается, и нам больше импонирует определение, данное в 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].

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

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

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

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

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

Позволим себе прокомментировать одно из устоявшихся мнений. Считая понятия 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 отсутствием сервера приложений. Считаем, что иллюстрировать ее отдельно не стоит. В случае двухзвенной архитектуры «клиент-сервер» запрос к серверу СУБД, формируемый через интерфейс клиентских мест, поступает «напрямую». При этом так же как и в трехзвенной архитектуре запускаются и отрабатываются обработчики сервера СУБД — триггеры и хранимые процедуры.

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

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

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

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

Рис. 1. Общая схема работы системы электронного архива и документооборота с использованием web-доступа

Насколько «тонок» web-доступ

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

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

Производительность обработки данных на сервере при обращении к базе через браузер такая же, как через «не web"-клиента, а вот возможности отображения информации гораздо ниже и определяются следующим:

• Внешний вид HTML-страницы ограничен стандартным для браузера набором элементов. Производительность работы при отображении ниже, чем в альтернативном клиенте, поскольку применяемые в web-браузере HTML и JavaScript не позволяют быстро «отрисовывать» динамически изменяющуюся информацию.
• Как известно, web-браузер не отображает векторные форматы, не говоря уже о сборках — многофайловых связанных структурах, получаемых в современных САПР. При просмотре однофайловых документов и чертежей можно, конечно, воспользоваться гиперссылкой и открыть файл в соответствующем приложении, проинсталлированном в системе, но такой способ исключает возможность доступа с любого компьютера. Открыть же трехмерную сборку невозможно еще и потому, что это требует инсталляции в операционной системе не только САПР (или соответствующего средства просмотра), но и специального интерфейса, позволяющего «собрать» все файлы вложенных сборок и деталей с учетом имеющихся связей. Одно только создание такого интерфейса, работающего через web-доступ, является достаточно трудоемкой и дорогостоящей задачей.

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

Использование JAVA-приложений и объектов ActiveX

Для решения некоторых задач обработки документов с использованием web-интерфейса в системах электронного архива и документооборота можно использовать специальные программы, загружаемые на рабочую станцию с сервера и выполняющиеся в окне web-браузера. На сегодня существуют две альтернативные технологии — JAVA-приложения (апплеты) и ActiveX, различающиеся способом создания загружаемого приложения. Обе они имеют следующий недостаток: программа выполняется на рабочей станции, занимая немало ее ресурсов. В сравнении с доступом через «не web-клиента» использование подобного web-доступа для решения задач электронного архива и документооборота гораздо менее удобно и более ресурсоемко.

К минусам использования данной технологии следует отнести и то, что в настройках web-браузеров современных операционных систем по умолчанию запрещены загрузка и выполнение JAVA-приложений и ActiveX-объектов. Связано это прежде всего с политикой безопасности, блокирующей возможность загрузки из сети вирусов. Необходимые настройки требуют соответствующей квалификации пользователей, предоставления им соответствующих прав в операционной системе рабочей станции. А кроме того «смягчение» политики безопасности повышает риск загрузки и выполнения действительно вредоносных программ.

При доступе через web-интерфейс в системах электронного архива и документооборота технология ActiveX подходит больше, чем JAVA, поскольку с ее помощью можно внести в окно браузера недостающий функционал. Таким функционалом являются, например, средства работы с векторными изображениями и получаемыми при проектировании в САПР трехмерными многофайловыми сборками. Кроме того, использование ActiveX позволяет динамически отображать на экранах меняющуюся информацию БД, применять в окне браузера привычные для пользователя элементы «не web"-интерфейса. Скорее всего (конечно, всё зависит от решаемых задач), практически 100% функционала клиентского места системы электронного архива и документооборота можно реализовать в окне браузера. Но, в отличие от JAVA-приложений, ActiveX-объекты могут выполняться только в операционных системах Microsoft Windows.

Не вдаваясь в технические подробности, вкратце поясним суть работы ActiveX.

Технология использует специальные приложения, хранящиеся на сервере (например, в виде OCX-файлов) и создаваемые практически в любых современных средах программирования. При написании могут использоваться API-библиотеки необходимых САПР (тех, например, с файлами и сборками которых необходимо обеспечить работу в окне web-браузера). В соответствующих тегах HTML-кода страницы, хранящейся на сервере, указывается команда на загрузку ActiveX-приложения в определенном месте страницы. Такая загрузка осуществляется web-браузером с клиентского места автоматически, причем, в отличие от JAVA-приложений, ActiveX-компоненты загружаются при первом обращении к странице, а не каждый раз.

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

• реализовать компонент ActiveX, позволяющий полноценно решать в окне web-браузера все задачи систем электронного архива и документооборота, — дело довольно трудоемкое и недешевое;
• размер файла-компонента ActiveX, решающего серьезные задачи, достаточно велик. Не называя конкретного продукта, дабы не навлечь на себя подозрений в антирекламе, приведем такой пример: в одной из систем размер ActiveX-приложения, работающего в окне web-браузера, достигает 25 Mб. Напомним, что при первом обращении к странице, работающей с ActiveX, этот файл должен быть загружен на клиентскую рабочую станцию. Закачивать такой объем по низкоскоростным, в том числе и коммутируемым каналам связи, мягко говоря, неудобно. Если же канал позволяет быстро загружать такие файлы, следует вполне логичный вопрос: «А зачем в таком случае web-доступ и почему не использовать «не web"-клиентское приложение?»

Возможный ответ звучит так: «Но ведь все равно кроме браузера и единожды загружаемого ActiveX ничего не требуется». Ниже мы предлагаем некоторые комментарии к подобной точке зрения:

• ActiveX-компонент, по сути являясь отдельным приложением, автоматически инсталлируется в операционной системе после первой загрузки. Кроме того:
  • возникает ограничение по используемой операционной системе клиентского места: она должна быть совместима с той, для которой создавался ActiveX;
  • как уже сказано, для работы с файлами и сборками, получаемыми в двумерных и трехмерных САПР, при написании ActiveX используются API-библиотеки этих САПР. Таким образом, для работы ActiveX на клиентском месте недостаточно одной только соответствующей операционной системы — необходимо еще и наличие API-библиотек. Другими словами, должны быть проинсталлированы соответствующие САПР (а значит «толщина» клиента возрастает);
  • еще раз напомним, что в настройках web-браузеров современных операционных систем загрузка и инсталляция ActiveX по умолчанию запрещены. Конечно, при наличии необходимых прав и должной квалификации пользователь может, понизив уровень безопасности, обеспечить загрузку, инсталляцию и исполнение ActiveX-компонентов в окне браузера, но тем самым он откроет доступ и вредоносным программам.

Принцип целесообразности

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

Теперь постараемся сформулировать наши подходы к использованию web-доступа.

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

Большинству пользователей системы электронного архива и документооборота, выражающих обоснованное желание работать через web-доступ, как правило, не требуется работа с файлами векторных форматов и 3D-моделями (чаще это не конструкторы-проектировщики, а руководители и административные работники). Web-доступ для редактирования файлов документов, реализация которого требует дополнительных средств, целесообразен лишь в крайних случаях — когда других вариантов нет, а создание необходимых ActiveX-приложений экономически оправдано, и эти приложения не переносят большую часть процедур по обработке информации на клиентскую рабочую станцию.

Реализация web-доступа для системы управления технической информацией и документацией TDMS

Компания CSoft Санкт-Петербург (Бюро ESG) активно продвигает и внедряет системы электронного архива и документооборота в среде программного комплекса TDMS — разработанной компанией Consistent Software Development системы управления технической информацией и документацией.

Среди реализованных проектов — внедрение системы электронного архива ОАО «Гипроспецгаз», системы электронного архива ОАО «Красный Октябрь», системы электронного архива и документооборота ЗАО «ГТ-Инспект», системы электронного архива и документооборота с элементами PDM ЗАО «ЦНИИ СМ» и многие другие.

Существенное место в проводимой работе занимает реализация технологий поддержки жизненного цикла изделий и объектов. Мы неоднократно представляли наши подходы к созданию подобных систем и рассказывали об их успешных реализациях в среде TDMS, учитывающих различные задачи на разных этапах жизненного цикла (управление проектированием, строительные модели, системы логистической поддержки с элементами статистического анализа [5]).

Важной частью нашего подхода к внедрению ИПИ-технологий является электронный документооборот [6].

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

Руководствуясь этими принципами, компания CSoft Санкт-Петербург (Бюро ESG) разработала систему web-доступа к базе данных системы TDMS — программный комплекс TDMS WEB Access. Продукт успешно внедрен и активно используется в системе электронного архива и документооборота санкт-петербургского ОАО «Красный Октябрь». При этом реализован следующий функционал:

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

Использование TDMS WEB Access не исключает применения полнофункционального «не web"-клиента. Для выполнения задач, требующих реализации функций, ресурсоемких как для клиентского рабочего места, так и для бюджета, на предприятии используется «не web"-доступ в двухзвенной архитектуре «клиент-сервер». Web-доступ к единому серверу СУБД организован в трехзвенной архитектуре.

Рис. 2. Доступ с PC к базе данных системы электронного архива и документооборота через web-интерфейс

На рис. 3 показан процесс идентификации при доступе к БД TDMS с карманного компьютера (Pocket PC). Отметим, что на карманном компьютере не потребовалось дополнительной инсталляции каких бы то ни было программных средств.

Рис. 3. Доступ с карманного компьютера к базе данных TDMS (через web-интерфейс)

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

Постараемся ответить читателям, формулирующим следующую задачу: необходим удаленный доступ с использованием «тонкого клиента» ко всему функционалу системы электронного архива и документооборота, несмотря на то что web-браузер такого доступа не обеспечивает. При этом условия не позволяют загружать JAVA- и ActiveX-приложения и инсталлировать на клиентской рабочей станции дополнительные средства для работы с векторной графикой и 3D-моделями.

Вернемся к одному из определений, приведенному в начале статьи: «„тонкий клиент“ представляет собой компьютер — клиент сети, который переносит большинство задач по обработке информации на сервер», после чего внимательно изучим рис. 4, иллюстрирующий удаленный доступ к рабочему столу компьютера, на котором проинсталлирован стандартный клиент TDMS (не осуществляющий web-доступа и выполняющий 100% функций работы в системе электронного архива и документооборота). Доступ, проиллюстрированный этим рисунком, организован через Internet с использованием канала GPRS. Подобный доступ возможен с использованием любого канала (коммутируемого модемного соединения, выделенного Ethernet-канала, ADSL-канала и т.д.). При этом может использоваться стандартное программное обеспечение КПК — клиент терминальных сервисов. Из сказанного следует, что такое решение (см. рис. 4) является одним из вариантов обеспечения доступа к полному функционалу системы электронного архива и документооборота без инсталляции дополнительного ПО на клиентской рабочей станции.

Рис. 4. Доступ к рабочему столу компьютера через Internet с использованием терминального клиента КПК

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

• на клиентском рабочем месте системы электронного архива и документооборота в локальной сети устанавливается серверная часть службы терминалов, являющаяся стандартным компонентом операционной системы;
• на том же клиентском рабочем месте устанавливается клиентское приложение системы электронного архива и документооборота. Оно может поддерживать или не поддерживать web-доступ — в данном случае это совершенно ни на что не влияет;
• на том же клиентском месте ¹ инсталлируются все приложения, необходимые пользователю: например, средства работы с векторными документами, двумерными и трехмерными САПР и т.д.;
• на удаленных рабочих местах настраиваются клиенты службы терминалов;
• между клиентским рабочим местом с серверной частью службы терминалов и рабочими местами с клиентами службы терминалов организуется канал, который может быть выделенным, GPRS, ADSL, коммутируемым (модемным) соединением с корпоративной сетью или Internet.

При помощи терминальных клиентов удаленных рабочих мест осуществляется полноценное управление клиентским рабочим местом системы электронного архива и документооборота с сервером терминалов (рис. 5).

Рис. 5. Общая схема системы электронного архива и документооборота с использованием службы терминалов

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

• при необходимости использовать сложный ресурсоемкий функционал, инсталлированный на рабочей станции, являющейся сервером терминального доступа;
• в случае невозможности изменить конфигурацию клиентского компьютера (например, когда по соображениям безопасности нельзя инсталлировать ActiveX, необходимые даже для web-доступа, или когда используемая операционная система или ресурсы удаленной рабочей станции в принципе не позволяют выполнить необходимые инсталляции);
• при необходимости повысить уровень доступа к рабочей станции — серверу терминального доступа (которая может находиться и в помещении, ограниченном для физического доступа).

Справедливости ради отметим и некоторые принципиальные недостатки данного подхода:

• в случае одновременной работы нескольких клиентов нагрузка на сервер терминального доступа может оказаться очень высокой;
• могут возникать проблемы с лицензированием как программного обеспечения электронного архива, так и САПР-систем, поскольку одна приобретенная копия одновременно используется несколькими сотрудниками;
• возрастает нагрузка на канал, так как по сети передаются не только необходимые команды и результаты, но и все действия пользователя (например, каждое движение «мыши») и весь вывод сервера (например, отрисовка 3D-модели).

Авторы выражают искреннюю благодарность О. Турецкому (НТЦ «Механотроника») за полезные советы и помощь при подготовке статьи, а также Д. Осипову (OAO «Балтийский завод»), идеи и подход которого к данной проблематике позволили взглянуть на нее под другим углом.

Источники и литература

1. Википедия — проект свободной многоязычной энциклопедии. Internet-ресурс. Открытый доступ, русскоязычный раздел (http://ru.wikipedia.org).
2. Википедия — проект свободной многоязычной энциклопедии. Internet-ресурс. Открытый доступ, англоязычный раздел (http://en.wikipedia.org).
3. Understanding Thin-Client/Server Computing (Joel Kanter, Microsoft Press, 1998).
4. Free On-Line Dictionary of Computing. — Internet-ресурс. Открытый доступ (http://foldoc.org).
5. А.А. Рындин, Л.М. Рябенький, А.А. Тучков, И.Б. Фертман. Ступени внедрения ИПИ-технологий. — CADmaster, № 1/2006.
6. И.Б. Фертман, А.А. Тучков, А.А. Рындин. Ступени внедрения ИПИ-технологий. Опыт реализации электронного документооборота (материалы конференции «МОРИНТЕХ-ПРАКТИК. Информационные технологии в судостроении-2006»). — СПб, 2006 (www.csoft.spb.ru/Articles/IPI_1.htm).

Скачать статью в формате PDF — 520.8 Кбайт