Enterprise Java Beans have become the foundation for developing distributed application components. However, the EJB standard does not include specific contracts for adapters; hence the importance of JCA specifications. Perhaps you can argue that the EJB specifications could have been extended to include adapter-specific contracts. An adapter can be conceptualized as a specialization or a new type of EJB. Just like there is an entity bean, a session bean, and a message bean, there could have been an EIS bean. However, the scope of adapters goes beyond the J2EE environment, and because EJB is a J2EE component model, a separate specification for adapters makes sense.

However, EJBs will be the primary clients of JCA resource adapters, and they will also be the primary J2EE application access points for resource adapters. The relationship between EJBs and resource adapters is bidirectional, and the resulting scenarios can range from simple to complex. The job of the application assembler will be to tie together the relevant EJB components and JCA adapters, and ensure the integrity of the J2EE application.

Perhaps the JCA and EJB specifications will merge at some point, especially because there is an overlap in their roles as well as in their capabilities. The intent of JCA is different from the EJB objectives, which are restricted to J2EE environments. Nonetheless, sometimes a session bean or a message-driven bean can do the job of application integration; and if it's a simpler design pattern, it could be justified.