Веб-клиенты против толстых / богатых клиентов?

Question

Моя компания является поставщиком программных решений для крупной телекоммуникационной компании. В настоящее время среда основана на IBM WebSphere, и внешние серверы IBM Portal взаимодействуют с кластером внутренних серверных приложений WebSphere, предоставляющих EJB-сервисы. Некоторые портлеты используют наш собственный MVC-шаблон, а некоторые написаны на JSF.

Недавно мы создали проверенное на практике приложение для многофункционального / толстого клиента, которое напрямую взаимодействует с EJB-компонентами на внутренних серверах. Он был написан с использованием платформы NetBeans и использует клиентскую библиотеку приложений WebSphere для установления связи с EJB.

Действительно болезненным было заставить клиента использовать безопасную связь JAAS / SSL. Но после того, как это было решено, мы обнаружили, что расширенный клиент имеет ряд преимуществ по сравнению с клиентскими приложениями веб-портала, к которым мы привыкли:

• Огромное преимущество в производительности (CORBA против HTTP, исключить посредника Portal Server)
• Разработка упрощается и ускоряется благодаря использованию визуального дизайнера NetBeans и в целом надежной архитектуры Swing
• Цикл отладки сокращается из-за отсутствия необходимости развертывания клиентского приложения на тестовом сервере
• Нет путаницы технологий, как при веб-разработке (Struts, JSF, JQuery, HTML, JSTL и т. Д. И т. Д.)

Пройдя некоторое время, испытывая боль от веб-разработки (даже JSF), я пришел к следующему выводу: богатые клиенты подходят не для каждой ситуации, но когда вы разрабатываете внутри компании решение на основе интрасети, тогда вы бы с ума сошли, если бы не рассматривали платформу NetBeans или Eclipse RCP.

Есть ли комментарии / опыт работы с богатыми клиентами или веб-клиентами?

Answer 1

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

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

В нашем случае в нашем приложении есть интерфейсы к аппаратному обеспечению, сканеры находятся на последовательных портах для рабочих станций. Мы также внедрили слой JNI для принтеров, чтобы мы могли управлять приложением Print Jobs из нашего приложения. (Печать счетов)

Для запуска и распространения нового программного обеспечения у нас есть файл обновления, который мы запускаем, который проверяет файл в локальной системе на соответствие дате развертывания на сервере, чтобы узнать, обновлена ​​ли локальная система. Если система устарела, мы скачиваем необходимые файлы jar, а затем запускаем приложение. Это позволяет пользователям не заходить на веб-страницу.

Я также рекомендую эту книгу для шаблонов на стороне сервера, поскольку они относятся к новым компонентам Java EE.

Answer 2

Пока вы используете Java Web Start для развертывания, я не обязательно не согласен. Смысл веб-приложений в ИТ состоит в том, чтобы избежать путаницы при удаленном развертывании, пытаясь обновить всех до версии Y, когда версия X больше не поддерживается.

Вы получаете это бесплатно с помощью веб-приложений.