16 октября, вторник 21:40
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Тонкий и толстый клиент.

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Тонкий и толстый клиент.

    Сразу прошу прощения у Алексея Чиликова, за то, что пользуюсь похожим ником.

    Перед регистрацией на форуме я много почитал про воплощения тонких клиентов, про их плюсы, минусы и особенности. Я смотрел не только новые темы, но и темы двухлетней давности.

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

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

    Эти пункты в разной степени относятся к различным реализациям, давайте не будем разводить что-то типа "А в PC-Banking'е этого нет, зато есть..." и "BS-Defender умещается на дискетку". К каждому пункту можно по желанию подставлять слово "относительный/относительно".

    Недостатки толстых клиентов :
    1. Большой размер дистрибутива
    2. Сложность установки и настройки
    3. Сложность обновления системы на стороне клиента
    4. Не самые актуальные данные


    Преимущества толстых клиентов:
    1. Более богатая функциональность по сравнению с тонкими клиентами.
    2. Многопользовательская работа
    3. Работа без постоянного подключения к внешнему миру
    4. Возможность подключения к банку без подключения к интернету
    5. Быстрая работа интерфейса


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

    Также тонкость клиентов сильно портит необходимость встраивания криптосистем, сложность и порядок установки которых в определенных условиях может сводить на нет преимущества тонкого клиента и усугублять недостатки толстого.
    ---------------------------------------------------------
    Хочу отметить, что для пользователя (особенно ЮЛ), как правило, нет разницы, каким воплощением клиент-банка пользоваться - тонким или толстым, при условиях, что оба представляют сходный функционал и удобство, пользователь может ориентироваться в любой из систем и качество каналов связи позволяет не ощущать замедления работы (последнее утверждение относится к обоим вариантам, по-разному бывает).

    Вот для банка ситуация иная. Разумеется, автоматизаторам проще исправить проблему, если для этого не приходится быть "Remote Desktop'ом по телефону" в течение доброго получаса или выезжать к клиентам для исправления мелкой, а, бывает, и не мелкой проблемы, не париться и не заморачиваться с установкой кучи софта, в настройке каждого из которых могут быть свои нюансы, иметь свои решения для каждого нюанса. Общеизвестно, что чем больше последовательных элементов в системе, тем больше вероятность выхода системы из строя.
    Для банка централизованное решение, конечно же, предпочтительнее.

    В попытках перещеголять друг друга лидеры на рынке клиент-банков "меряются ...ами" в форуме, в той или иной мере рекламируя отсутствие недостатков и наличие достоинств обоих систем в своих продуктах. А мне больше импонирует позиция mgolovanov'а, которую в совокупности со своими мыслями я хочу изложить. Признаюсь, тут есть кое-что и от модуля PC-Banking из системы iBank2.

    Тонко-толстый клиент с модульной архитектурой, не требующий установки
    Если идеально тонкого клиента не получается, совсем не обязательно привязывать тонкий клиент к браузеру и пользоваться его (браузера) возможностями. Это уже показали нам BIFIT и BSS. Один продукт эксплуатирует технологию Java, другой формирует представление и логику при помощи ActiveX. Обе технологии "прикручены" к браузеру и прекрасно работают в его отсутствие. "А если нет разницы, зачем платить больше?" © Дося.
    Тогда вообще не нужно использовать технологии, работающие в браузере, клиент-банк можно реализовать на чем угодно. Можно оптимизировать размер. Можно функциональность.
    Можно предоставить основную функциональность в небольшом приложении, а дополнительные возможности загружать отдельными модулями, даже автоматически.
    Можно реализовать модулями криптосистемы и транспортные системы, формат хранения данных и импорта. Получится что-то типа конструктора. IBM PC с открытой архитектурой. Наконец,
    можно использовать существующее подключение для работы в онлайне и режим с синхронизацией при его отсутствии. Для обмена, наверное, подойдет предложенный mdeveloper'ом экономный SOAP.

    Предлагаю обсудить идею, высказать свое мнение по этому поводу. Предвидя флейм, оставляю за собой право игнорировать высказывания, на которые не хочу отвечать. Но я постараюсь быть объективным.

  • #2
    Мне эта идея тоже в свое время показалась хорошей, сам прикидывал, как это можно сделать и понял, что это вполне можно реализовать ( хотя надо заметить, что я в результате все равно пришел к использованию скриптов, описывающих формы и их поведение т.е. практически написал своеобразный браузер ), но мне как потенциальному пользователю систем ДБО хочется иметь возможность управлять своими счетами из любого интернет кафе и желательно не таскать с собой никакой софт (мало-ли какие там могут быть правила). Так что у тонкого, пардон, - у Web-клиента определенно есть будущее. Правда для физиков он все таки должен быть несколько другой - полегче, чтобы в отпуск с собой брать не дискетку или другой носитель, а скажем листочек с одноразовыми паролями.

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

    Комментарий


    • #3
      Как обидно: набил огромный ответ, буквально через три слова собирался отправить - и комп перезагрузился!

      Ладно, попытка N2. Если будет недосказанность - не серчайте, второй раз одно и то же набираю.

      Я имел ввиду немножко другое. Я хотел избавиться от браузера вообще как от средства использования клиента. Имелась ввиду программа, которая запускается после загрузки из интернета и сразу работает. То есть загружается, вводятся минимальные настройки, после этого происходит синхронизация с банком, в котором прописаны все настройки клиента. Во время синхронизации клиенту загружаются не только необходимые ему для работы документы и формы, но и предпочтительный способ взаимодействия с каналами связи, криптосистема. То есть после первоначальной синхронизации клиенту сразу предоставляется требование либо ввести сессионный пароль, либо вставить ключевую дискету, либо еще что-то. Можно даже привязать работу клиента к определенному компьютеру. После этого ведется работа. Если есть подключение к сети - онлайн, выписки там, мгновенная отправка документов, если инет обрубился - локально. Захотел срочно платежку отправить - слил на носитель исполняемый модуль, загруженные модули расширения, файл настроек и базу, пошел к другому компьютеру, с интернетом, запустил, отправил в банк.

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

      Сегодня еще появилась у меня идея: что если исполняемый модуль сделать интерпретатором экономного, но мощного в плане подключения внешних функций языка, а загружаемые модули реализовать на этом языке? Тогда модули будут еще меньше занимать, а на разработку можно будет потратить меньше времени. Недостающий функционал смогут клепать автоматизаторы банка прямо "на коленке". Очень способствует расширению и популярности системы. Удачные наработки можно будет вставлять в коробочный комплект системы, поощряя при этом разработчиков. Вон RSL как помог R-Style'у-то! Точнее банкам, использующим индивидуальные наработки на основе базовой конфигурации.

      А, может, зря я это затеял? Может, были или есть подобные проекты? Какие подводные камни я не увидел своими розовыми очками? Из-за чего они не получили широкого распространения? Ответьте, специалисты!

      P.S. GeC, спасибо за ответ!
      Последний раз редактировалось Lexy2; 14.04.2004, 01:07. Причина: Исправил символы ? на отображающиеся корректно

      Комментарий


      • #4
        GeC
        Моя вторая идея действительно напоминает браузер. Но фишка в том, что его функциональность можно расширять неограниченно, в отличие от браузера. Кроме того, в разных браузерах отображаться это будет по-разному, что хоть и небольшой минус, но определенным образом ограничивает использование. Я, например, люблю Оперу, хотя для захода на некоторые страницы мне требуется IE (в частности, BSS).

        Комментарий


        • #5
          Lexy2: исполняемый модуль сделать интерпретатором экономного, но мощного в плане подключения внешних функций языка, а загружаемые модули реализовать на этом языке?

          А может тогда проще использовать интерпретаторы, которые уже имеются в Винде?

          А вообще, разница между толстым и тонким клиентами ИБ, ИМХО, в базе данных, которая в первом случае на стороне клиента, во втором - в банке.

          Комментарий


          • #6
            sandyman: А может тогда проще использовать интерпретаторы, которые уже имеются в Винде?

            Имеются ввиду jscript и vbscript? По-моему, у них ограниченный функционал, а все, что они могут делать, реализуется COM-объектами на стороне клиента. Визуальный интерфейс ими описать сложно. Логику - тем более. Я подумал, что язык должен быть более или менее специализированным. Наверное, декларативный подойдет лучше процедурного. Надо подумать. Возможно, я ограниченно знаю WSH.

            sandyman: А вообще, разница между толстым и тонким клиентами ИБ, ИМХО, в базе данных, которая в первом случае на стороне клиента, во втором - в банке.

            Ну а если использовать базу в банке, а при отключении иметь возможность работать в оффлайне с закэшированными документами? Конечно, возникнут проблемы со справочниками. Их тоже надо подгружать клиенту, собравшемуся поработать. Но при этом не обязательно грузить все справочники, тем более полностью. У клиента ограниченный набор корреспондентов в ограниченном числе банков. Даже на этом можно оптимизировать работу - грузить справочник по частям.
            Последний раз редактировалось Lexy2; 14.04.2004, 17:42. Причина: Смысловая ошибка

            Комментарий


            • #7
              Уважаемые коллеги,
              приходит ли вам в голову одна простая мысль: тонкий клиент на базе браузера/Java есть ПЕРЕНОСИМАЯ среда, в отличие от всех других вариантов. Используя среды не переносимые, вы отсекаете пользователей, работающих не под Windows -- а такие есть.

              Комментарий


              • #8
                Конечно, приходит.

                Вот только переносимость среды на базе браузера - вопрос довольно спорный. Ведь истинно тонких клиентов не существует - каждый использует те или иные возможности браузера - ActiveX, DHTML, JavaScript. Я видел вживую несколько тонких клиентов. Так вот, работа в них невозможна, если даже под платформой Windows использовать браузеры Opera или Mozilla. Седставьте пребе, они некорректно отображают или вообще не отображают данные формы клиента. И для такой работы я вынужден использовать IE. Что уж говорить других платформах!

                Что касается Явы, то с этим, конечно, не поспоришь. Ява есть во всех браузерах, и аутсайдером тут выступает, как ни странно, Microsoft, с его непонятной и изменчивой политикой по поддержке Явы в Internet Explorer'е. Да еще и устаревшей (одна из самых надежных реализаций JVM - ха-ха). Однако, ориентируясь на Яву, мы обрекаем себя на использование AWT в качестве визуального интерфейса или на свои компоненты, как у БИФИТа, которые, замечу, надо еще написать и отладить. Пользователи, сидящие на Win98 4.10.1998 и WinXP SP1, коих несравненно больше, нежели пользователей Оперы и Линукса, не оценят нашего дальновидного решения.

                Если рассматривать мое решение, то я могу навскидку предложить следующий обходной вариант: исполняемый модуль сделать и для других распространенных платформ, а загружаемые - идентичными для каждой среды исполнения. М-да, фактически получается реализация виртуальной машины Java для разных платформ. Велосипед, однако. Преимущества этого способа лишь в том, что моей виртуальной машине не требуется быть универсальной, она будет много меньше Sun JVM, однако тогда, конечно, лишится своего небольшого размера. Бесспорно, меньше 15 или даже 5 Мб, но около мегабайта точно, а это уже перебор.

                Я думаю, что пользователям не-Windows приходится только мечтать о знакомой среде вне дома/работы. В этом случае мое решение им не подойдет. Люди, выбирающие клиент-банк для *nix, наверняка не собираются пользоваться им мобильно, в разных местах.

                Признаться, первоначальная идея была в использовании компилируемого языка, присутствующего на многих платформах, например ANSI C или ISO C99. Модули, привязанные к платформе, были бы меньше по размеру, чем байт-код Java, но имели бы большую гибкость. А гибкость - снова привязка к платформе. Замкнутый круг.

                Все равно, этот вопрос можно решить. А какие еще есть решения в этой сфере для пользователей не-Windows, кроме iBank? Да, iBank - компромисс между переносимостью и удобством, но кто еще не отсекает пользователей не-Windows?

                Комментарий


                • #9
                  Lexy2
                  Люди, выбирающие клиент-банк для *nix, наверняка не собираются пользоваться им мобильно, в разных местах.
                  -- очень ошибаетесь, уважаемый. Известно ли Вам, что из всех продуктов Эппл в России наибольшим спросом пользуются именно ноутбуки? И что их покупателей здесь уже десятки тысяч? А люди, покупающие эту технику, для любого банка являются привлекательными клиентами.
                  Напоминаю: MacOS X есть UNIX-подобная система на основе открытого микроядра и FreeBSD, дополненных проприетарным эппловским GUI.
                  ИМХО, надо исходить из того, что JVM есть на каждой клиентской машине, включая КПК, а вот все остальное -- под вопросом.
                  Кстати, на месте наших разработчиков я бы подумал вот о чем. Как-то так получается, что все они всегда _догоняют_ события. А ведь сейчас есть шанс их несколько опередить. Дело в том, что абсолютно очевидно, что через 2-4 года максимум никаких КПК в нынешнем виде уже не будет, а будет то, что сейчас называется "смартфонами", то есть КПК с GSM/GPRS модулем и возможностью голосовой связи. Аналогично, не будет и мобильных телефонов в нынешнем виде: они также превратятся в смартфоны (кстати, отягощенные всякой ерундой типа фотокамер и MP3 проигрывателей, но это не имеет отношения к теме).
                  Так вот, я бы уже сейчас начал разработку банк-клиента, ориентированного именно на эту платформу, с учетом ее специфики.

                  Комментарий


                  • #10
                    Так вот, я бы уже сейчас начал разработку банк-клиента, ориентированного именно на эту платформу, с учетом ее специфики.
                    Специфика уж больно сильная, особенно в эргономике. Клавиатура никакая (разве что распростанение получат такие как в Nokia 6800/6820), экран очень маленький. Попробуй на таком платёжку ввести... Пока не произойдёт качественного скачка (типа использования виртуальных экранов в очках), большой функциональности там не реализовать.

                    Комментарий


                    • #11
                      Вот только переносимость среды на базе браузера - вопрос довольно спорный. Ведь истинно тонких клиентов не существует - каждый использует те или иные возможности браузера - ActiveX, DHTML, JavaScript. Я видел вживую несколько тонких клиентов. Так вот, работа в них невозможна, если даже под платформой Windows использовать браузеры Opera или Mozilla. Седставьте пребе, они некорректно отображают или вообще не отображают данные формы клиента. И для такой работы я вынужден использовать IE. Что уж говорить других платформах!

                      Вспоминается анекдот: Папа а тонкие клиенты существуют? Нет это фантастика сынок!
                      Ан нет встречается и такой зверь - например широко используемая в скандинавских странах система Solo насколько я знаю абсолютно тонкий Web-клиент т.е. клиенту отправляется чистый HTML.

                      Возможно построить навороченную систему на чистом HTML трудно, и работать это будет медленнее, но зато работает в любом браузере.

                      Комментарий


                      • #12
                        Сообщение от hedin
                        Специфика уж больно сильная, особенно в эргономике. Клавиатура никакая (разве что распростанение получат такие как в Nokia 6800/6820), экран очень маленький. Попробуй на таком платёжку ввести... Пока не произойдёт качественного скачка (типа использования виртуальных экранов в очках), большой функциональности там не реализовать.
                        Я же говорю о коммуникаторах и смартфонах на базе платформы КПК -- они, как правило, имеют возможность ввода через сенсорный экран с помощью стилуса и либо системы граффитти, либо экранной клавиатуры. Как человек, пятый год пользующийся бесклавиатурным КПК, могу сказать, что это очень удобно -- более удобно и быстро, чем работать на миниатюрной клавиатурке. Экран будет минимум 240 на 320, а судя по тому, как развиваются события -- скорее 640 на 480. Даже первого разрешения достаточно для заполнения довольно сложных форм, если они организованы правильно (см., например, настройку GPRS и Интернета). При этом на такой платформе несложно организовать хранение справочников по реквизитам основных контрагентов -- реально ведь достаточно очевидно, какие операции и в отношении каких контрагентов будет совершать через такой терминал физическое лицо...

                        Комментарий


                        • #13
                          Экран будет минимум 240 на 320, а судя по тому, как развиваются события -- скорее 640 на 480.
                          Да хоть 1280 на 1024. Дело то не в разрешении, а в физических размерах. Будут большие размеры - работать будет удобно, но носить такое чудо в кармане уже не сможешь. А остануться маленькими - без лупы буковки не разглядишь. Выход я тут вижу только один - виртуальные экраны, когда изображение может превышать физичиские размеры экрана. Например, через проецирование на сетчатку глаза.

                          Комментарий


                          • #14
                            alexve
                            Lexy2

                            Люди, выбирающие клиент-банк для *nix, наверняка не собираются пользоваться им мобильно, в разных местах.
                            -- очень ошибаетесь, уважаемый. Известно ли Вам, что из всех продуктов Эппл в России наибольшим спросом пользуются именно ноутбуки? И что их покупателей здесь уже десятки тысяч?


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

                            GeC
                            Возможно построить навороченную систему на чистом HTML трудно, и работать это будет медленнее, но зато работает в любом браузере.

                            Я специально посмотрел на эту систему. В общем, ничего. Однако вся криптография там основана на SSL и сессионных паролях. Нам такое не подойдет.

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

                            Комментарий


                            • #15
                              hedin
                              Да хоть 1280 на 1024. Дело то не в разрешении, а в физических размерах. Будут большие размеры - работать будет удобно, но носить такое чудо в кармане уже не сможешь. А остануться маленькими - без лупы буковки не разглядишь.
                              Уважаемый, вот передо мной мой ASUS 620 с экраном в три с половиной дюйма. Вот я читаю на нем книжицу интересную. Что характерно, при моей дальнозоркости -- без всякого напряжения (на самом деле глаза устают даже меньше, чем при чтении с бумаги). Нет, на мой взгляд (и мой опыт) тут проблемы физических размеров, есть проблема правильного проектирования пользовательского интерфейса приложения (специально для малых экранов).

                              Комментарий


                              • #16
                                Я специально посмотрел на эту систему. В общем, ничего. Однако вся криптография там основана на SSL и сессионных паролях. Нам такое не подойдет.

                                Данную систему я привел только как пример использования HTML (кстати у них можно соединяться с системой через разные каналы - через WAP например) и по архитектуре весьма правильная система, правда весьма дорогая
                                BSS и iBank не чета

                                Что касается кодирования/подписи - наскольно я помню там есть возможность использовать для чиповые карты. Из любого места конечно не попользуешься, но если работать в оффисе то вполне приемлимо.
                                А насчет сессионных паролей - для физика IMXO возможность использовать сессионные пароли очень даже удобна.

                                Комментарий


                                • #17
                                  Lexy2 По поводу КПК - я думаю, юрлица предпочтут мобильность надежности. Mobile-Banking имеет смысл в основном для физлиц. По крайней мере, у нас, в Воронеже, пока совершенно никто из клиентов не рассматривает возможность использования мобильного банкинга. Вряд ли кто-то из директоров будет удаленно контролировать действия своих бухгалтеров - масштабы не те. -- а вот четыре года назад один весьма уважаемый человек, президент нехилой группы компаний, включающей одного из крупнейших в России лизинговых операторов, интересовался у меня, нет ли готовой разработки системы управленческого учета, с которой руководители предприятия могли бы работать с КПК через мобильный телефон... Люди бывают разные, и еще несколько лет назад мно-ого было директоров, которые с клиент-банком не соглашались работать.
                                  Еще раз повторяю: я говорю о разработке на перспективу -- не на сегодняшний рынок, а на тот, каким он будет через два года -- как раз когда разработка закончится.

                                  Комментарий


                                  • #18
                                    Уважаемый, вот передо мной мой ASUS 620 с экраном в три с половиной дюйма. Вот я читаю на нем книжицу интересную.
                                    В том то и дело, что читаешь. А представь, что тебе надо набрать. Ту же банальную платёжку. С подключенными справочниками. Прикинь, сколько символов по вертикали и горизонтали у тебя отображается при ненапряжном чтении. После этого учти, сколько у тебя места съестся виртуальной клавиатурой. Ну не поместится она (платёжка) у тебя вся на экране, как ни крути. Значит придётся добавлять закладки и скроллинг. И возможности одним взглядом окинуть данные у тебя не будет.

                                    Далее, одновременно вывести список документов и быстрый просмотр (как в Outlook Express) тоже не получится. Или буквы будут нечитаемые или текст не влезет.

                                    Вот это я и называю - будет неудобно работать

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

                                    Комментарий


                                    • #19
                                      hedin -- прекрасно носится в кармане, даже в кармане рубашки, притом эта модель не самая малогабаритная (ipaq 19xx заметно меньше).
                                      Прежде чем делать выводы о применимости девайса, поработайте с ним. Закладки не фатальны, наоборот, дают возможность сделать операцию подготовки платежки пошаговой (визард), что уменьшает вероятность ошибок.

                                      Комментарий


                                      • #20
                                        Кстати, а многим ли юр.лицам нужна мобильность на уровне КПК/смартфона. Будет ли руководитель на отдыхе подписывать платежки и проматривать выписки. А не для отпуска и ноутбуки есть.


                                        Если мы говорим про физиков, то тут и с сеансоваыми паролями все в порядке и мобильность на уровне Смарфона потребуется. Только им платежки не надо будет такие масштабные набивать как юр.лицам. Переброску средств меджу счетами можно в 3 контроля нарисовать.

                                        Комментарий


                                        • #21
                                          Уважаемый Lexy2,

                                          Вас немного увели от темы дискуссии

                                          Но для начала хочу сделать небольшую поправку, - с моей точки зрения, Ваше понимание тонкого клиента не совсем точное. Дело в том, что тонкий клиент это не в чистом виде HTML приложение, подобное ограничение приведет к тому, что Вы не сможете встроить криптографию. Я не имею в виду шифрование трафика, эта задача решается элементарно на базе SSL/TLS, я имею в виду ЭЦП. Решения, построенные на базе пароля (какого угодно) всегда будут ограничены. Даже для физлиц, начиная с определенного сегмента, "парольные" схемы защиты начинаю "напрягать" клиентов, т.к. они судебно не доказуемы, в отличие от ЭЦП, а я не говорю уже про юриков, где надо защищаться, для начала, от собственных сотрудников. Следовательно, я бы предложил, все-таки рассматривать тонкого клиента, как приложение, способное работать в рамках стандартной поставки операционной системы. Хочу заметить, что криптографическая защита тонкого клиента, тоже попадает под данное определение, для этого достаточно посмотреть на запад, где в криптографии используются алгоритмы, признанные на международном уровне, а не на уровне одной страны, как у нас. При таком подходе, кстати, написать тонкого клиента совсем не сложно, не нужны не джавы и не активиксы ))

                                          Теперь про высказанную идею. Идея конечно не нова, и бесспорно имеет право на существование и реализацию. Я даже знаю ряд воплощений высказанной идеи. Но с моей точки зрения она ничем не отличается от толстого клиента. Вот мои аргументы, давайте обсудим:
                                          1. Наличие возможности догружать модули автоматически "расслабляет" программиста (это полная аналогия java-аплетов), т.к. что называется "выдержать архитектуру" это дело не простое, и при подобных возможностях на клиента будет перенесено большое количество лишней логики. А наличие ограниченной и неконтролируемой клиентской платформы дает стимул "думать" над каждым изменением.
                                          2. Автоматическое обновление клиентской части - это вещь неперспективная, уже сейчас в Москве, например, можно спокойно проложить до квартиры канал в 300 Кбит, за менее чем 50$ в месяц, поэтому вопрос скорости канала скоро перестанет быть актуальным, и все эти оптимизации буду лишними.
                                          3. Что касается "открытой архитектуры". Может в Вас еще не раскрыт будущий Билл Г (без шуток)! В первом ответе на Ваше письмо были приведен абсолютно справедливый пример - при разработке описанной Вами штуки, Вы, со временем, начнете замечать сходство с очень знакомым приложением - MS IE, или аналогом. Следовательно, встает вопрос - зачем изобретать велосипед ?
                                          4. Что касается работа в оффлайне. См. п.2. Часто ли не работает у Вас телевизор из-за отсутствия канала с вышки? Не часто. Следовательно, стоит ли подобная функциональность того геморроя, который она приносит ?

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

                                          Используйте его в своих целях, используйте чужие инвестиции!

                                          Комментарий


                                          • #22
                                            sandyman: А может тогда проще использовать интерпретаторы, которые уже имеются в Винде?
                                            Имеются ввиду jscript и vbscript? По-моему, у них ограниченный функционал, а все, что они могут делать, реализуется COM-объектами на стороне клиента.


                                            Функционал действительно ограниченный, но при желании это легко исправить. В нашем "толстом" BARS'е мы используем эти интерпретаторы для построения экранных и печатных форм, обработки событий, доступа к данным и т.д. Для облегчения создания таких сценариев специалистами банка, мы реализовали визуальную среду разработки, сопоставимую по своим возможностям с Delphi. Желающим можем ее выслать для ознакомления.

                                            Что касается "тонкого" клиента, то на мой взгляд обсуждаемая идея выглядит довольно привлекательно. Особенно если совместить браузер, например IE и небольшое приложение, являющееся для него оболочкой (вариант внедренного IE

                                            metallic: Используйте его в своих целях, используйте чужие инвестиции!

                                            От браузера взять его возможности по загрузке и отображению Web-страниц, обработки скриптов и т.д. А задачами приложения, являющегося для браузера контейнером, будет автоматическая установка необходимых настроек (при этом на другие копии IE настройки не распространяются), работа с СКЗИ, импорт-экспорт данных, кеширование для поддержки режима офф-лайн и ускорения работы (например кеширование справочника банков и контрагентов), подключение любых внешних транспортных систем и т.д.
                                            При этом приложение сопоставимо по размеру с Java-апплетом от Bifit, а значит его можно хранить на дискете вместе с ключами, в крайнем случае на flash-носителе (если СКЗИ объемное), с него и запускать

                                            Минусом остается невозможность работы под *nix (без эмуляторов).

                                            А сколько преимуществ для автоматизаторов банков! Изменение печатной/экранной формы или клиентской логике обработки сводится к изменению HTML странички в каком-нибудь FrontPage или Macromedia. В этой ситуации нет необходимости страничку оптимизировать под все браузеры. Пользователь однозначно будет работать с внедренным IE, значит и странички будут меньше и объем программирования на скриптах уменьшается. При таком построении зависимость банков от разработчиков сильно понижается.

                                            Вообщем мы всерьез рассматривали это направление для создания "тонкого" клиента.

                                            Комментарий


                                            • #23
                                              2metallic: поэтому вопрос скорости канала скоро перестанет быть актуальным, и все эти оптимизации буду лишними.

                                              Вопрос скорости канала ещё очень нескоро перестанет быть актуальным, потому что кроме Москвы существуют ещё регионы, где у клиентов и денег меньше, и каналы гораздо хуже. У нас, например, несколько "жирных" в денежном отношении клиентов работают с интернет-клиент-банком по GPRS на 9600 откуда-то из дикой лесной глухомани. И что же, из-за того, что в Москве проблемы с каналами нет, мы должны терять подобных иногородних клиентов, так, что ли ?
                                              WBR, Александр Турчин

                                              Комментарий


                                              • #24
                                                Маленькое замечание
                                                Что такое тонкий и толстый клиент? Если судить по названию, то в идеале толстый клиент - это программа, обладающая большим размером за счет увеличения универсальности и функциональности системы, а тонкий - приложение, не требующее специальной установки на компьютер пользователя за счет несколько ограниченной функциональности.
                                                Достаточно вольное определение... напоминает решение, подогнанное под ответ
                                                На самом деле изначально идея тонкого клиента заключалась в том, чтобы освободить компьютеры на рабочих местах от вычислений, передав их серверу.
                                                Т.е. клиентское приложение занимается только отображением и вводом информации и не занимается ее обработкой (view в парадигме model-view-presenter).

                                                Моя идея действительно напоминает браузер. Но фишка в том, что его функциональность можно расширять неограниченно, в отличие от браузера.
                                                Заблуждение - браузеры (не знаю про все, но IE - 100%) изначально сделаны так, что их функциональность можно расширять неограниченно, причем с помощью разных технологий (Java, ActiveX, flash и т.д.)

                                                Кроме того, в разных браузерах отображаться это будет по-разному, что хоть и небольшой минус, но определенным образом ограничивает использование.
                                                Сейчас существующие браузеры совместимы хоть на каком-то минимальном уровне, ты предлагаешь сделать еще один браузер, который ни с кем по определению не будет совместим.
                                                Я, например, люблю Оперу, хотя для захода на некоторые страницы мне требуется IE (в частности, BSS).
                                                В итоге понадобиться еще один браузер

                                                jscript и vbscript - по-моему, у них ограниченный функционал... Визуальный интерфейс ими описать сложно. Логику - тем более.
                                                Распространенное заблуждение - с помощью DHTML/JScript можно реализовать сколь угодно навороченный интерфейс . Что касается логики - во-первых, в тонком клиенте она должна стремиться к нулю, а во-вторых, на jscript можно реализовать все необходимую прикладную логику.

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

                                                Согласен 100%

                                                Комментарий


                                                • #25
                                                  Сообщение от Александр_Турчин
                                                  2metallic: поэтому вопрос скорости канала скоро перестанет быть актуальным, и все эти оптимизации буду лишними.

                                                  Вопрос скорости канала ещё очень нескоро перестанет быть актуальным, потому что кроме Москвы существуют ещё регионы, где у клиентов и денег меньше, и каналы гораздо хуже. У нас, например, несколько "жирных" в денежном отношении клиентов работают с интернет-клиент-банком по GPRS на 9600 откуда-то из дикой лесной глухомани. И что же, из-за того, что в Москве проблемы с каналами нет, мы должны терять подобных иногородних клиентов, так, что ли ?
                                                  Александр,
                                                  да у Вас логика абсолютно верная, конечно. Вопрос стоит рентабельности вложений в разработку подобных технологий. Если у вас подобные штуки есть исторически, то все ясно. Но если Вы пишете с нуля, станете ли Вы городить подобный огород из таких клиентов?

                                                  Комментарий


                                                  • #26
                                                    2metallic:Но если Вы пишете с нуля, станете ли Вы городить подобный огород из таких клиентов?

                                                    Есть достаточно много клиентов, разъезжающих по России и всему миру с нотебуком и GPRS-картой. Качество связи в такой ситуации часто весьма хреновое, однако терять таких клиентов из-за неумения программистов оптимизировать софт НЕЛЬЗЯ !
                                                    WBR, Александр Турчин

                                                    Комментарий


                                                    • #27
                                                      Сообщение от Александр_Турчин
                                                      2metallic:Но если Вы пишете с нуля, станете ли Вы городить подобный огород из таких клиентов?

                                                      Есть достаточно много клиентов, разъезжающих по России и всему миру с нотебуком и GPRS-картой. Качество связи в такой ситуации часто весьма хреновое, однако терять таких клиентов из-за неумения программистов оптимизировать софт НЕЛЬЗЯ !
                                                      Верно конечно.
                                                      Skylink предоставляет сейчас GPRS канал под 150 Кбит, может это решение?
                                                      Оптимизация софта дело не простое, чудес не бывает. Иногда дешевле купить другую железку.

                                                      Комментарий


                                                      • #28
                                                        2metallic : Skylink предоставляет сейчас GPRS канал под 150 Кбит

                                                        А Вы зону покрытия SL посмотрите - он даже в Подмосковье не везде работает, не говоря уж о всей стране. А международного роуминга в SL нет . Тем более заставлять клиента покупать дополнительный sl-телефон мы не можем... Хотя, конечно, SL - вещь хорошая. Мы сейчас подключаем некоторые банкоматы и даже доп. офисы (временно, до прокладки нормального канала) через телефоны SL.
                                                        И кстати, SL не предоставляет GPRS-канал ! SL - это вообще не GSM, а CDMA-450. Услуги передачи данных реализованы там посредством технологии IMT-MC.
                                                        WBR, Александр Турчин

                                                        Комментарий


                                                        • #29
                                                          Ирония судьбы: для того чтобы воспользоваться цитированием, форму ответа я открываю в IE.

                                                          metallic
                                                          Идея конечно не нова, и бесспорно имеет право на существование и реализацию. Я даже знаю ряд воплощений высказанной идеи
                                                          А можно примерчики? А можно где-нибудь такое пощупать?

                                                          1. Наличие возможности догружать модули автоматически "расслабляет" программиста (это полная аналогия java-аплетов), т.к. что называется "выдержать архитектуру" это дело не простое, и при подобных возможностях на клиента будет перенесено большое количество лишней логики. А наличие ограниченной и неконтролируемой клиентской платформы дает стимул "думать" над каждым изменением.

                                                          Чем же это неконтролируемая схема? И так уж ли обязательно "выдерживать архитектуру" с точки зрения отдельно взятого банка, которому "лишь бы работало", а там получше и компания-разработчик напишет. Лишняя логика здесь заключается только в возможности автоматической подгрузки. Что касается функциональной части - ее можно и ограничить.


                                                          2. Автоматическое обновление клиентской части - это вещь неперспективная, уже сейчас в Москве, например, можно спокойно проложить до квартиры канал в 300 Кбит, за менее чем 50$ в месяц, поэтому вопрос скорости канала скоро перестанет быть актуальным, и все эти оптимизации буду лишними.

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


                                                          3. Что касается "открытой архитектуры". Может в Вас еще не раскрыт будущий Билл Г (без шуток)! В первом ответе на Ваше письмо были приведен абсолютно справедливый пример - при разработке описанной Вами штуки, Вы, со временем, начнете замечать сходство с очень знакомым приложением - MS IE, или аналогом. Следовательно, встает вопрос - зачем изобретать велосипед ?

                                                          Клиент-банк - это все-таки специализированная система, а в специализированной системе можно соптимизировать что-нибудь, в отличие от универсальной. Повторюсь, что всерьез рассматривается только MS IE, а все остальное, получается - незначительный процент, так?


                                                          4. Что касается работа в оффлайне. См. п.2. Часто ли не работает у Вас телевизор из-за отсутствия канала с вышки? Не часто. Следовательно, стоит ли подобная функциональность того геморроя, который она приносит ?

                                                          Сравнение несколько неточное, имхо. К телевизору можно подключить видеомагнитофон.


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

                                                          Опять же, если посмотреть на существующие клиент-банки, тонкие, российские, то там опять используется IE, а все остальное - побоку.

                                                          iEddy Достаточно вольное определение... напоминает решение, подогнанное под ответ
                                                          На самом деле изначально идея тонкого клиента заключалась в том, чтобы освободить компьютеры на рабочих местах от вычислений, передав их серверу.
                                                          Т.е. клиентское приложение занимается только отображением и вводом информации и не занимается ее обработкой (view в парадигме model-view-presenter).

                                                          Согласен, слукавил Тем не менее, мало кто предоставляет только отображение, а обработка на стороне клиента повышает скорость реакции системы.

                                                          Заблуждение - браузеры (не знаю про все, но IE - 100%) изначально сделаны так, что их функциональность можно расширять неограниченно, причем с помощью разных технологий (Java, ActiveX, flash и т.д.)
                                                          ВОТ ИМЕННО - IE. Так мы от него никогда не отвяжемся. А разные технологии больше нагружают именно клиентскую часть, что тоже не слишком тонко. И потом, где эти технологии? ActiveX - исключительно IE под Windows, Java - да, везде, но под винду - хе-хе. flash, pdf? А что если написать клиент-банк на флэше? Вот уж я действительно порадуюсь цельному куску. Зато есть практически везде, занимает мало, ставится быстро, в IE даже автоматически

                                                          Сейчас существующие браузеры совместимы хоть на каком-то минимальном уровне, ты предлагаешь сделать еще один браузер, который ни с кем по определению не будет совместим.
                                                          А как совместимы разные реализации клиент-банков даже от одной фирмы? "Единое информационное пространство"!

                                                          Распространенное заблуждение - с помощью DHTML/JScript можно реализовать сколь угодно навороченный интерфейс . Что касается логики - во-первых, в тонком клиенте она должна стремиться к нулю, а во-вторых, на jscript можно реализовать все необходимую прикладную логику.
                                                          Киньте в меня ссылочкой, пожалуйста. Примерчиков, pls. Поучиться.

                                                          В общем, стало примерно понятно. Спасибо всем за высказанное мнение.

                                                          Комментарий


                                                          • #30
                                                            Lexy2

                                                            Клиент-банк - это все-таки специализированная система, а в специализированной системе можно соптимизировать что-нибудь, в отличие от универсальной

                                                            Вы все-таки определитесь - система должна быть универсальной или специализированной?

                                                            если посмотреть на существующие клиент-банки, тонкие, российские, то там опять используется IE... Так мы от него никогда не отвяжемся

                                                            А зачем от него отвязываться? Что это самоцель такая?
                                                            Может стоит задуматься, почему все разрабатывают под IE? 1) наиболее распространенный 2) наиболее продвинутый в плане предоставляемого функционала. Естественнго сначала все делают под него.
                                                            Возникает вопрос - можно ли сделать кроссбраузерное приложение? Конечно можно. Только оно будет или слишком убогим по сравнению с возможностями, реализуемыми под IE (если пользоваться чистым HTML), или придется писать фактически несколько разных клиентских частей, заточенных под каждый браузер. Почему-то это вопрос снимается сам собой после оценки целесообразности разработки с точки зрения стоимость/количество клиентов,пользующихся этим браузером.

                                                            Киньте в меня ссылочкой, пожалуйста. Примерчиков...
                                                            Весь интернет является одним большим примерчиком... особенно если посмотреть на сайты дизайн-студий. Я бы предложил пойти от противного - приведите пример того, что нельзя сделать на DHTML/CSS/JScript,

                                                            Комментарий

                                                            Пользователи, просматривающие эту тему

                                                            Свернуть

                                                            Присутствует 1. Участников: 0, гостей: 1.

                                                            Обработка...
                                                            X