EJB без сохранения состояния: поиск баланса между производительностью и безопасностью - PullRequest
2 голосов
/ 16 сентября 2009

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

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

  • Должен ли я только отправлять имя пользователя в EJB, а затем загружать сущность User при каждом вызове EJB, или я отправляю сущность User из уровней представления?
  • Если мне нужно больше информации, чем просто сущность User (скажем, мне нужно загружать дополнительную сущность при каждом вызове EJB), отправляю ли я имя пользователя и ключ другой сущности и загружаю обе сущности на прикладном уровне, или отправить оба объекта из слоев презентации?
  • А что если мне понадобится еще больше информации для определенных вызовов EJB (> = 3 объекта)?

Когда имеет смысл отправлять реальную сущность, а не только ее ключ, или ответ никогда не перезагружается на стороне прикладного уровня? Должен ли я беспокоиться о производительности? Я слышал, что Hibernate (который я использую) использует интеллектуальное кэширование, что означает, что сущность User, вероятно, не будет перезагружаться из БД каждый раз? Что, если мои EJB-методы имеют очень малую степень детализации, и действия внешнего интерфейса могут иногда вызывать 3 или более EJB-методов, при этом каждый из них должен загрузить сущность User?

Последний связанный вопрос: я собираюсь использовать принципал JAAS для хранения имени пользователя, которое загружается EJB-компонентами. Что, если мои EJB-компоненты удаленного фасада вызывают группу локальных EJB без сохранения состояния, которые также требуют информацию о пользователе, я все еще использую принципал JAAS и загружаю сущность User в каждом из них, или есть лучший способ?

Ответы [ 2 ]

1 голос
/ 16 сентября 2009

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

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

Но, действительно, я думаю, что вы уже упомянули лучший подход: ленивая загрузка Hibernate. Вы просто взаимодействуете с объектом и позволяете ему загружать данные по требованию. В этом отношении, чтобы хорошо работать с Hibernate, объект User должен быть небольшим, чтобы его загрузка была достаточно быстрой и помещала всю большую тяжелую информацию в дочерние объекты или другие объекты. Тогда не имеет значения, нужно ли вам много загружать Пользователя; это всего лишь «указатель» на другую информацию.

Я не думаю, что это что-то меняет, если вы используете JAAS, нет. Хотя я могу сказать, что для ваших целей JAAS может быть, а может и не стоить. За то время, которое у вас уходит на интеграцию, запись разрешений, использование этих разрешений, устранение последствий SecurityManager и т. Д., Вы, возможно, могли бы в любом случае просто написать для себя простую структуру разрешений.

0 голосов
/ 17 сентября 2009

если вы сделаете только один EJB, сделайте сеанс без сохранения состояния. лично я нашел это пустышкой пустые интерфейсы

...