Я пытаюсь решить между локальным и удаленным EJB для уровня доступа к данным. Благодаря большому количеству исследований, похоже, общий консенсус в том, что если я хочу масштабируемость, я должен использовать Remote EJB.Масштабируемость удаленного EJB и локального EJB
Что это значит? Я не могу найти ничего, что явно показывает, почему Remote EJB может масштабироваться, а Local не может.
Я не уверен, где вы получили общий консенсус.
Запомните Fowler's First Law of Distributed Objects.
Вы должны сделать вызов по сети с объекта Java в реляционную базу данных (если только это не база данных в памяти). Почему добавление дополнительного хопа из вашего сеансового компонента в удаленный объект будет более быстрым или более масштабируемым?
Кроме того, масштабируемость определяется намного большим, чем это.
Я бы сказал, что ваш консенсус неверен: предпочитайте местные, если можете.
Хотя я знаю, что это неправильно, я признаю это чувство с десятилетия назад. Люди думали, что деловая логика на отдельном сервере помогла бы с масштабированием, поскольку тогда вы могли бы добавить более тяжелый сервер для бизнес-логики и множество дополнительных узлов для обработки веб-запросов. Эта идея была очень распространенной. Тогда я говорил часами, чтобы вытащить его из головы людей. –
Разница заключается в том:
LocalBean: Это будет работать на том же EJB контейнер в качестве вызывающего абонента. Это означает, что каждый звонок быстрее по сравнению с удаленным вызовом. Но он останется на том же сервере, даже если у него закончились ресурсы.
RemoteBean: Это будет работать на одном узле в кластере EJB. Он перейдет на другой узел, если вы используете auf of ressources. Вы также можете добавить узлы для масштабирования.
редактировать Если вы хотите, чтобы ваши бобы только для редактирования базы данных, использование LocalBeans .. , как @duffymo писал
Если у вас работает auf ресурсов, вполне вероятно, что уровень Servlet уже исчерпал ресурсы, а ваш балансировщик нагрузки перенаправил запрос на другой узел. В большинстве случаев EJB слишком мало работают, чтобы расплатиться. Такие вещи, как базы данных, поисковые системы, системы обмена сообщениями, серверы заданий и т. Д., Часто (почти всегда) получают выгоду от своего собственного сервера, но EJB редко. –
я предполагаю, что мы говорим классический Java EE сценарий:
client (usually browser) ----> Servlet ----> EJB ----> DB
В этом случае мы могли бы либо находить Servlet и EJB, либо использовать локальные интерфейсы или иметь сервлет и EJB в отдельных слоях и, следовательно, нужны удаленные интерфейсы - конечно, используя дистанционный интерфейс e потребует дополнительного сетевого хопа, однако он, возможно, может принести пользу.
Рассмотрим сначала масштабирование локального сценария. Двигатель сервлета/EJB иссякает, поэтому мы развертываем еще один, получаем больше энергии (очевидно, какой-то опрыскиватель перед сервлетом должен распределять работу. Нам нужно больше энергии, добавить еще больше уровней Servlet/EJB. Но ...
Предположим, что наш слой EJB действительно очень тяжелый, возможно, выполнив сложное вычисление после сбора данных. Для достижения требуемой производительности мы масштабируем объединенный уровень Servlet/EJB, НО нам не нужны все эти копии движка Servlet, они практически не работают, все работает на уровне EJB, мы без причины потребляем память и другие ресурсы. В таком сценарии использование удаленных EJB может дать нам выигрыш, мы можем развернуть независимо, получать как можно больше копий движка сервлетов и движка EJB, а стоимость удаленного хопа может быть незначительной по сравнению со сложными вычислительными затратами.
На практике последний пример редок. EJB мало работают, и если нам требуется больше энергии при поступлении большего количества запросов, это означает, что нам нужны как дополнительные сервлеты, так и бэкэнды JSF и компоненты EJB. Может быть, иногда есть один боб (или несколько), которые выполняют тяжелые вычисления. Если это так; помещайте их только на дополнительный сервер. Но OP просит поместить ВСЕ EJB по умолчанию на удаленный сервер, чтобы масштабировать, а это не так. Большинство компонентов EJB обычно просто координируют транзакцию и несколько вызовов БД. –
Согласен. Важно только разделение «особых» EJB. – djna
Ну, я понимаю принятый ответ, но использование удаленного EJB не всегда означает распределенную бизнес-логику на нескольких серверах.
Хорошим примером масштабируемости с использованием дистанционного EJB является API Gateways. Вы можете настроить шлюз API как клиент EJB (один WAR, на пример) для использования удаленного EJB с разных серверов (EAR, на пример), который содержит бизнес-логику.
Используя эту идею, вы можете иметь более одного сервера для предоставления удаленных EJB для шлюзов API, распределяя работу для всех серверов в каждом lookup.
Удаленный и локальный не имеет ничего общего с масштабируемостью. Он ссылается только на то, может ли EJB получить доступ к удаленному вызову или к локальному вызову. На практике Remote никогда не используется, но в редких случаях, потому что вся логика обычно находится на одном сервере приложений, поэтому удаленные вызовы добавляют латентность и снижают производительность для общих случаев. –