?

Log in

No account? Create an account

Предыдущий | Следующий

Написав своё замечание и получив по его поводу исчерпывающий комментарий, хочу вернуться ко второму вопросу: как сравнить тёплое и мягкое? На самом деле, достаточно просто корректно определить набор критериев для сравнения.

Под катом несколько занудных букв о сравнении Толстого и Тонкого клиентов.
В той статье, которая посвящена выбору системы для отправки электронной отчётности, приведены странные критерии сравнения. Говорить о том, что каждый плюс "Тонкого клиента" это минус "Толстого клиента" и наоборот - не очень корректно. Но после прочтения статьи можно сделать только такой вывод. Хотя главные отличия, на мой взгляд, там не указаны.

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

Сперва дам те определения Тонкого и Толстого клиентов, в рамках которых я и буду дальше их сравнивать:
  • Тонкий клиент - программное решение, позволяющее обеспечить электронный документооборот без установки на компьютере пользователя специализированного программного обеспечения (за исключением средств СКЗИ), обеспечивающий полную обработку документов на стороне центрального сервера, к которому пользователь должен иметь постоянный доступ в процессе подготовки документов.
  • Толстый клиент - программное решение, позволяющее обеспечить электронный документооборот только при условии установки на  компьютере пользователя специализированного программного обеспечения, обеспечивающий полную обработку документов на стороне клиента, с обращением к центральному серверу только в моменты обмена документами.
У каждого из этих решений есть неоспоримые преимущества. Как и то, чем приходится платить за эти преимущества.
Тонкий клиент намного проще в обслуживании, за счёт одной точки, в которой необходимо производить обновления. Но эта простота обслуживания даёт и свой минус: в период неработоспособности Центрального сервера или в отсутствие телекоммуникационного доступа к нему, работа пользователя невозможна.
Толстый клиент позволяет все операции по подготовке данных выполнить в отсутствие доступа к Центральному серверу. Но за это надо расплачиваться необходимостью обновления тысяч рабочих мест пользователей (повышенный трафик в пиковые периоды).

Имея опыт разработки и внедрения обоих типов клиентов, я сформулировал для себя аксиомы (пусть и оставляющие место для споров), которые корректирую по мере получения нового опыта:
  • Объем передаваемых данных, при подготовке и отправке одного документа, в случае тонкого клиента в 10 раз больше, чем при использовании толстого.
  • Объем обновления толстого клиента, как правило, колеблется в пределах объёма 1000 документов.
  • Время подготовки документа в 100 раз больше времени его передачи.
  • Информация о документах на центральном сервере всегда доступна его администратору.

И подходя к реализации той или иной задачи, я сразу задаю себе несколько вопросов, от ответов на которые и зависит выбор реализации:
  • Объём и частота обновлений ПО относительно объёма документооборота.
  • Возможность и необходимость стыковки с информационными системами на стороне клиента.
  • Владелец сервера, к которому обращается клиент.
  • Необходимость хранения архивов документооборота и их объем.
  • Необходимость обеспечения дополнительных функций на стороне клиента.

Возвращаясь к статье, которая стала поводом для этого поста, в части представления налоговой отчётности в электронном виде по каналам связи, могу сформулировать следующее:
  • Формы, форматы и правила заполнения налоговых деклараций меняются достаточно часто. Объем изменений, которые необходимо доводить до Толстого клиента, как правило, превышает количество документов, которые пользователь успеет отправить. Использование тонкого клиента в этом случае удобно и разумно. Единственным исключением является работа уполномоченной бухгалтерии, в которой количество представляемых деклараций будет существенно большим.
  • Подготовка бухгалтерской отчётности и налоговых деклараций, крайне редко осуществляется в автоматизированном виде. Как правило, подготовка первичных данных осуществляется с использованием данных бухгалтерской системы, в режиме ручной правки. При поштучной отправке отчётности, существенной разницы для пользователя нет. При отправке большого количества документов (уполномоченная бухгалтерия или крупные налогоплательщики) использование Толстого клиента предпочтительней.
  • Пользователь (налогоплательщик) всегда обращается к серверу специализированного оператора связи. Если пользователь согласен с тем, чтобы специализированный оператор связи имел доступ к его данным - это одно. Если нет, то ему подойдёт только Толстый клиент.
  • Хранение архивов является обязательным условием документооборота при представлении отчётности. Здесь у Толстого клиента неоспоримое преимущество, так как в Тонком клиенте эта возможность реализуется только ручным способом, да ещё и с  опасностью расползания архива по разным рабочим местам.
  • Для многих пользователей не требуются дополнительные функции, которые не могут быть реализованы в рамках Тонкого клиента.
