Я пытаюсь понять, какова цель и почему нам нужны разные клиентские представления в EJB. Может кто-нибудь попытаться объяснить?
Ответы:
Просмотр удаленного клиента
Когда ваш EJB и его клиенты будут находиться в распределенной среде, то есть EJB и клиенты будут находиться на отдельных виртуальных машинах Java. Пример: EJB, размещенные на сервере приложений WebSphere, и сервлеты, использующие EJB API, размещенные на сервере Tomcat.
Просмотр локального клиента
Только когда гарантировано, что другие корпоративные компоненты или клиенты будут обращаться к компоненту только в рамках одной JVM. Пример, EJB и сервлеты развернуты на одном сервере WebSphere.
Просмотр без интерфейса
Практически то же самое, что и представление локального клиента, но с некоторыми отличиями. В этом случае ваш класс bean-компонента не требуется для реализации клиентских интерфейсов просмотра. Все общедоступные методы класса bean-компонента автоматически предоставляются вызывающей стороне. представление без интерфейса всегда получает ссылку на EJB - точно так же, как локальные или удаленные представления - либо через внедрение, либо через поиск JNDI; но тип Java ссылки EJB - это тип класса компонента, а не тип локального интерфейса. Это удобство, представленное как часть Java EE6.
Разница между представлением локального клиента и представлением без интерфейса
В случае представления без интерфейса клиент и целевой компонент должны быть упакованы в одном приложении (EAR). В случае локального просмотра клиент может быть упакован в отдельное приложение, чем корпоративное приложение. Таким образом, это дает больше гибкости с точки зрения детализации ваших компонентов.
Вы можете использовать представление локального клиента и представление без интерфейса в зависимости от сценария использования API. Весьма вероятно, что представление без интерфейса получит гибкие функции в будущих спецификациях.
Причина
Исторически или иначе, клиент, желающий использовать службы EJB, должен был «искать» компонент в контейнере (с определенными начальными контекстами). Это произошло потому, что все вызовы выполняются через специальную ссылку EJB (прокси), предоставляемую контейнером. Это позволяет контейнеру предоставлять все дополнительные службы bean-компонентов, такие как объединение в пул, транзакции, управляемые контейнером, и т. Д. Таким образом, клиент не может явно создать экземпляр EJB с newоператором. Вид клиента предоставляется через определенные интерфейсы, к которым у клиента будет доступ. Реализация прокси на стороне сервера осуществляется на основе этих интерфейсов. Различные клиентские представления определены для различных сценариев развертывания, как указано выше.
newвы получите новый экземпляр. Это все. Этот новый экземпляр не будет иметь какой-либо «поддержки» из контейнера с точки зрения объединения, настройки его контекста и т. Д. Вы работаете самостоятельно.
Согласно разделу 3.2.2 спецификации EJB 3.1:
Доступ к корпоративному компоненту через представление локального клиента требуется только для поддержки локальных клиентов, упакованных в том же приложении, что и корпоративный компонент, обеспечивающий представление локального клиента. Совместимые реализации этой спецификации могут дополнительно поддерживать доступ к локальному клиентскому представлению корпоративного компонента из локального клиента, упакованного в другом приложении. Требования к конфигурации для межпрограммного доступа к представлению локального клиента зависят от поставщика и выходят за рамки данной спецификации. Приложения, полагающиеся на доступ между приложениями к локальному клиентскому представлению, не переносятся.
Представление без интерфейса - это просто удобная функция, которая позволяет компоненту предоставлять представление локального клиента без необходимости объявлять отдельный интерфейс.