Спецификация EJB не указывает, как должна быть выполнена кластеризация, поэтому это будет зависеть от конкретной используемой реализации. На самом деле спецификации EJB специально написаны так, чтобы не делать предположений о развертывании: они не требуют какой-либо поддержки кластеризации, но написаны таким образом, чтобы это стало возможным (и множество ограничений в модель EJB проистекает из потенциальных проблем кластеризации, например, доступа к файловой системе). Реализатор может свободно поддерживать кластеризацию или нет, и при этом соответствовать спецификации.
В Glassfish ссылка на удаленный EJB делает сам дистрибутив. См. мой ответ здесь для получения дополнительной информации. Каждый запрос может быть отправлен на другой узел. Вероятно, так работает большинство реализаций. Поэтому я бы сказал, что ваше предположение верно.
Тем не менее, я надеюсь, что они оптимизируют случай, когда один EJB вызывает другой EJB, и по возможности старается отправить вызов на тот же узел. Это будет зависеть от того, является ли развертывание однородным или нет (все узлы имеют одинаковые компоненты или нет). Опять же, спецификации немного расплывчаты в отношении таких моментов. Но я предполагаю, что большинство развертываний на практике однородны: одно и то же ухо развернуто на всех узлах.
Что касается снижения производительности удаленных и локальных вызовов, я однажды предпринял некоторые меры (на Glassfish). Смотрите мой ответ здесь. Между EJB-вызовами в том же .ear через удаленный интерфейс был в 3 раза медленнее, чем локальные вызовы. Это звучит здорово, но мы говорим о миллисекундах, так что относительные накладные расходы зависят от того, что на самом деле делают методы. Я не знаю производительность другого приложения. сервер.
Надеюсь, это поможет.