Клиент приложения получает доступ к EJB на Glassfish через удаленный интерфейс.Могу ли я сделать это через локальный интерфейс?

Question

Недавно я просматривал статью Netbeans о том, как создать и Enterprise Application Client, который получает доступ к EJB-развертыванию на Glassfish. ( Ссылка на статью здесь ) У меня есть пара вопросов по этой статье.

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

Так что мой вопрос: зачем здесь использовать интерфейс remote?Это потому, что клиентский компьютер и Glassfish могут быть на разных компьютерах (разных JVM).Поэтому, если я скажу, что клиентский код и сервер Glassfish находятся на одной машине (той же JVM), могу ли я каким-то образом изменить дизайн, чтобы использовать локальный интерфейс, чтобы избежать накладных расходов.

Поскольку все коды приведены в статье, я не буду публиковать ее здесь снова.Пожалуйста, дайте мне знать, если вы все еще настаиваете, чтобы я отправил код

Answer 1

Часто задаваемые вопросы EJB на сайте Glassfish решают этот вопрос , и совершенно очевидно, что это невозможно, если вы не используете встроенный контейнер:

У меня естьКомпонент EJB с локальным интерфейсом.Могу ли я получить к нему доступ из приложения-клиента или автономного Java-клиента?

Если на сервере запущен компонент EJB, нет.Локальное представление EJB - это оптимизированный путь вызова, который использует семантику вызова по ссылке.Он доступен только для веб-компонентов и компонентов EJB, которые являются частью того же приложения, что и целевой компонент EJB.Чтобы получить доступ к компонентам EJB, работающим на сервере, из Application Client или автономного Java-клиента, вам необходимо использовать либо интерфейс Remote 3.x Business, либо интерфейс 2.x Home, либо веб-службы.

Одной из альтернатив при использовании GlassFish v3 является использование API-интерфейса EJB 3.1 Embeddable.Это позволяет программе Java SE напрямую выполнять компоненты EJB в той же JVM, не используя серверный процесс.

Следующий вопрос также дает подсказку, почему это является причиной- спецификация Java EE никогда явно не указывала, что локальные интерфейсы ДОЛЖНЫ быть доступны для нескольких приложений в одной JVM / контейнере.

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

Answer 2

Используется удаленный интерфейс, поскольку клиент приложения находится в отдельной JVM, а не на сервере EJB.Единственный способ общаться между ними - через сокет.

То, о чем вы говорите, - это нечто более похожее на встроенный EJB-сервер, встроенный в клиент.Это не то, что поддерживает модель клиента приложения.

GFv3 может быть встроен, так что это может быть сделано, но это не описанная часть модели или профилей Java EE, где модель клиента приложения является частьюJava EE spec.