Стоит ли использовать сервер приложений вместе с богатым / толстым клиентом? - PullRequest
0 голосов
/ 07 января 2012

Я знаю, что серверы приложений интенсивно используются, когда речь идет о веб-приложениях.Здесь у вас есть тонкий клиент (браузер), взаимодействующий с сервером приложений, таким как tomcat или jboss.

Теперь я более подробно рассмотрел коммерческое программное обеспечение, которое также использует сервер приложений вместе с богатым / толстым клиентом.,(<100 пользователей) Здесь богатый клиент связывается с серверным программным обеспечением, работающим на сервере приложений (например, tomcat, jboss, ...) </p>

Я не вижу преимуществ, почему кто-то использует сервер приложений вместе с расширенным клиентом.

Какие преимущества имеет решение b по сравнению с решением a?

a) Богатый клиент <-> Простой сервер, работающий на jvm

b) Богатый клиент <-> сервер, работающий на сервере приложений, таком как tomcat или jboss

Спасибо

Ответы [ 2 ]

1 голос
/ 07 января 2012

Сервер приложений с толстым клиентом предоставляет те же функции, что и приложение с веб-приложением. Если бы серверы приложений были полезны только для веб-приложений, не было бы смысла использовать их даже для веб-приложений: достаточно было бы простого сервера Tomcat или Jetty.

Преимущества полноценного сервера приложений Java EE следующие:

  • декларативное управление транзакциями
  • распределенные транзакции (например, между несколькими базами данных и / или базой данных и сервером JMS)
  • декларативная и программная безопасность
  • пул потоков
  • обработка параллелизма
  • JPA поддержка персистентности
  • Поддержка JMS для асинхронной связи
  • управление ресурсами (пулы соединений и т. Д.)
  • возможность выставлять сессионные компоненты как веб-сервисы
  • внедрение зависимости
  • и т.д.

Все эти функции полезны, независимо от того, имеет ли пользовательский интерфейс веб-интерфейс или нет. Если ваше приложение не использует все эти функции, вам не нужен сервер приложений. Если вам все это не нужно и вы предпочитаете интегрировать различные компоненты (менеджер транзакций, движок JPA, сервер JMS и т. Д.) Самостоятельно, вы можете просто использовать Spring с веб-контейнером или без него, таким как Tomcat или Jetty.

0 голосов
/ 07 января 2012

Сервер будет иметь три цели:

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

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

Если вам нужен пример, возьмите Microsoft Access. Вероятно, мы можем согласиться с тем, что это приложение базы данных с толстым клиентом. Он изменяет базу данных более или менее напрямую (в любом случае, в случае баз данных Jet / ACE) и может совместно использовать базу данных с другими процессами. Но из-за того, что слишком много пользователей, в частности, получают доступ к файлу общей базы данных по сети, коррупция практически неизбежна. Однако если вы внедрите SQL Server для обработки базы данных и позволите Access выполнять работу пользовательского интерфейса и генерировать запросы и т. Д., Вы получите большинство из тех же преимуществ с гораздо меньшим риском разрушения базы данных.

Что касается того, является ли автономный сервер лучше или хуже, чем веб-приложение в Tomcat или что-то подобное: приложение в одном из этих контейнеров имеет те же преимущества, что и веб-приложение, работающее в Tomcat, по сравнению с автономным веб-приложением на Java. ... вам не нужно беспокоиться о деталях низкого уровня. Вы имеете дело с запросами и ответами, а не с сокетами и пакетами. Кроме того, использование известного и стандартного протокола, такого как HTTP, упрощает для других программ (включая новые версии вашего собственного программного обеспечения) связь с вами. В свою очередь, однако, вы должны согласовать коммуникации вашего приложения с тем, как работает ваш конкретный контейнер. Можете ли вы сделать это, зависит только от вас.

...