Concepts
One goal of the original Enterprise JavaBeans (EJB) specification
was to expand upon Java's write-once, run-anywhere philosophy: developers
could build applications from server-side components and focus on business
logic and other features without worrying about where the components would
be deployed. To achieve this, early EJB specifications defined a robust yet
fairly complex infrastructure—including remote interfaces, the Java Remote
Method Invocation (RMI) protocol, and RMI over IIOP (Internet Inter-ORB Protocol)—that
enables distributed components to find each other and communicate across the
Internet or an intranet.
As developers worked with EJBs, two things became apparent.
First, flexibility came at the expense of performance. Routing method calls
and responses through remote interfaces and RMI gobbled up processing resources,
and applications simply ran slower. Second, in many cases, EJBs were deployed
to the same container—they didn't need the remote communication infrastructure
but had to use it anyway.
Responding to this kind of feedback, the EJB 2.0 expert group
introduced support for local interfaces. This mechanism, defined in the
EJB 2.0 specification, enables components in the same container to bypass RMI
and call each other's methods directly. In general, direct local method calls
are faster than remote method calls. The downside is a loss of flexibility:
because bean and client must run in the same container, the location of the
bean is not transparent to the client (as it is with remote interfaces).
The Design section describes how
OTN developers decided when and how to use local interfaces in the FBS 10g. Coding
details are discussed in the Implementation section.
| 
Bookmark
