EJB design: What is the need of Home and Remote Interfaces?

  1. Hi all,

    What is the need of Home and Remote Interfaces?
    Why can't we use directly(invoke/access) Bean instead of calling trhu the Remote and Home?
    Let me know in detail.

    B S Reddy
  2. The home interface is essentially a factory, which creates EJB references for you from various constructor-like methods. You can't "new" an EJB directly because a) EJBs are under the control of the container, and b) an EJB may be remote e.g. running in another JVM.

    The remote interface is there, again, because you're dealing with an object managed by the container, and also because the object may be remote, in which case your object invocations are going over the network.

    In more practical terms, the real EJB is hidden by the interfaces, and container-specific generated code (exactly like RMI stubs 'n' skeletons) may be intervening in the middle. When you run an EJB compiler over an EJB, its this stub and skeleton like code that's getting generated which glues the home and remote interfaces to the real EJB. Whether or not you go through any of this code is up to the container. Some containers (like Weblogic) will optimize out network-like access if your client and EJB are running in the same JVM, but the code is still there in case you deploy your client on one app server and your EJB on another one for load balancing/failover reasons.

    In short - an EJB may be remote, and may not be directly accessible as an object to your client code. The home/remote interfaces are a standard mechanism for hiding this fact and making an EJB look like it's always local (sort of).

  3. Mike,
     Thanks for Your Clear Reply.
    B S Reddy