Что мы имеем в итоге:
- если вы обеспечены постоянным и скоростным доступом к Интернет, вас не волнует возможность доступа посторонних лиц к данным  вашей отчётности, а отчётность формируется вручную и общее количество документов не очень велико - вам прямая дорога на Тонкий (On-line) клиент;
- если вам необходимо в автоматизированном режиме передавать большое количество документов, вам необходимо обеспечить защиту от несанкционированного доступа и автоматическое создание полноценного архива электронных документов - Толстый (Off-line) клиент ваш выбор.

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

А давайте их проверим. То есть те критерии, которые заявлены как "плюсы" для Тонкого и "минусы" для Толстого.

Критерий №1.
Установка обновлений. Почему-то авторы статьи считают, что установка обновлений не может производиться автоматически, требует обязательного участия специалиста и во многих случаях оборачивается нештатными ситуациями. Не знаю почему. Возможно, что именно так ими была спроектирована система обновлений для Толстого клиента в их реализации.

Критерий №2. Хранение архивов. Авторы статьи делают вольное допущение, что хранение зашифрованных архивов на Центральном сервере возможно только в Тонком клиенте. Непонятно, что делает невозможным хранение этого архива сразу в двух местах: на компьютере пользователя и на Центральном сервере при использовании Толстого клиента.

Критерий №3. Привязка бухгалтера к определённому компьютеру. Это святая правда, в случае, если рабочее место, на котором установлен Толстый клиент, вышло из строя - до восстановления его работоспособности возобновить штатную работу не получится.

Критерий №4. Фиксация даты отправки документа. Я уж не знаю, что и подумать. Авторы уверены, что единственным протоколом передачи данных между Толстым клиентом и почтовым сервером является протокол электронной почты. О том, что отчёт, что в случае Толстого, что в случае Тонкого клиента попадает на Центральный сервер сразу после нажатия кнопки "Отправить", а для формирования подтверждения даты отправки требуется время, вне зависимости от используемой технологии.

Итого, из 4-х критериев, которые приведены, только один действительно имеет отношение к преимуществам Тонкого клиента над Толстым, но этот, пресловутый Критерий №3, обходится созданием резервных копий на отчуждаемых носителях, с возможностью их автоматизированного восстановления.

Метки:

Comments

( 4 комментария — Оставить комментарий )
(Удалённый комментарий)
ivalnick
7 сент, 2009 19:20 (UTC)
Re: не согласен!!!
1. Прикладное ПО (в том числе и Толстый клиент) не обязаны менять системные файлы. Не вижу поводов, для увеличения сбоев. Тем более, что целостность операционной системы не менее (а то и более) важна для тонкого клиента.
У меня на рабочей станции в автоматическом режиме обновляется более 50-ти прикладных программ. И как-то все живет пока. И систему я переставлял больше трех лет назад после физического сбоя жесткого диска.

2. Простому бухгалтеру важна возможность восстановления архива. Как она реализована технически (доступ по HTTP, FTP или запрос выгрузки такого архива по телефону) - ему плевать.
В этом смысле Тонкий клиент более удобен для пользователя.
Но только в том случае, если на компьюетере, где установлен Толстый клиент, все совершенно потеряно.
При выходе же из строя Центрального сервера, пользователь Тонкого клиента оказывается в однозначном проигрыше. У пользователя Толстого клиента останется его собственная копия, сделанная в автоматическом режиме, а пользователя Тонкого клиента только искусанные локти о не сделанных резервных копиях.

3. Кажется, я именно это и написал. Единственное реальное преимущество Тонкого клиента.

