Насколько «тонок» клиент
29 мая 2006
Л. Гимейн, В. Козменко, А. Рындин, И. ФертманО понятии «тонкий клиент»
В последнее время, достаточно часто приходится слышать требования пользователей систем электронного архива, документооборота по поводу возможности работы с использованием «Тонкого клиента». Причем далеко не все, выдвигающие подобное требование, отдают себе отчет в том, что такое «Тонкий клиент», чем работа с его использованием отличается от работы через Web – интерфейс (для многих это одно и тоже). В связи с этим, материал статьи призван расставить точки над «i» в вопросах терминологии и функциональных возможностях «Тонкого клиента» в преломлении его использования в системах электронного архива и документооборота.
Итак, начнем с определения. Термин «Тонкий клиент» появился сравнительно недавно и, скорее относился к «компьютерным» жаргонизмам, нежели к неологизмам. В связи с этим, его трактовку бесполезно искать в толковом словаре Даля. Несмотря на это, указанный термин применяется все чаще и чаще. Не претендуя даже на малую толику лексикографических заслуг Ожегова, попытаемся пояснить понятие «Тонкого клиента».
Считаем, что читатели полностью или частично посвящены в следующую особенность построения баз данных архитектуры клиент-сервер и трехзвенной архитектуры: в идеале все процессы выполняются на сервере посредством отработки хранимых процедур сервера. Обращение к серверу СУБД осуществляется через интерфейс клиентского места в архитектуре «клиент-сервер», а для трехзвенной архитектуры с клиентского места осуществляется обращение к серверу приложений, который, в свою очередь, обращается к СУБД. При этом сервер СУБД и сервер приложений физически располагаются на мощных аппаратных средствах, отличных от «клиентских» рабочих станций, что позволяет обрабатывать большое число запросов и управлять большими объемами информации БД без нагрузки на рабочие станции.
В различных источниках приведены несколько отличающихся определений «тонкого клиента». Иногда они достаточно противоречивы (даже в пределах одного и того же источника). Приведем примеры.
- В компьютерных технологиях тонкий клиент (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].
- Можно привести еще множество определений понятия «тонкого клиента», но все они либо дополняют друг друга, либо взаимоисключают друг друга.
Давайте проведем небольшой экскурс в историю. В добропорядочные времена мейнфреймов доступ к многопользовательской среде осуществлялся через терминалы, локальные и удаленные. Именно этим устройствам суждено было стать прообразом устройств, на сегодняшний день объединенных под термином «тонкий клиент». Т.е. это устройства, имеющие в своем составе устройства ввода (клавиатура, мышь, считыватель смарт-карт, флэш-карт и т.д.), устройства вывода (монитор, принтер, колонки и т.д.) и средства подключения к серверу (адаптер сети Ethernet, адаптер последовательной линии связи или модем). В качестве примера можно привести “тонкие клиенты” фирмы “AK systems”. Именно поэтому определение [3] является абсолютно обоснованным. Нo сегодня понятие “тонкого клиента” не ограничивается данным определением. Нам больше импонирует определение «тонкого клиента», данное в Free On-Line Dictionary of Computing: “A simple client program or hardware device which relies on most of the function of the system being in the server” [4] Т.е. в качестве «тонкого клиента» может выступать и полноценная рабочая станция, имеющая в своем составе ПО, иммитирующее режим «тонкого клента». С развитим WEB технологий, для доступа к WEB-узлам (серверам) стандартом де-факто стало использование Web-браузера. Именно поэтому появилось отожествление понятия «тонкого клиента» и Web-браузера.
«Толстый клиент» является антиподом «тонкого». В определениях «толстого клиента» противоречия встречаются реже. Приведем одно из них: «Толстый клиент» производит обработку информации независимо от сервера, используя последний в основном лишь для хранения данных. [1]
Не станем дальше заниматься приведением определений и поиском противоречий в них, а будем говорить ниже лишь о «толщине» тонкого клиента – степени распределения нагрузки по обработке информации между клиентским приложением и сервером СУБД в двухзвенной архитектуре и между клиентским приложением, сервером приложений и сервером СУБД в трехзвенной архитектуре. Причем, все изложение будем строить на практическом применении в системах электронного архива и документооборота.
В идеале, большинство пользователей систем электронного архива и документооборота хотят иметь возможность доступа к системе с любого компьютера, по любым каналам. При этом выдвигается требование к отсутствию необходимости дополнительных инсталляций клиентских приложений на удаленных рабочих станциях. Одним из требований является отсутствие на них каких-либо специфических настроек. Кроме того, часто высказывается пожелание иметь доступ с удаленной рабочей станции к полному функционалу системы электронного архива и документооборота. Иногда же, требованием является доступ к системе электронного архива и документооборота независимо и от операционных систем удаленных рабочих станций. Выдвигающие перечисленные требования пользователи, как правило, всегда говорят о доступе через «тонкого клиента».
Обобщив все пожелания пользователей систем электронного архива и документооборота, можно сделать следующий вывод: в идеале, для реализации тонкого клиента должно существовать клиентское приложение, работающее, не требующее дополнительных инсталляций в операционных системах рабочих станций и позволяющее любому пользователю, имеющему необходимый сетевой доступ и параметры идентификации, независимо от операционной системы рабочей станции и сервера, используемой СУБД, иметь доступ к полному функционалу системы электронного архива и документооборота.
Ответ на вопрос о возможности практической реализации не может быть однозначным и зависит от конкретики решаемых задач, в некоторых случаях он может быть вполне утвердительным, в других – нет. Теоретически, реализация вышеприведенного суммарного функционала сродни понятию математического предела, говоря проще – нечто к чему стремимся, но в идеале никогда не достигнем (как для всех возможных задач по работе с БД в общем, так и для задач работы с БД систем электронного архива и документооборота, в частности).
Если система построена в архитектуре клиент-сервер, то на наш взгляд, невозможно провести четкую грань между системой, использующей «тонкого» клиента, в которой основная часть обработки информации возложена на сервер, и системой с «толстым клиентом», в которой сервер используется в основном для хранения данных. Это связано, прежде всего, с тем, что сам принцип работы систем клиент-сервер, как двухзвенной, так и трехзвенной архитектуры (подробнее описанный ниже), подразумевает ведение основной части обработки информации на сервере. Кроме того, невозможность проведения указанной грани связана с отсутствием четкой формулировки критериев. Например, вряд ли кем-нибудь определено, в чем стоит измерять и сколько должна составлять «основная часть обработки информации», возложенная на сервер. Кроме того, численно не определены критерии эксплуатации сервера при его использовании «в основном для хранения данных». На наш взгляд, в современных системах, использующих архитектуру «клиент-сервер», стоит говорить о «толщине клиента», то есть о «степени участия» клиентских рабочих мест в процессе обработки информации, нагрузке на них, использовании их ресурсов и «доле» сервера и сервера приложений в процессах, происходящих в системе в целом.
Для дальнейшей «расстановки точек над i», позволим себе прокомментировать одно из устоявшихся мнений. Большинство пользователей (как существующих, так и перспективных) систем электронного архива и документооборота часто считают, что «тонкий клиент» обязательно должен быть реализован через WEB – браузер, считая понятия WEB – доступа и тонкого клиента абсолютно идентичными. На наш взгляд, применительно к системам электронного архива и документооборота, такое мнение не всегда корректно.
Совершенно понятным является то, почему, на первый взгляд, оптимальным клиентским приложением для реализации тонкого клиента мог бы являться Web–браузер. Действительно, в большинстве современных операционных систем он является их неотъемлемой частью и не требует дополнительной инсталляции, HTML страницы одинаково отображаются в различных операционных системах и могут передаваться по любым каналам связи. Работа через браузер удобна и привычна для большинства пользователей. Общую схему работы системы электронного архива и документооборота с использованием WEB – доступа иллюстрирует рис. 1. Подобная схема применима и к трехзвенной архитектуре (в этом случае, промежуточным звеном между сервером СУБД и клиентскими рабочими станциями является сервер приложений). Схема работает следующим образом:
- запрос с клиентской рабочей станции, формируемый через интерфейс клиентского рабочего места (в случае WEB – доступа – через WEB – браузер), поступает на сервер приложений (или WEB-сервер, в случае WEB – доступа);
- сервер приложений (в случае WEB–доступа – WEB–сервер) производит обработку запроса, при необходимости решает прикладные задачи и передает запрос серверу СУБД. Примером прикладной задачи, решаемой сервером системы WEB–доступа к системе электронного архива и документооборота TDMS, является формирование и передача СУБД запросов для маршрутизации документов между пользователями в процессе их разработки (обработки);
- СУБД отрабатывает запрос и возвращает результат серверу приложений, который отправляет клиенту результаты в понятном тому виде. В случае же WEB–доступа, Web-сервер должен дополнительно представить результаты в виде страниц, «понятных» WEB – браузеру, например, используя технологию ASP или PHP.
При отработке запроса используются специальные средства «клиент-серверных» СУБД (Oracle, Microsoft SQL Server, Interbase и прочих) – хранимые процедуры и триггеры, реализованные на специализированных расширениях языка запросов (SQL), являющиеся неотъемлемой частью СУБД (для Oracle – PL/SQL, для Microsoft SQL Server - Transact SQL). Как правило, хранимые процедуры – специальные блоки программного кода, теоретически позволяющие производить любую обработку данных на сервере. СУБД получает команду от сервера приложений на запуск той или иной хранимой процедуры.
Повторим, что для «ресурсоемких» систем с интенсивным доступом, для снятия нагрузки с сервера СУБД, далеко не всю обработку целесообразно проводить с хранимыми процедурами сервера СУБД. Необходимая часть обработки в трехзвенной архитектуре производится сервером приложений.
Кроме команды на запуск той или иной хранимой процедуры, на сервер СУБД передаются все необходимые параметры, вводимые через пользовательский интерфейс клиентской рабочей станции или формируемые сервером приложений.
Триггеры – специальный вид хранимых процедур, «отвечающий» за целостность базы. В отличие от явно вызываемых хранимых процедур, триггеры автоматически отрабатывают на события при добавлении, удалении, обновлении информации в таблицах СУБД, реализуя необходимую логику работы системы электронного архива и документооборота.
Приведем примеры, которые успешно могут быть реализованы посредством триггеров и хранимых процедур сервера СУБД. При изменении наименования заказчика – потребителя проектной документации, автоформируемые номера и наименования томов, комплектов и документов в завершенных проектах, включающие код и название заказчика, должны остаться прежними, а в некоторой части ведущихся проектов номера и наименования должны автоматически измениться, порой по достаточно непростой логике.
Другой пример – при попытке внесения изменений в атрибутивную информацию документа, принадлежащего завершенному проекту (тому, комплекту), необходимо автоматически проверить, соблюдена ли бизнес логика (имеется ли разрешение на ревизию или извещение об изменении?).
Схема работы системы с использованием двухзвенной архитектуры «клиент-сервер» отличается от приведенной на рис. 1 отсутствием сервера приложений. Считаем, что отдельно иллюстрировать ее не стоит. В случае применения двухзвенной архитектуры «клиент-сервер», запрос к серверу СУБД, формируемый через интерфейс клиентских мест, поступает «напрямую». При этом, так же, как и в трехзвенной архитектуре запускаются и отрабатываются обработчики сервера СУБД – триггеры и хранимые процедуры.
При интенсивном использовании информационной системы, использование сервера приложений снимает нагрузку с сервера СУБД, что положительно влияет на быстродействие системы в целом и ее качество. В ряде случаев целесообразно использование нескольких серверов приложений. С другой стороны, отсутствие элементарной информации о принципе работы серверов приложений, их назначении в совокупности с рекламными акциями компаний-производителей ПО, приводит к тому, что ряд клиентов отказывается рассматривать любое решение, не поддерживающее трехзвенную архитектуру даже для одного - двух десятков рабочих станций c достаточно низкой интенсивностью доступа к базе данных.
Несомненно, целесообразность применения трехзвенной архитектуры определяется стоящими перед системой задачами, количеством одновременно работающих клиентов, интенсивностью их доступа, «размером» базы данных, возможностями используемой СУБД и, конечно же, решаемыми задачами, определяющими степень использования ресурсов сервера. Четких количественных критериев не существует. При достаточных ресурсах сервера, полнофункциональные рабочие места системы электронного архива и документооборота, например, при оптимальной конфигурации системы, устойчиво работают при использовании СУБД Oracle на 300-600 полнофункциональных рабочих станциях. При этом в таблицах СУБД могут содержаться миллионы записей, а архитектура системы может быть двухзвенной без использования серверов приложений.
При возникновении необходимости в решении специфических «более узких» задач для большого количества пользователей (например, доступа лишь для просмотра в систему электронного архива), целесообразно для той же базы данных использовать сервер приложений или WEB – доступ, речь о котором подробнее пойдет ниже.
Надеемся, что все изложенное поможет сделать правильный выбор и порой сэкономить средства.
Рис. 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.
- Как указывалось выше, для работы с файлами и сборками, получаемыми в 2D- и 3D-САПР, при написании ActiveX используются API–библиотеки САПР. То есть для работы ActiveX на клиентском месте недостаточно «соответствующей» операционной системы, но еще и необходимо наличие соответствующих API–библиотек, иными словами должны быть проинсталлированы соответствующие САПР («толщина» клиента возрастает).
- Как мы уже замечали, в современных операционных системах, в настройках системы безопасности Web–браузеров по умолчанию загрузка и инсталляция ActiveX запрещена. Необходима соответствующая квалификация и права пользователя для разрешения работы с ActiveX–компонентами в окне браузера. Кроме того, снижение уровня безопасности, при установке разрешения загрузки, инсталляции и исполнения ActiveX, открывает доступ для вредоносных программ.
Принцип разумной целесообразности
Таким образом, полноценная работа со всеми функциями системы электронного архива и документооборота при попытках использования WEB – браузера без увеличения нагрузки на клиентские рабочие станции невозможна или крайне сложно достижима. Ввиду вышеизложенного, реализация Web–доступа к полному функционалу (при использовании WEB – браузера в качестве полнофункционального тонкого клиента), далеко нецелесообразна, порой громоздка, ресурсоемка и дорога.
Теперь постараемся сформулировать наши подходы к использованию WEB – доступа.
Несомненно, Web- доступ удобен, порой полезен и необходим, хотя при его реализации и использовании стоит руководствоваться принципом разумной целесообразности. Так, если действительно необходим доступ к системе электронного архива и документооборота с любого компьютера с использованием WEB-интерфейса и без инсталляции дополнительных программных средств, то он возможен. Но, при этом, ввиду описанных выше причин, функционал рабочего места при таком доступе будет ограничен. Как правило, при использовании любого Web–браузера возможен поиск информации по атрибутам и (или) полнотекстовый, просмотр растровых изображений форматов, поддерживаемых Web–браузером. Кроме того, возможен просмотр документов форматов, не поддерживаемых браузером, лишь с использованием проинсталлированных в операционной системе приложений (для работы с данными документами). В системе документооборота через Web–доступ возможна маршрутизация документов. Кроме того, часто целесообразен WEB – доступ к функционалу системы электронного архива и документооборота, связанному не только с просмотром, но и редактированием информации (например, атрибутивной информации документов, а порой и их файлов). Подчеркнем, что доступ на редактирование атрибутивной информации, как правило, может осуществляться «стандартными» для WEB – интерфейса средствами.
Добавим, что основному контингенту пользователей системы электронного архива и документооборота, выражающих обоснованное желание работать через WEB – доступ, как правило, не требуется работа с файлами векторных форматов, 3D – моделями (чаще, это – не конструктора - проектировщики, а руководители и административные работники). WEB - доступ на редактирование файлов документов, реализация которого требует дополнительных средств (описанных выше), целесообразен лишь в крайних случаях, если других вариантов нет, а создание необходимых Active-Х приложений экономически оправдано, и эти приложения не переносят большую часть процедур по обработке информации на клиентскую рабочую станцию.
Реализация WEB – доступа для системы управления технической информацией и документацией TDMS
Компания CSoft-SPb/Бюро ESG занимается активным продвижением и внедрением систем электронного архива и документооборота, разработанных в среде программного комплекса TDMS – системы управления информацией и документацией разработки CSoft.
Среди реализованных проектов – внедрение системы электронного архива ОАО «Гипроспецгаз», внедрение системы электронного архива ОАО «Красный Октябрь», внедрение системы электронного архива и документооборота ЗАО «ГТ-Инспект», внедрение системы электронного архива и документооборота с элементами PDM ЗАО «ЦНИИ СМ» и многие другие.
Важное место в проводимой работе занимает реализация технологий поддержки жизненного цикла изделий и объектов. Мы неоднократно писали о наших подходах в области создания подобных систем и успешных реализациях в среде TDMS, учитывающих различные задачи на различных этапах жизненного цикла – управление проектированием, строительные модели, системы логистической поддержки с элементами статистического анализа и многое другое. [5].
В нашем подходе к внедрению ИПИ – технологий, электронный документооборот является важной частью [6].
При реализации проектов по внедрению систем электронного архива и документооборота, в связи с часто возникающими вопросами по реализации WEB – доступа и тонкого клиента, и были сформулированы приводимые в статье подходы.
Руководствуясь вышеописанными принципами, компанией Бюро ESG была разработана система Web–доступа к базе данных системы управления технической информацией и документацией TDMS – программный комплекс TDMS WEB Access. Продукт успешно внедрен и активно используется в системе электронного архива и документооборота СПб ОАО «Красный Октябрь». При этом выполняется следующий функционал:
- доступ осуществляется через Web–интерфейс с любой машины сети (после соответствующей идентификации пользователя (рис. 2).
- осуществляется поиск по атрибутивной информации документов;
- осуществляется полнотекстовый поиск;
- осуществляется маршрутизация документа в процессе документооборота, рассылки извещений и сообщений;
- возможно редактирование атрибутивной информации;
- допустимо редактирование части файлов документов (не требующих инсталляции дополнительных программных средств, несущих большую нагрузку на клиентскую рабочую станцию).
Использование TDMS WEB Access на предприятии не отвергает использование полнофункционального «не WEB – клиента». По принципу разумной целесообразности, на предприятии для выполнения задач, требующих реализации ресурсоемких как для клиентского рабочего места, так и для бюджета функций, используется «не WEB» доступ в двухзвенной архитектуре «клиент-сервер». WEB – доступ к единому серверу СУБД организован по трехзвенной архитектуре.
Рис. 2. Общая схема работы системы электронного архива и документооборота с использованием WEB–доступа
На рис. 3 приведен карманный компьютер (Pocket PC) (процесс идентификации при доступе к БД TDMS). Отметим, что на карманном компьютере не потребовалось дополнительной инсталляции каких–либо программных средств.
Рис. 3. Доступ к базе данных TDMS с использованием WEB – интерфейса с карманного компьютера
Использование терминального клиента
Постараемся ответить читателям, формулирующим следующую задачу: необходимо иметь удаленный доступ с использованием «тонкого клиента» ко всему функционалу системы электронного архива и документооборота, несмотря на то, что WEB - браузер такого доступа не обеспечивает. При этом условия не позволяют загружать JAVA и ActiveX – приложения и инсталлировать на клиентской рабочей станции дополнительные средства для работы с векторной графикой и 3D – моделями.
Вернемся к одному из определений, приведенному в начале статьи:
«Тонкий клиент» — это компьютер-клиент сети, который переносит большинство задач по обработке информации на сервер.
После чего внимательно изучим рисунок 4, иллюстрирующий удаленный доступ к рабочему столу компьютера, на котором проинсталлирован стандартный клиент TDMS (не осуществляющий WEB-доступ и выполняющий 100% функций работы в системе электронного архива и документооборота). Иллюстрированный рисунком 4 доступ организован через Интернет с использованием канала GPRS. Подобный доступ может быть осуществлен с использованием любого канала (коммутируемого модемного соединения, выделенного Ethernet – канала, ADSL – канала и т. д.). При этом может использоваться стандартное программное обеспечение КПК – клиент терминальных сервисов. Из сказанного следует, что такое решение (см. рис. 4) является возможным вариантом решения задачи доступа к полному функционалу системы электронного архива и документооборота без инсталляции дополнительного ПО на клиентской рабочей станции.
Рис 4. Доступ к рабочему столу компьютера через Интернет с использованием терминального клиента КПК
Общая схема работы в системе электронного архива и документооборота с использованием терминального доступа проиллюстрирована рис. 5. и поддерживает следующий принцип работы:
- На клиентском рабочем месте системы электронного архива и документооборота в локальной сети устанавливается серверная часть службы терминалов, являющаяся стандартным компонентом операционной системы;
- На том же клиентском рабочем месте устанавливается клиентское приложение системы электронного архива и документооборота. Оно может как поддерживать, так и не поддерживать WEB-доступ, в описываемом случае, это совершенно ни на что не влияет;
- На том же клиентском месте инсталлируются все необходимые для работы приложения, например средства работы с векторными документами, 2D и 3D – САПР и т.д.;
- Работа с этого клиентского рабочего места описывалась выше (см. рис. 1);
- На удаленных рабочих местах настраиваются клиенты службы терминалов;
- Между клиентским рабочим местом с серверной частью службы терминалов и рабочими местами с клиентами службы терминалов организуется канал, который может быть выделенным , GPRS, ADSL, коммутируемым (модемным) соединением с корпоративной сетью или Интернет;
- При помощи терминальных клиентов удаленных рабочих мест осуществляется полноценное управление клиентским рабочим местом системы электронного архива и документооборота с сервером терминалов, проиллюстрированное выше (см. рис. 4).
Выделим на наш взгляд случаи наиболее целесообразного использования доступа через клиента службы терминалов:
- При необходимости использования сложного ресурсоемкого функционала, проинсталлированного на рабочей станции, являющейся сервером терминального доступа;
- В случае невозможности изменить конфигурацию клиентского компьютера (например, когда по соображениям безопасности нельзя инсталлировать необходимые даже для WEB – доступа Active-X, когда используемая операционная система или ресурсы удаленной рабочей станции в принципе не позволяют провести необходимые инсталляции);
- В случае необходимости повышения уровня доступа к рабочей станции – серверу терминального доступа (которая может находиться в порой ограниченном для физического доступа помещении).
Стоит также отметить некоторые принципиальные недостатки данного подхода:
- Нагрузка на сервер терминального доступа может быть очень высокая, в случае одновременной работы нескольких клиентов.
- Могут возникать проблемы с лицензированием, как программного обеспечения электронного архива, так и с САПР-системами, поскольку одна приобретенная копия используется одновременно несколькими сотрудниками.
- Возрастает нагрузка на канал, т.к. по сети передаются не только необходимые команды и результаты, а все действия пользователя (например, каждое движение указателя «мыши») и весь вывод сервера (например, отрисовка 3D-модели).
Благодарности
В заключение, хочется выразить благодарность О.Турецкому (НТЦ “Механотроника”), за полезные советы и помощь при редактировании статьи, а также Д.Осипову (OAO “Балтийский Завод”), идеи и подход которого к данной проблематике позволили нам взглянуть на вопрос под другим углом.
Источники и литература
- Википедия – проект свободной многоязычной энциклопедии. Интернет ресурс. Открытый доступ. http://ru.wikipedia.org, русскоязычный раздел;
- Википедия – проект свободной многоязычной энциклопедии. Интернет ресурс. Открытый доступ. http://en.wikipedia.org, англоязычный раздел;
- “Understanding Thin-Client/Server Computing” (Joel Kanter, Microsoft Press, 1998 г.);
- Free On-Line Dictionary of Computing – Интернет ресурс. Открытый доступ. http://foldoc.org
- «Ступени внедрения ИПИ – технологий», А.А.Рындин, Л.М.Рябенький, А.А.Тучков, И.Б.Фертман, «Судостроение» № 4/2005 СПб., ГНЦ РФ ФГУП ЦНИИ ТС
- «Ступени внедрения ИПИ – технологий. Опыт реализации электронного документооборота», И.Б.Фертман, А.А.Тучков, А.А.Рындин. Материалы конференции «Моринтех-практик информационные технологии в судостроении – 2006», СПб., 2006 г.