1

I would like to know what is going on "under the hood" if I use remote interfaces in JavaEE. In the project I use a stateless enterprise bean that implements a remote interface. And I can call methods in this remote interface from a client (it all runs on the same glassfish server but it should work from a different machine as well).

The remote interface is within a Java Class Library, the enterprise bean and the client both include this library, but only in the bean it gets implemented.

I am quite new to JavaEE and glassfish. I know there is a container that manages the beans and a lot of stuff which makes everything super easy, but I don´t know yet what happens behind the scenes. Could you give me a brief description of what happens on a remote call? I think it has to do something with JNDI. And if I would start my client on a completely different machine, how would JNDI find my bean on the other machine?? (Since I use netbeans with glassfish I didn´t have to configure anything in glassfish)

Thanks!

EDIT: I use dependency injection, so everything I need to access the bean is the annotation @EJB (this works because of the class library)

Puckl
  • 1,525
  • 2
  • 13
  • 17

1 Answers1

3

RMI is the standard for distributed object computing in Java. An EJB with a remote interface is an RMI object. RMI enables an application to obtain references to other objects located elsewhere in the network, and to invoke method on that object as though it where co-located with the client on the same JVM locally in client's virtual machine. On the server side bytecode (stub) is generated for remote classes on the fly and these dynamically generated classes are bound to JNDI. On the client side a proxy is also generated for the remote interfaces. Calls to the proxies are routed to the stub. Naming service resolution still need to be configured on your remote client

evince
  • 31
  • 1