Java Reference
In-Depth Information
Business Interface
Problem
The remote interface of a session facade defines the business methods that are accessible
from the client. The bean class, on the other hand, provides implementation for the busi-
ness methods. However, there is no direct relationship between the two. This results in
annoying runtime or deploy-time errors such as missing methods, inconsistent method
names, parameter type and count, and exceptions. Since these errors are generally
detected only at runtime, you may end up losing a significant amount of effort in the
debug-fix-deploy-test cycle. Thus, this decoupling of remote interface and bean imple-
mentation makes it impossible to trap errors early, at compile time.
The easiest solution to this problem is to allow the bean class to implement the
remote or local interface. However, this is not allowed by the EJB specification. Although
not very common, sometimes a session bean method may need to pass its reference to
the called method. This is common in Java programming, where you pass the
this
refer-
ence. But things are different in EJB. The EJB clients should always use the remote
interface to invoke business methods. This helps the EJB container intercept all business
method invocation and register these methods for applying system services such as secu-
rity and transaction. Now, since the bean class does not implement the remote interface,
you are forced get the associated
EJBObject
/
EJBLocalObject
from the
SessionContext
and
pass it to the called method. If the bean class had implemented the remote or local inter-
face, then there is a chance of inadvertently passing this reference from the bean class to
the calling method. In this case, however, the behavior of the EJB container is not guaran-
teed, and you may get unexpected results.
There are other problems for the bean class implementing the remote and local
interfaces.
The
EJBObject
and
EJBLocalObject
interfaces define two different sets of methods. The
container is supposed to provide implementations for these methods during deploy-
ment. The container-implemented methods are critical to the overall working of the EJBs.
These methods take care of low-level concerns such as networking, serialization of
parameters and passed values, and coordination with the container for system services.
They also proxy business method calls to the actual bean implementation. But in case
the bean class implements these methods, it has to provide implementation for these
classes, which may ultimately result in an unusable EJB. To compile the bean, the imple-
mentation needs to implement the methods defined in these interfaces. This in turn
clutters the bean implementation with unnecessary code. Moreover, if the remote inter-
face is implemented by the bean implementation, the clients will have access to the
actual bean just by casting the remote interface, which defeats the core goals of the EJB,
which are location transparency and distributed business objects.
