rahul lahiri wrote:Hi,
I am new to Ejb.I was reading somewhere that every ejb must have a remote and a local interface and only those methods which are exposed in the remote interface can be accessed.Now,if a programmer wants to access the ejb from a different machine,he/she must have a copy of the remote interface(at least thats what seems to me).Is it correct?
EJB enables development and deployment of distributed components. A distributed
component, also commonly referred to as distributed object or remote
object, is callable from a remote system. That is, not only can it be called from
an in-process client but also from an out-of-process client that might be located
on a different system on the network.
A remote invocation of a method on a distributed object follows a common
process that is similar across almost all distributed computing technologies.
The main steps of this remote method invocation process are:
1. The client calls a stub, which is a client-side proxy object. This stub is
responsible for masking network communications from the client. The
stub knows how to call over the network using sockets and also how to
massage parameters from their Java representations to the corresponding
network representations.
2. The stub calls over the network to a skeleton, which is a server-side
proxy object. The skeleton masks network communication from the distributed
object. The skeleton understands how to receive calls on a
socket as well as how to massage parameters from their network representations
to their Java representations.
3. The skeleton delegates the call to the appropriate implementation
object. This object serves the call and does its work, and returns control
to the skeleton, which returns it to the stub, which finally returns control
to the client.
A key point here is that both the stub and the server-side implementation
object implement the same interface (called the remote interface). This means
the stub clones the distributed object’s method signatures. Aclient who calls a
method on the stub thinks he is calling the distributed object directly; in reality,
the client is calling an empty stub that knows how to go over the network. This
is called distribution transparency. In fact, the distributed object is an abstraction
that is created by the cooperation between the stub, skeleton, and implementation
objects. No single entity in this scenario is the distributed object.
You can develop and deploy distributed objects using many other technologies,
including CORBA (OMG), Distributed Component Object Model or
DCOM (; Microsoft), and Java RMI-IIOP (Sun).
(Quote from
Mastering Enterprise JavaBeans 3.0, Sriganesh, Brose and Silverman, Wiley Publishing Inc., 2006)
