Adapters and Beans
The brief outline of some of the capabilities of entity beans, session beans, and message-driven beans in the previous sections is bound to create some doubt in terms of the usefulness of JCA as compared with EJB. The benefits and strengths of JCA are not in its system contracts as much as in the formalization of the client API in the form of the CCI. Future versions of JCA will probably have a more comprehensive client API and stronger support for emerging XML-based protocols and APIs. There is no reason why this cannot be done with EJBs, but the objectives of EJB and JCA are different. EJB is a component model for distributing business logic of the J2EE application in relevant components. JCA is a standard method of accessing legacy systems.
Of the three types of beans, the session bean will tend to be the most likely client of JCA resource adapters. Entity beans map Java objects to persistent data models, and it is unlikely that entity beans will need to access JCA resource adapters. There can be times when an entity bean maps its schema (fields and relationships) to the JCA interface (XML document). The resource adapter can then store the document or data in the legacy system's database.
It is very likely that JCA adapters will interact with entity and session beans, especially those of other J2EE applications. Message-driven beans will be useful in triggering application components upon arrival of JMS messages from external applications. The same mechanism can be used to trigger resource adapters if required. The bottom line is that resource adapters will collaborate with enterprise Java beans and support complex integration patterns.