Java Reference
In-Depth Information
Local and Remote Instances
EJBs can be accessed via local or remote interfaces. In the canonical Java EE deployment,
EJBs are accessed through servlets, and the servlet has the choice of using the local or re-
mote interface to access the EJB. If the EJB is on another system, then of course the remote
interface must be used, but if the EJB is colocated with the servlet (which is the more com-
mon deployment topology), the servlet should always use a local interface to access the EJB.
That may seem obvious, since a remote interface implies a network call. But that isn't the
reason—when the servlet and remote EJB are deployed in the same application server, most
servers are smart enough to bypass the network call and just invoke the EJB method through
normal method calls.
The reason to prefer local interfaces is the way in which the two interfaces handle their argu-
ments. Arguments that are passed to (or returned from) a local EJB follow normal Java se-
mantics: primitives are passed by value and objects are passed by reference. (Or, strictly
speaking, the object handle is still passed by value, but references through the object make it
appear that the object is passed by reference.)
Arguments that are passed to (or returned from) a remote EJB must always be passed by
value. That is the only possible semantic over a network: the sender serializes the object and
transmits the byte stream, while the receiver deserializes the byte stream to reconstitute the
object. Even when the server optimizes the local call by avoiding the network, it is not al-
lowed to bypass the serialization/deserialization step. (Most servers will realize when the ob-
ject in question is immutable—a String , or a primitive value—and skip the serialization of
those objects. But that isn't possible in the general case.) No matter how well written the
server is, using a remote EJB interface within the server will always be slower than using a
local one.
Java EE offers other deployment scenarios. For example, the servlet and EJBs can be de-
ployed in different tiers, and remote EJBs can be accessed from an ordinary application via
their remote interface. There are often business or functional reasons that dictate the topo-
logy; for example, if the EJBs access corporate databases, you may want to run them on ma-
chines that are behind a separate firewall from the servlet container. Those reasons trump
performance considerations. But from the strict perspective of performance, colocating EJBs
with whatever is accessing them and using local interfaces will always be faster than using a
remote protocol.
Speaking of protocols, all remote EJBs must support the IIOP (CORBA) protocol. That is
great for interoperability, particular with other programs that are not written in Java. Java EE
server vendors are also allowed to use any other protocol, including proprietary ones, for re-
Search WWH ::




Custom Search