What is purpose of homeObject?

[Veena Pointi]

I got following doubt while reading 92-95 pages of HFEJB.

Why EJBHomeObjects are registered with JNDI? Why not EJBRemoteObjects are not registered directly with ? What is the purpose of having EJBHome object in-between client and EJBRemoteObject?

When client makes requests for bean, using lookUp it gets back EJBHomeObject stub.It uses EJBHomeObject inturn to get reference to EJBRemoteObject through it's EJBRemoteObject stub.

Security ,i.e authorization is taken care by EJBObject,all other services like transaction,persistence is taken care by services provided by container.Then why do we have EJBHomeObject in-between? Why EJBRemoteObjects are not registered directly with JNDI?

Thanks
Veena

[Jesus Angeles]

i asked myself the same question while reading the book. but understood as i proceeded with the book.

you will get it as you read on.

you need the homeObject. i might confuse you if i attempt to explain what you havent read yet. so you can read on. you will see why we need the homeObject.

[Peer Reynders]

AFAUI EJBHome is an Abstract Factory.

"new" and the class constructors are great for creating simple, unconnected objects but once you start creating interrelated "objects" things get more complicated and you tend to create "factories" that know how to create things that are actually composites or aggregation of objects.

Look at a JDBC connection - you don't create it with a "new", you get it from the DriverManager. The DriverManager is a Factory. Under the hood the connection object the DriverManager creates is interconnected with lots of other details that you don't want to deal with - but DriverManager (the Factory) knows what needs to be done.

Beans cannot exist in a vacuum - they need the EJB container. And the client doesn't actually talk to the bean - it talks to an object that implements the EJBObject interface and your component interface. So when a client requests access to a bean there is quite a lot to do.

Furthermore the client doesn�t initially have access to the Factory that can give it "access to the bean". It has to get it through JNDI � so there has to be one single facility that all clients can use to access beans of a certain type � while there will be many bean instances of that type.

So EJBHome is an Abstract Factory.
You create a home interface the extends EJBHome.
Ultimately the container implements the class that becomes the Factory that implements your home interface which manages/orchestrates the bean/EJBObject lifecycle for you.

From a class design perspective it makes sense to separate bean lifecycle management from the bean and its EJBObject:

There is only one Factory instance (accessible via JNDI) but there will be many "EJBObjects".

A class should do one single job and it should do that well. Being responsible for orchestration of the creation and destruction of all those beans/EJBObjects for one bean type is big enough for one class (EJBHome). Implementing the component interface with all the container intercepts is another one (EJBObject), and finally there is the business logic (your Bean).

[ August 19, 2005: Message edited by: Peer Reynders ]