Les haricots de Java d'entreprise sont devenus la base pour développer les composants distribués d'application. Cependant, la norme d'EJB n'inclut pas les contrats spécifiques pour des adapteurs ; par conséquent l'importance des caractéristiques de JCA. Peut-être vous pouvez arguer du fait que les caractéristiques d'EJB pourraient avoir été prolongées pour inclure les contrats adapteur-spécifiques. Un adapteur peut être conceptualisé comme spécialisation ou nouveau type d'EJB. Juste comme il y a un haricot d'entité, un haricot de session, et un haricot de message, là pourrait avoir été un haricot d'EIS. Cependant, la portée des adapteurs dépasse l'environnement de J2EE, et parce qu'EJB est un modèle composant de J2EE, des spécifications séparées pour le sens de marques d'adapteurs.

Cependant, EJBs sera les clients primaires des adapteurs de ressource de JCA, et elles seront également les points d'accès primaires d'application de J2EE pour des adapteurs de ressource. Le rapport entre EJBs et adapteurs de ressource est bidirectionnel, et les scénarios résultants peuvent s'étendre de simple au complexe. Le travail de l'assembleur d'application sera d'attacher ensemble les composants appropriés d'EJB et des adapteurs de JCA, et assure l'intégrité de l'application de J2EE.

Les caractéristiques peut-être de JCA et d'EJB fusionneront à un certain point, particulièrement parce qu'il y a un chevauchement dans leurs rôles aussi bien que dans leurs possibilités. L'intention de JCA est différente des objectifs d'EJB, qui sont limités aux environnements de J2EE. Néanmoins, parfois un haricot de session ou un haricot message-conduit peut faire le travail de l'intégration d'application ; et si c'est un modèle plus simple de conception, elle pourrait être justifiée.