В последнее время, достаточно часто приходится слышать требования пользователей систем электронного архива, документооборота по поводу возможности работы с использованием «Тонкого клиента». Причем далеко не все, выдвигающие подобное требование, отдают себе отчет в том, что такое «Тонкий клиент», чем работа с его использованием отличается от работы через Web – интерфейс (для многих это одно и тоже). В связи с этим, материал статьи призван расставить точки над «i» в вопросах терминологии и функциональных возможностях «Тонкого клиента» в преломлении его использования в системах электронного архива и документооборота.
Итак, начнем с определения. Термин «Тонкий клиент» появился сравнительно недавно и, скорее относился к «компьютерным» жаргонизмам, нежели к неологизмам. В связи с этим, его трактовку бесполезно искать в толковом словаре Даля. Несмотря на это, указанный термин применяется все чаще и чаще. Не претендуя даже на малую толику лексикографических заслуг Ожегова, попытаемся пояснить понятие «Тонкого клиента».
Считаем, что читатели полностью или частично посвящены в следующую особенность построения баз данных архитектуры клиент-сервер и трехзвенной архитектуры: в идеале все процессы выполняются на сервере посредством отработки хранимых процедур сервера. Обращение к серверу СУБД осуществляется через интерфейс клиентского места в архитектуре «клиент-сервер», а для трехзвенной архитектуры с клиентского места осуществляется обращение к серверу приложений, который, в свою очередь, обращается к СУБД. При этом сервер СУБД и сервер приложений физически располагаются на мощных аппаратных средствах, отличных от «клиентских» рабочих станций, что позволяет обрабатывать большое число запросов и управлять большими объемами информации БД без нагрузки на рабочие станции.
В различных источниках приведены несколько отличающихся определений «тонкого клиента». Иногда они достаточно противоречивы (даже в пределах одного и того же источника). Приведем примеры.
Давайте проведем небольшой экскурс в историю. В добропорядочные времена мейнфреймов доступ к многопользовательской среде осуществлялся через терминалы, локальные и удаленные. Именно этим устройствам суждено было стать прообразом устройств, на сегодняшний день объединенных под термином «тонкий клиент». Т.е. это устройства, имеющие в своем составе устройства ввода (клавиатура, мышь, считыватель смарт-карт, флэш-карт и т.д.), устройства вывода (монитор, принтер, колонки и т.д.) и средства подключения к серверу (адаптер сети 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. Подобная схема применима и к трехзвенной архитектуре (в этом случае, промежуточным звеном между сервером СУБД и клиентскими рабочими станциями является сервер приложений). Схема работает следующим образом:
При отработке запроса используются специальные средства «клиент-серверных» СУБД (Oracle, Microsoft SQL Server, Interbase и прочих) – хранимые процедуры и триггеры, реализованные на специализированных расширениях языка запросов (SQL), являющиеся неотъемлемой частью СУБД (для Oracle – PL/SQL, для Microsoft SQL Server - Transact SQL). Как правило, хранимые процедуры – специальные блоки программного кода, теоретически позволяющие производить любую обработку данных на сервере. СУБД получает команду от сервера приложений на запуск той или иной хранимой процедуры.
Повторим, что для «ресурсоемких» систем с интенсивным доступом, для снятия нагрузки с сервера СУБД, далеко не всю обработку целесообразно проводить с хранимыми процедурами сервера СУБД. Необходимая часть обработки в трехзвенной архитектуре производится сервером приложений.
Кроме команды на запуск той или иной хранимой процедуры, на сервер СУБД передаются все необходимые параметры, вводимые через пользовательский интерфейс клиентской рабочей станции или формируемые сервером приложений.
Триггеры – специальный вид хранимых процедур, «отвечающий» за целостность базы. В отличие от явно вызываемых хранимых процедур, триггеры автоматически отрабатывают на события при добавлении, удалении, обновлении информации в таблицах СУБД, реализуя необходимую логику работы системы электронного архива и документооборота.
Приведем примеры, которые успешно могут быть реализованы посредством триггеров и хранимых процедур сервера СУБД. При изменении наименования заказчика – потребителя проектной документации, автоформируемые номера и наименования томов, комплектов и документов в завершенных проектах, включающие код и название заказчика, должны остаться прежними, а в некоторой части ведущихся проектов номера и наименования должны автоматически измениться, порой по достаточно непростой логике.
Другой пример – при попытке внесения изменений в атрибутивную информацию документа, принадлежащего завершенному проекту (тому, комплекту), необходимо автоматически проверить, соблюдена ли бизнес логика (имеется ли разрешение на ревизию или извещение об изменении?).
Схема работы системы с использованием двухзвенной архитектуры «клиент-сервер» отличается от приведенной на рис. 1 отсутствием сервера приложений. Считаем, что отдельно иллюстрировать ее не стоит. В случае применения двухзвенной архитектуры «клиент-сервер», запрос к серверу СУБД, формируемый через интерфейс клиентских мест, поступает «напрямую». При этом, так же, как и в трехзвенной архитектуре запускаются и отрабатываются обработчики сервера СУБД – триггеры и хранимые процедуры.
При интенсивном использовании информационной системы, использование сервера приложений снимает нагрузку с сервера СУБД, что положительно влияет на быстродействие системы в целом и ее качество. В ряде случаев целесообразно использование нескольких серверов приложений. С другой стороны, отсутствие элементарной информации о принципе работы серверов приложений, их назначении в совокупности с рекламными акциями компаний-производителей ПО, приводит к тому, что ряд клиентов отказывается рассматривать любое решение, не поддерживающее трехзвенную архитектуру даже для одного - двух десятков рабочих станций c достаточно низкой интенсивностью доступа к базе данных.
Несомненно, целесообразность применения трехзвенной архитектуры определяется стоящими перед системой задачами, количеством одновременно работающих клиентов, интенсивностью их доступа, «размером» базы данных, возможностями используемой СУБД и, конечно же, решаемыми задачами, определяющими степень использования ресурсов сервера. Четких количественных критериев не существует. При достаточных ресурсах сервера, полнофункциональные рабочие места системы электронного архива и документооборота, например, при оптимальной конфигурации системы, устойчиво работают при использовании СУБД Oracle на 300-600 полнофункциональных рабочих станциях. При этом в таблицах СУБД могут содержаться миллионы записей, а архитектура системы может быть двухзвенной без использования серверов приложений.
При возникновении необходимости в решении специфических «более узких» задач для большого количества пользователей (например, доступа лишь для просмотра в систему электронного архива), целесообразно для той же базы данных использовать сервер приложений или WEB – доступ, речь о котором подробнее пойдет ниже.
Надеемся, что все изложенное поможет сделать правильный выбор и порой сэкономить средства.
Прочитав предыдущий раздел статьи, не следует делать вывод о том, что доступ к базе данных системы электронного архива и документооборота, организованный через окно браузера, исключает рассмотрение использования систем электронного архива и документооборота, предоставляющих информацию «не в окне браузера».
В этом месте изложения отметим явные недостатки Web-браузера, при его использовании в качестве средства доступа к полному функционалу системы электронного архива и документооборота. При этом, акцентируем внимание на том, что речь пойдет о системах электронного архива и документооборота. В других приложениях, использующих WEB-доступ, перечисленных ниже недостатков может не существовать, равно, как могут проявляться и другие:
Производительность обработки данных на сервере при обращении к базе через браузер такая же, как и через «не WEB» клиента, а вот возможности в отображении информации гораздо ниже и определяются следующим:
Хотя следует отметить ряд технологий, позволяющих частично решить приведенные проблемы. Заметим, что все описанные ниже технологии переносят часть процессов по обработке информации на клиентское место. При этом они, предоставляя возможность WEB-доступа, превращают WEB-браузер в далеко «неидеального» тонкого клиента, «толщина» которого, порой велика. В некоторых случаях, при создании большой нагрузки по обработке информации на клиентскую рабочую станцию, сложно г оворить о «тонком клиентом» вообще (несмотря на WEB–доступ). Кроме того, часто, ввиду сложности реализации, потери производительности системы из-за громоздкости клиентского приложения, желание «просто получить Web–доступ» ведет к необоснованным затратам при потере качества системы.
Для решения некоторых задач по обработке документов с использованием 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–компоненты загружаются при первом обращении к странице, а не каждый раз.
Описываемая технология имеет следующие особенности, являющиеся, скорее недостатками для систем электронного архива и документооборота:
Таким образом, полноценная работа со всеми функциями системы электронного архива и документооборота при попытках использования WEB – браузера без увеличения нагрузки на клиентские рабочие станции невозможна или крайне сложно достижима. Ввиду вышеизложенного, реализация Web–доступа к полному функционалу (при использовании WEB – браузера в качестве полнофункционального тонкого клиента), далеко нецелесообразна, порой громоздка, ресурсоемка и дорога.
Теперь постараемся сформулировать наши подходы к использованию WEB – доступа.
Несомненно, Web- доступ удобен, порой полезен и необходим, хотя при его реализации и использовании стоит руководствоваться принципом разумной целесообразности. Так, если действительно необходим доступ к системе электронного архива и документооборота с любого компьютера с использованием WEB-интерфейса и без инсталляции дополнительных программных средств, то он возможен. Но, при этом, ввиду описанных выше причин, функционал рабочего места при таком доступе будет ограничен. Как правило, при использовании любого Web–браузера возможен поиск информации по атрибутам и (или) полнотекстовый, просмотр растровых изображений форматов, поддерживаемых Web–браузером. Кроме того, возможен просмотр документов форматов, не поддерживаемых браузером, лишь с использованием проинсталлированных в операционной системе приложений (для работы с данными документами). В системе документооборота через Web–доступ возможна маршрутизация документов. Кроме того, часто целесообразен WEB – доступ к функционалу системы электронного архива и документооборота, связанному не только с просмотром, но и редактированием информации (например, атрибутивной информации документов, а порой и их файлов). Подчеркнем, что доступ на редактирование атрибутивной информации, как правило, может осуществляться «стандартными» для WEB – интерфейса средствами.
Добавим, что основному контингенту пользователей системы электронного архива и документооборота, выражающих обоснованное желание работать через WEB – доступ, как правило, не требуется работа с файлами векторных форматов, 3D – моделями (чаще, это – не конструктора - проектировщики, а руководители и административные работники). WEB - доступ на редактирование файлов документов, реализация которого требует дополнительных средств (описанных выше), целесообразен лишь в крайних случаях, если других вариантов нет, а создание необходимых Active-Х приложений экономически оправдано, и эти приложения не переносят большую часть процедур по обработке информации на клиентскую рабочую станцию.
Компания CSoft-SPb/Бюро ESG занимается активным продвижением и внедрением систем электронного архива и документооборота, разработанных в среде программного комплекса TDMS – системы управления информацией и документацией разработки CSoft.
Среди реализованных проектов – внедрение системы электронного архива ОАО «Гипроспецгаз», внедрение системы электронного архива ОАО «Красный Октябрь», внедрение системы электронного архива и документооборота ЗАО «ГТ-Инспект», внедрение системы электронного архива и документооборота с элементами PDM ЗАО «ЦНИИ СМ» и многие другие.
Важное место в проводимой работе занимает реализация технологий поддержки жизненного цикла изделий и объектов. Мы неоднократно писали о наших подходах в области создания подобных систем и успешных реализациях в среде TDMS, учитывающих различные задачи на различных этапах жизненного цикла – управление проектированием, строительные модели, системы логистической поддержки с элементами статистического анализа и многое другое. [5].
В нашем подходе к внедрению ИПИ – технологий, электронный документооборот является важной частью [6].
При реализации проектов по внедрению систем электронного архива и документооборота, в связи с часто возникающими вопросами по реализации WEB – доступа и тонкого клиента, и были сформулированы приводимые в статье подходы.
Руководствуясь вышеописанными принципами, компанией Бюро ESG была разработана система Web–доступа к базе данных системы управления технической информацией и документацией TDMS – программный комплекс TDMS WEB Access. Продукт успешно внедрен и активно используется в системе электронного архива и документооборота СПб ОАО «Красный Октябрь». При этом выполняется следующий функционал:
Использование TDMS WEB Access на предприятии не отвергает использование полнофункционального «не WEB – клиента». По принципу разумной целесообразности, на предприятии для выполнения задач, требующих реализации ресурсоемких как для клиентского рабочего места, так и для бюджета функций, используется «не WEB» доступ в двухзвенной архитектуре «клиент-сервер». WEB – доступ к единому серверу СУБД организован по трехзвенной архитектуре.
На рис. 3 приведен карманный компьютер (Pocket PC) (процесс идентификации при доступе к БД TDMS). Отметим, что на карманном компьютере не потребовалось дополнительной инсталляции каких–либо программных средств.
Постараемся ответить читателям, формулирующим следующую задачу: необходимо иметь удаленный доступ с использованием «тонкого клиента» ко всему функционалу системы электронного архива и документооборота, несмотря на то, что WEB - браузер такого доступа не обеспечивает. При этом условия не позволяют загружать JAVA и ActiveX – приложения и инсталлировать на клиентской рабочей станции дополнительные средства для работы с векторной графикой и 3D – моделями.
Вернемся к одному из определений, приведенному в начале статьи:
«Тонкий клиент» — это компьютер - клиент сети, который переносит большинство задач по обработке информации на сервер.
После чего внимательно изучим рисунок 4, иллюстрирующий удаленный доступ к рабочему столу компьютера, на котором проинсталлирован стандартный клиент TDMS (не осуществляющий WEB-доступ и выполняющий 100% функций работы в системе электронного архива и документооборота). Иллюстрированный рисунком 4 доступ организован через Интернет с использованием канала GPRS. Подобный доступ может быть осуществлен с использованием любого канала (коммутируемого модемного соединения, выделенного Ethernet – канала, ADSL – канала и т. д.). При этом может использоваться стандартное программное обеспечение КПК – клиент терминальных сервисов. Из сказанного следует, что такое решение (см. рис. 4) является возможным вариантом решения задачи доступа к полному функционалу системы электронного архива и документооборота без инсталляции дополнительного ПО на клиентской рабочей станции.
Общая схема работы в системе электронного архива и документооборота с использованием терминального доступа проиллюстрирована рис. 5. и поддерживает следующий принцип работы:
Выделим на наш взгляд случаи наиболее целесообразного использования доступа через клиента службы терминалов:
Стоит также отметить некоторые принципиальные недостатки данного подхода:
В заключение, хочется выразить благодарность О.Турецкому (НТЦ “Механотроника”), за полезные советы и помощь при редактировании статьи, а также Д.Осипову (OAO “Балтийский Завод”), идеи и подход которого к данной проблематике позволили нам взглянуть на вопрос под другим углом.
Эл. версия "CADmaster" 5, 2006 г.
вернуться к
списку