新しいJSR 299「Java EEのコンテキストと依存性注入」は、「スコープ」の概念に基づいているようです。Web層がなくHTTPセッションがない場合、CDIは意味がありますか？
Beanは作成され、サポートされているスコープ（アプリケーション、セッション（HTTPセッションにマッピングされている）、会話、およびリクエスト）のいずれかに関連付けられます。
マネージドBeanが存在しないため、マネージドBeanはどのコンテキストにも関連付けられないため、HTTPセッションがない場合（たとえば、EJBリモート処理を通じて機能を公開するエンタープライズアプリケーションの場合）、CDIを使用することは理にかなっています）？
このようなシナリオでCDIを使用することは可能ですか？どのような利点がありますか？それは自分の質問のことを思い出す
は、私はいくつかの時間前に尋ねた：How does @SessionScoped work with EJB? Is CDI only for web-tier?
「スコープ」のアイデアが唯一のHTTPセッションの場合に該当すると思われます。
しかし、要求がHTTPであっても、application-singleton beanを実装する方法として、@ApplicationScopedスコープの有効な使用方法がわかります。任意のJava EE Webサービスの呼び出し中に
（...）
、任意の時に
：
Javadoc言う：
適用範囲がアクティブであります任意のEJBの非同期メソッド呼び出し中の、任意のEJBのリモートメソッド呼び出しEJB タイムアウト方法および任意のEJBメッセージドリブン Beanへのメッセージ配信中のいずれかの呼び出し、
はまた、独自のスコープを作成することができます。 CDIは非常に拡張性が高く、さまざまな状況で使用できます。また、HttpSessionもHttpRequestもないSEアプリケーションでも使用されています。
それ以外にも、CDIはライフサイクル管理だけでなく、それを使って依存関係注入を行うことができ、インタフェースを実装から非常にクリーンな方法で分離することができます。また、インターセプタとデコレータを使用してAOP技法を実行したり、CDIイベントを利用して非常に疎結合のObserverパターンを作成することもできます。