Изучаю EJB3. Посему вопросы наверное примитивные.

1. 
Имею session bean, бизнес интерфейс которого (A) возвращает ссылку на другой  бизнес интерфейс (B - отдельный bean). По-сути - A - фабрика B.
Вопрос - как в EJB 3 можно выполнить инициализацию бина с состоянием не добавляет метод инициализации в его бизнес (remote) интерфейс? Грубо говоря, я не хочу допускать инициализации (B) за пределами моей фабрики (A). 

2.
Поясните разницу между @local локальными и @remote удалёнными вызовами (методами) в EJB3. Ранее, насколько помню, это должны были быть совершенно различные интерфейсы, теперь методы можно смешивать внутри одного бизнес-интерфейса (не понятно как это работает).

На вряд ли это будет фабрикой в такой ситуации. Скорее это ближе к сервис-локатору, чем к фабрике.
Инициализация EJB компонента производится самим компонентом, поскольку создаётся он контейнером EJB. 
Инициализировать можно в конструкторе без параметров и в методе помеченном аннотацией @PostConstruct (последний будет выполнен после инжекции бинов, от которых он зависит).

Если ситуация такая, что нужно инициализировать бин, перед его использованием, то можно можно сделать это в "@PostConstruct" методе того компонента куда он был инжектирован. (т.е. если бину A засеттить бин B, то инициализацию бина B можно сделать в методе помеченном аннотацией @PostConstruct бина A). 


А как кстати ссылки на бины стали доступны вашей фабрике? Они были инжектированы контейнером EJB? Если так то ещё можно произвести инициализацию в методе @PostConstruct вашей фабрики. 


При вызове методов @Local интерфейса параметры можно передавать по ссылке. Т.е. то что передашь, может быть изменено в вызываемом методе и результат будет доступен в вызывающем (например, тот же callback в данном случае прокатит). С параметрами  методов @Remote интерфейса такой фокус не пройдёт. Вероятно по тому, что контейнер подготавливает параметры для удаленного вызова (проксирует, сериализует). Отсюда и простой вывод, то для увеличения производительности не стоит использовать @Remote интерфейс где в нем нет необходимости (т.е. не предполагается удалённого вызова).

Возможно ли вызвать методы @Local интерфейса бина B если он был получен как Remote (внутри бина А)? и наоборот..?
Либо бин можно получить только однозначно либо для Remote, либо для Local использования (одно из двух, но не оба одновременно)?

@Remote интерфейс насколько мне известно проксируется. Т.е. при его инъекции мы получаем прокси, которая дополнительно сериализует и десериальзует параметры вызова т.к. это необходимо для удалённых клиентов (отсюда нельзя в remote интерфейс передавать параметры по ссылке). А @Local интерфейс - это обыкновенный интерфейс в который можно передавать значения по ссылке.
Можно ли привести @Remote интерфейс к локальному? Думаю что нет, это как минимум нелогично. А привести ссылку на local к remote интерфейсу вполне должно получиться. Так же думаю, что попробовать поиграть с instanceof думаю никто не помешает.

Спасибо за мысли. Поиграюсь -- напишу о результате.

Приведенный пример не работает, потому что (myBean instanceof MyInterfaceLocal) в методе getMyBean() вернет false -- не получается откастить к локальному интерфейсу.
В то же время если в этом примере MyInterfaceLocal объявить как @Remote то кастинг от одного ремоут интерфеса к другому будет успешным и методы обоих будут корректно вызываться на одном и том же инстасе бина.
Но мне необходимо скрыть инициализацию (вызов localInitialization()) от внешних потребителей. @PostConstruct и т.п. методы не подходят потому что в реальном примере в localInitialization() каждый раз передается текущее состояние вызывающего бина (в примере MyBeanCaller).

Я написал похожий тест, но только с инъекцией. Просмотрел типы объектов и понял, что контейнер всегда инжектирует прокси. Будь это локалный или удаленный интерфейс, но вероятно с разной имплементацией. Доля логики в этом конечно же есть. Ведь по спецификации контейнер не гарантирует что один и тот же вызов сделанный 2 раза будет выполнен на одном stateless бине (а я тестировал именно на stateless), заглушка для stateless бина запросто может вытаскивать для каждого вызова свободный объект из пула. Привести типы естественно не удалось.





Попробую написать тест и для stateful бина.


Такой вызов кстати возвращает ссылку на Remote интерфейс. Поскольку только они регистрируются в JNDI.

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

Я могу ошибаться, но думаю такого способа нет (только если решлекшином из проксей выцеплять, или самому написать бин таким образом, что бы он ссылку на себя выдавал наверх). Все таки это контейнеро-управляемые сущности и доступ к ним должен быть всегда через промежуточное звено. Контейнер и прокси в данном случае одно и тоже. Это важно, например, при выполнении транзакций и разраничения прав доступа - прокси и транзакцию начнёт и права проверит. 

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

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