BlazkowiczrabiterТе, что управляются контейнером специфицированным JSR-299.
Там написано что технология должна помочь подружить JSF и EJB. Иногда обзывается Web Bean. Но CDI-bean это вообще любой проинжекченый бин, в том числе @EJB.
Осталось понять что вы с Niky4000 подразумеваетет под Application Client. Где и stateful удобен и CDI работает.

Понять-то думаю не сложно. Application client я так понял это desktop имеется ввиду? Толстый клиент?

По поводу JSF и CDI - в JSF сейчас рекомендуют использовать CDI вместо JSF Managed Beans
например:
javax.enterprise.context.SessionScoped вместо javax.faces.bean.SessionScoped.
Это да. Но не одним JSF ограничено применение CDI. Вот вы например, работаете со спрингом, и конечно же, используете все радости его IoC? В том числе и длительность жизни бинов (session, request, singleton, prototype, какие там еще есть...).
А что нам делать если мы спринг не используем? IoC-то тоже охота. Так вот CDI это в какой-то мере тоже самое, только специфицировано в JavaEE. Имплементация от JBoss Weld.
Вещь хорошая, мне понравилась очень как разобрался. Включает в себя например Annotated Qualifiers - т.е. с помощью аннотации мы можем контейнеру указать какую конкретную из имплементаций требуется заинжектить.
Продюссеры - методы, которые позволяют написать свой код, решающий какой инстанс будет заинжекчен.
И еще много другого. Отлично работает с web. Но и не только, с desktop тоже.

И еще, EJB и CDI путать не стоит, тот же класс синглетон есть и в EJB и в CDI:
javax.ejb.Singleton - EJB3.1
javax.inject.Singleton - CDI
Первый управляется контейнером EJB, второй - CDI.
И аннотация @Inject относится к CDI бинам, а @EJB - соответственно к EJB.
Так с помощью @Inject заинжектить EJB бин нельзя (хотя это легко обойти с помощью продюссеров).

Blazkowiczrabiterрекомендуют использовать CDI вместо JSF Managed Beans
И еще, EJB и CDI путать не стоит

Т.е. CDI-бины это обычные POJO, жизненым циклом которых контейнер умеет управлять, но ни к EJB, ни к Managed Bean они вообще никак не относятся?

Ну да. Они могут заменить JSF Managed бины. С помощью аннотации @Named CDI бину можно указать строковое имя, через которое потом к нему можно в файслетах обращаться. Единственная проблема - в JSF есть ViewScoped, в CDI такого нет. Но это обходится с помощью ConversationScoped.

Niky4000Понять-то думаю не сложно. Application client я так понял это desktop имеется ввиду? Толстый клиент?
Ну, да.
Продюссеры - методы, которые позволяют написать свой код, решающий какой инстанс будет заинжекчен.
И еще много другого. Отлично работает с web. Но и не только, с desktop тоже.
То есть какой экземпляр @Singleton'а отдать в пользование в какую сессию?

Не только синглетона, это может быть sessionscoped и requestscoped бин.
Фишка в том, что с помощью продюссера вы можете реализовать какую-нибудь логику, которая принимает решение какой экземпляр бина должен быть заинжекчен.




ну и далее в коде получаем доступ к IntegrationService:

BlazkowiczrabiterНу да. Они могут заменить JSF Managed бины. С помощью аннотации @Named CDI бину можно указать строковое имя, через которое потом к нему можно в файслетах обращаться. Единственная проблема - в JSF есть ViewScoped, в CDI такого нет. Но это обходится с помощью ConversationScoped.
Мда. Как JEE ни стремиться к простоте, простота для неё не достижима.

Аминь, сплю и вижу спринг.

Niky4000А всё-таки как быть с фабрикой фабрик?
И ещё, если мы создаём EntityManagerFactory и EntityManager'ы в Singleton'е, то тот клиент, который первый захватил ресурс и будет им пользоваться, а другие будут ждать.
То есть соединение с СУБД тоже как бы Singleton получается, если можно так выразиться. А если пул соединений захочется сделать, то надо List<EntityManagerFactory> и List<EntityManager> делать? И как-то определять какой em занят, а какой нет? То есть пулом ручками рулить?

Пул соединений к базе реализовывать не надо. Все уже реализовано до нас. Возьмите с Apache Commons, или готовый реализованный в ApplicationServer'е.
Потокобезопасностью синглетона можно управлять, в частности, с помощью аннотации LockType.
Если поместите синглетон в критическую секцию, то он будет потокобезопасным, но может стать и бутылочным горлышком. Где будут ждать куча клиентов своей очереди выполнить код синглетона для своего потока.