Enterprise Java Beans have become the foundation for
developing distributed application components.
A D V E R T I S E M E N T
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.
|