4. Э-э-э... А зачем пользователю Толстого клиента ждать? То есть, чем он в этом ожидании принципиально отличается от пользователя Тонкого клиента? Они оба ждут момента формирования подтверждения и только. Или вы считаете, что они не могут использовать один и тот же транспортный протокол?

--------------------

По поводу доступа Администратора к данным пользователя Тонкого клиента.
Что делает пользователь Тонкого клиента, взаимодействуя с Центральным сервером:
- вводит документы
- хранит документы
- редактирует документы
- проверяет документы
Вот только после всех этих операций он подписывает их и шифрует.
До этого момента, а особенно в момент проверки, данные документа полностью доступны Администратору Центрального сервера.

Если вы считаете, что от этого можно защититься - приведите работоспособную схему, гарантирующую отсутствие возможности такого доступа.

--------------------

Кстати, мои поздравления с первым комментарием в ЖЖ.
Польщен.
ivalnick
7 сент, 2009 19:23 (UTC)
Две маленькие неточности
1. Сертификаты налогоплательщику, как правило, выдает специализированный оператор связи, который в этот момент действует в качестве удостоверяющего центра, но и только. Вопросы выдачи оставим за кадром, они никакого отношения к сравнению клиентов не имеют.

2. Тенденции таковы, что чем дальше тем больше, используя широкополосные каналы связи, пользователи отгораживаются от Интернета любыми способами, вплоть до организации "воздушного зазора".
serg_bad_guy
7 сент, 2009 20:19 (UTC)
Re: не согласен!!!
по поводу п.3 =)
согласен, но не совсем.
Если ПО написано таким образом что может функционировать в так называемом Portable режиме (т.е. с флешки), а такое ПО существует =))), то в случае если нужно "переехать" на другой компьютер для работы с "толстым клиентом" достаточно установить СКЗИ и сертификаты (как и для "тонкого") а также запустить с флешки сам "толстый клиент" и продолжать работать. =)
Если компьютер на котором был установлен "толстый клиент" сломался, но данные с HDD доступны, никто не мешает скопировать "толстого клиента" на другой компьютер и работать дальше.
Вопрос только в том, как написано ПО и в наличии специалистов которые помогут бухгалтеру, а если мы говорим про ИТ и затраты на быстрый интернет, то и соответствующие специалисты должны быть. =) Они должны быть хотя бы для того, чтобы поставить бухгалтеру на компьютер СКЗИ и установить сертификаты. Я не уверен что любой бухгалтер в состоянии выполнить эти манипуляции, а если в состоянии, то и скопировать каталог с программой на флешку он сможет =)
Все вышесказанное IMHO. =)))

по п.4
возможно я чего-то не понимаю, но...
Если пользователь сдает отчетность в 23:45 и подтверждение на него формируется сразу, то при условии что пользователь подключается к центральному серверу и передает ему, допустим почтовое сообщение то IMHO оно на центральный сервер попадает практически сразу. И если центральный сервер практически сразу формирует подтверждение, то пользователю достаточно просто еще раз подключиться к центральному серверу и проверить наличие подтверждения.
ivalnick
7 сент, 2009 20:29 (UTC)
Крошечное дополнение
Во-первых, установка СКЗИ не является неотъемлемым аттрибутом этого класса ПО. Оно так же может функционировать в Portable-mode. Так что все что нужно для возобновления работы - носитель с Толстым клиентом, ключевой носитель и работоспособный компьютер с доступом к сети. Кстати, решения объединяющие носитель с ключевым носителем уже есть.

Во-вторых, Центральный сервер тратит одно и тоже время на формирование подтверждения, вне зависимости от того, каким клиентом пользуется пользователь. И оба клиента могут использовать один и тот же транспортный протокол. Так что с этой точки зрения между ними нет вообще никакой разницы.
( 4 комментария — Оставить комментарий )

Profile

Аватарка
ivalnick
ivalnick

Latest Month

Ноябрь 2019
Вс Пн Вт Ср Чт Пт Сб
     12
3456789
10111213141516
17181920212223
24252627282930

Метки

Page Summary

Разработано LiveJournal.com
Designed by Tiffany Chow