EJB3 Remote vs Webservices, производительность?

Question

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

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

Я планирую выставить удаленный EJB через JNDI с сервером Glassfish, чтобы 1000 человек могли использовать этот EJB одновременно (я думаю, что может быть 5-50 запросов в секунду) для получения данных, необходимых для локальных вычислений, а затем отправить результаты ...

Дорого ли выставлять EJB многим клиентам? Было бы лучше использовать веб-сервисы, RMI, другое решение?

Вы бы порекомендовали мне другую архитектуру для того, что я собираюсь делать?

Answer 1

Во-первых, с чисто архитектурной точки зрения EJB-компоненты используются для создания распределенных приложений, веб-службы - это технология интеграции, и они на самом деле не конкурируют друг с другом. В вашем случае EJB будет естественным выбором (мы говорим о EJB3, верно?), И сессионные компоненты очень хорошо масштабируются.

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

Итак, поскольку все ваши клиенты на 100% являются Java-клиентами, я бы просто предоставил сессионные компоненты без сохранения состояния ¹ и избежал бы издержек на SOAP / XML-маршалинг / демаршалинг и написание WSDL (если однажды вам потребуется представить свои сервисы как веб-сервисы, это все еще возможно и просто).

¹ Использование JPA или чего-либо еще для доступа к данным остается на ваше усмотрение.

Answer 2

Мой 2p заключается в том, что предложение клиента Webservice или XML / http проще и стандартнее с точки зрения клиента. Одним из преимуществ является то, что они не должны быть клиентами Java, если это веб-служба SOAP.

Answer 3

Я прочитал на форуме, что может быть плохой идеей извлекать сущности из клиента, потому что прокси-сервер сохраняется и генерирует трафик

Один протестированный парень и 40ko-сериализованный список из 300 объектов сгенерировали 3,6-миллионный трафик сети в wireshark, но если вы используете EntityManager.clear () для отсоединения сущностей или используете pojos d, чтобы возвращать тип удаленным функциям, тогда все нормально:)