Как разделить фасад SFSB?

Question

У меня возникли некоторые проблемы при разработке приложения на основе технологии EJB 3.

Я хотел бы использовать шаблон фасада в компонентах Session для отделения моего клиента (веб-приложения) от компонентов Entity Bean.

Я использую SFSB для управления сеансом пользователя.

Итак, у меня есть FacadeLoginRemote удаленный интерфейс, который предоставляет клиенту методы doLogin(), doLogout() и т. Д. В настоящее время этот SFSB также включает некоторые другие методы, такие как getCourse(int id), getResource(int id). Не все пользователи могут получить курс и получить ресурс , поэтому Фасад выполняет некоторые проверки перед возвратом значений клиенту.

Я бы хотел разделить Facade, поместив методы getCourse() и getResource() в специальный класс для них, но оставив FacadeLoginRemote функции проверки пользовательских привилегий.

Если я сделаю несколько разных SLSB, я представлю их клиенту. Таким образом, клиент будет иметь возможность подключиться напрямую к ним, избегая проверок из FacadeLoginRemote.

Я не прав? Есть ли способ сделать это?

Заранее спасибо,

Andrea

Answer 1

Первый совет. если вы создаете веб-приложение, то более типично иметь веб-уровень и бизнес-уровень в одном приложении. В этом случае нет необходимости в удаленном взаимодействии. Ваши сессионные компоненты будут работать в той же JVM, что и веб-уровень.

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

Или это веб-приложение, которое вы говорите об удаленном приложении, размещенном кем-то еще на своих серверах, и используют ли они сервисы из ваших EJB-компонентов?

В Java EE аутентификация может выполняться в веб-модуле. Особенно если вы используете локальные bean-компоненты, эта аутентификация (субъект безопасности) будет автоматически распространяться на EJB-компоненты. Вы можете комментировать ваши EJB-компоненты, чтобы требовать определенной роли безопасности. Если пользователь не аутентифицирован, у него нет этой роли, и служба будет отклонена.

В этом случае не имеет значения, пытается ли клиент подключиться напрямую к bean-компонентам с помощью методов getCourse() и т. Д.

Мне интересно, как вы реализовали doLogin() в своем EJB. Я предполагаю, что вы сделали что-то нестандартное, так как, к сожалению, насколько мне известно, EJB3 не имеет простого способа выполнить программный вход в систему с помощью специального метода для конкретного компонента. Безопасность в основном декларативна, и клиент должен будет предоставить детали аутентификации при доступе к любому бину. Например. когда вы запрашиваете bean-компоненты от удаленного JNDI, вы должны предоставить эти данные при первоначальном соединении JNDI с удаленным сервером.