Используя клиентскую банку в EJB 3 и шаблонах разработки
Я плохо знаком с EJB 3 и довольно смущен с некоторыми сомнениями, которым Google не предоставлял удовлетворительный ответ.
Я пытаюсь создать платформу с некоторыми базовыми классами и некоторыми служебными методами, которые могут использовать мои другие приложения. Все приложения должны быть развернуты на том же сервере.
Когда я пытаюсь создать новый проект EJB 3.0 в затмении, это спрашивает, хочу ли я создать клиентскую банку также. Какой цели эта клиентская банка служит? Мой ejbmodule добавляется как часть файла EAR. Мне действительно нужна эта клиентская банка? Я должен создать и локальные и удаленные интерфейсы? Или просто удаленные интерфейсы сделают?
Я решил сохранить все интерфейсы в проекте названными projCommon и бобовыми определениями в projApps. Удаленные интерфейсы, которые реализуют классы компонента, находятся в projCommon. Таким образом, projApps зависит от projCommon.
Я планирую использовать метод делегата, определенный в projCommon для вызова классов компонента. Это будет означать, что projCommon также зависит от projApps, rt? И вывод к круговой зависимости.
Как точно РАЗВЕ EJB's непосредственно введен?
Было бы действительно полезно, если можно любезно дать объяснение моим сомнениям.
1 ответ
Когда я пытаюсь создать новый EJB 3.0 в eclipse, он спрашивает, хочу ли я также создать клиентскую банку. Что Для чего служит этот клиентский jar?
Клиентский JAR-файл EJB - это необязательный JAR-файл, который может содержать все файлы классов, необходимые клиентской программе для использования клиентского представления корпоративных компонентов EJB, содержащихся в JAR-файле EJB. Если вы решите не создавать клиентский JAR-файл для модуля EJB, все классы клиентского интерфейса будут в файле EJB JAR
Мой ejbmodule добавлен как часть EAR файл. Так мне действительно нужно это клиентская банка?
На самом деле вам не нужен клиент EJB, он просто предоставляет более простой пакет для использования EJB от клиента.
Нужно ли мне создавать как локальные, так и удаленные интерфейсы? Или просто удаленный интерфейсы подойдут?
Если все ваши EJB находятся в одном EAR, вы можете использовать локальные интерфейсы, если вам не нужны удаленные интерфейсы. Локальные интерфейсы более эффективны, вызовы выполняются по ссылке.
Некоторые контейнеры (например, WebSphere) оптимизируют это во время выполнения для вас и автоматически вызывают локальные интерфейсы, если это возможно.
Я решил оставить все интерфейсы в проекте под названием projCommon и определения bean-компонентов в projApps. В удаленные интерфейсы, которые bean-компонент Реализация классов находится в projCommon. Итак, projApps зависит от projCommon.
Я бы организовал свои проекты по функциональным областям. Совершайте локальные вызовы в функциональных областях и удаленные за пределами функциональных областей. Это позволяет позже разделить функциональность, которая будет развернута на разных серверах, для ее масштабирования.Это также делает код более модульным. Это также позволяет избежать любых циклических зависимостей.
Как именно EJB напрямую связаны вводили?
То, как это работает, не имеет значения, это будет делать контейнер. Вся суть J2EE в том, чтобы абстрагироваться от того, как.
Согласно http://www.developer.com/print.php/3650661 :
Контейнеры EJB 3 предоставляют средства для внедрения различных типов ресурсов в сессионные компоненты без сохранения состояния. Обычно для выполнения пользовательских задач или обработки запросов от клиентских приложений бизнес-методы в сессионном компоненте требуют одного или нескольких типов ресурсов. Эти ресурсы могут быть другими сессионными компонентами, источниками данных или очередями сообщений.
Ресурсы, которые пытается использовать сессионный компонент без сохранения состояния, могут быть введены с помощью аннотаций или дескрипторов развертывания. Ресурсы могут быть получены путем аннотации переменных экземпляра или аннотации методов установки.