EJB design: Home/Remote/EJB

  1. Home/Remote/EJB (3 messages)

    A client can access EJB thru EJBObject. The EJBObject must know every business method associated w/ EJB thru remote interface. Again, client can’t instantiate an EJBObject directly because EJBObjects could exist on a different machine than the client resides. The client acquires reference to an EJBObject thru HomeObject. The HomeObject implements the home interface, which defines for creating , destroying, and finding EJB objects.

    Above is my abstraction from the ED ROMAN book. Kindly answer my following questions.
    1. Is that true that EJB, EJBObject and HomeObject may reside in different container ?.
    My comments: HomeObject(EJBObject factory) can locate the EJBObject since it may reside in different m/c. How does the client locate HomeObject in case it resides in other m/c ?
    2. I really don’t understand the requirement of HomeObject since all the business methods are available
    EJBObject(which implements remote interface). Utlimately we need instance of EJB; why we can’t achieve it from the EJBObject itself instead of going thru HomeObject ?

    Kindly help me out to understand. Thanks

    Threaded Messages (3)

  2. Home/Remote/EJB[ Go to top ]

    This won't be an elaborate answer to your question. But this is what I have understood.

    One of the advantages using EJB's are that the EJB server will handle the Transaction, Threading etc, ther by reducing the risk in a Programmer.

    But for doing this for the outside world, the container is not providing the facility of creating an instance of the Bean class directly.

    So what the container does is They will provide Home and Object Interface to the outside world.

    Home interface is used to get a handle to the Remote Interface. To get a Home Interface , we make use of the JNDI look up.

    Once you get the Home Interface , then you have to get a handle to the Remote interface. If the EJB container gives you the Bean class directly rather than the Remote Interface then user can disturb the Transaction and Threading mechanism of the EJB. So to prevent the user from collapsing the server, it gives you the remote Interface.

    Moreover this feature is very good in the sense that you can change the implementation, without disturbing the outside world. Hope I had answered to your query to some extend.
    If you find out any thing more pls inform, me suresh_vasudev at hotmail dot com

  3. Home/Remote/EJB[ Go to top ]


    1. Home/Remote/EJB must be in the same container! The container will generate actual implementations for the Home/Remote interface and delegate those invocations of remote interface methods to EJB methods. They must reside in the same container, otherwise, the container will have trouble in code generation.

    2. why cannot we achieve from EJBObject itself rather than going through HomeObject? Nope. a simple example would be the enity bean: find an entity bean which satisfies some conditions.

    Theoretically, another specification without EJBHome could be defined. But I think that specification will be not be
    graceful as the current J2EE specification which intergrates SUN and a lot of companies's proposal.


  4. Home/Remote/EJB[ Go to top ]

    thank you for Suresh and Fengliang.