I'm new to EJB's and J2EE and have a question that I can't quite deduce.
In a design I'm looking at, we have an engine that uses session beans to instantiate custom objects that conform to an interface. So for instance, the session beans in the engine will at runtime learn the class information for these custom objects and create them as needed (or do a JNDI lookup). These objects all implement a common interface so the engine knows how to talk to them.
These custom objects will live in the same appserver as the engine and there is no decision around whether or not we want to require these custom objects to be EJB's themselves.
What I'm having trouble with is trying to understand the advantages or disadvantages of having these custom objects as simply java classes or EJB's. If they are regular java objects, then the engine will create them and I'm assuming they will inherit all the advantages of living within the appserver along with the engine's session beans. If they are EJB's themselves and the session bean invokes them, am I only making the engine less efficient, or can these custom EJB objects do more than if I had implemented them as regular java classes? There will be no situation where the custom objects will need to live on another app server.
These custom objects have no use outside the engine, so no other client would ever access them other than the engine.
So what all this lengthy question deduces to: Why would I want to call an EJB (EJB A) from another EJB (EJB B) as opposed to just making EJB A a regular java class?
thanks,
Neil
In a design I'm looking at, we have an engine that uses session beans to instantiate custom objects that conform to an interface. So for instance, the session beans in the engine will at runtime learn the class information for these custom objects and create them as needed (or do a JNDI lookup). These objects all implement a common interface so the engine knows how to talk to them.
These custom objects will live in the same appserver as the engine and there is no decision around whether or not we want to require these custom objects to be EJB's themselves.
What I'm having trouble with is trying to understand the advantages or disadvantages of having these custom objects as simply java classes or EJB's. If they are regular java objects, then the engine will create them and I'm assuming they will inherit all the advantages of living within the appserver along with the engine's session beans. If they are EJB's themselves and the session bean invokes them, am I only making the engine less efficient, or can these custom EJB objects do more than if I had implemented them as regular java classes? There will be no situation where the custom objects will need to live on another app server.
These custom objects have no use outside the engine, so no other client would ever access them other than the engine.
So what all this lengthy question deduces to: Why would I want to call an EJB (EJB A) from another EJB (EJB B) as opposed to just making EJB A a regular java class?
thanks,
Neil