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