JSP Servlet J2EE Questions 10

46: Brief description about local interfaces?
A: EJB was originally designed around remote invocation using the Java Remote
Method Invocation (RMI) mechanism, and later extended to support to standard CORBA
transport for these calls using RMI/IIOP. This design allowed for maximum
flexibility in developing applications without consideration for the deployment
scenario, and was a strong feature in support of a goal of component reuse in J2EE.
Many developers are using EJBs locally -- that is, some or all of their EJB calls
are between beans in a single container.
With this feedback in mind, the EJB 2.0 expert group has created a local interface
mechanism. The local interface may be defined for a bean during development, to
allow streamlined calls to the bean if a caller is in the same container. This does
not involve the overhead involved with RMI like marshalling etc. This facility will
thus improve the performance of applications in which co-location is planned.
Local interfaces also provide the foundation for container-managed relationships
among entity beans with container-managed persistence.

47: What are the special design care that must be taken when you work with
local interfaces?
A: EIt is important to understand that the calling semantics of local
interfaces are different from those of remote interfaces. For example, remote
interfaces pass parameters using call-by-value semantics, while local interfaces
use call-by-reference.
This means that in order to use local interfaces safely, application developers
need to carefully consider potential deployment scenarios up front, then decide
which interfaces can be local and which remote, and finally, develop the
application code with these choices in mind.
While EJB 2.0 local interfaces are extremely useful in some situations, the
long-term costs of these choices, especially when changing requirements and
component reuse are taken into account, need to be factored into the design
decision.

48: What happens if remove( ) is never invoked on a session bean?
A: In case of a stateless session bean it may not matter if we call or not as
in both cases nothing is done. The number of beans in cache is managed by the
container.
In case of stateful session bean, the bean may be kept in cache till either the
session times out, in which case the bean is removed or when there is a requirement
for memory in which case the data is cached and the bean is sent to free pool.

49: What is the difference between Message Driven Beans and Stateless Session
beans?
A: In several ways, the dynamic creation and allocation of message-driven bean
instances mimics the behavior of stateless session EJB instances, which exist only
for the duration of a particular method call. However, message-driven beans are
different from stateless session EJBs (and other types of EJBs) in several
significant ways:
Message-driven beans process multiple JMS messages asynchronously, rather than
processing a serialized sequence of method calls.
Message-driven beans have no home or remote interface, and therefore cannot be
directly accessed by internal or external clients. Clients interact with
message-driven beans only indirectly, by sending a message to a JMS Queue or Topic.
Note: Only the container directly interacts with a message-driven bean by creating
bean instances and passing JMS messages to those instances as necessary.
The Container maintains the entire lifecycle of a message-driven bean; instances
cannot be created or removed as a result of client requests or other API calls.

50: How can I call one EJB from inside of another EJB?
A: EJBs can be clients of other EJBs. It just works. Use JNDI to locate the
Home Interface of the other bean, then acquire an instance reference, and so forth.