When the container starts up, it normally puts a fixed number of equivalent method-ready beans in the bean pool. Now, when the client invokes a method on the EJB Object, it picks up a bean from the pool to service the request. What escapes me is, how does the implementation of the methods that was written for the EJB Object (in the implementation Bean Class) is stuffed into this plain Stateless bean picked up on the fly to service the incoming request. Can someone please explain me what is happening here?
Regards, Rakesh.R
Jimmy Clark
Ranch Hand
Joined: Apr 16, 2008
Posts: 2187
posted
0
... method-ready beans in the bean pool. Now, when the client invokes a method on the EJB Object, it picks up a bean from the pool to service the request.
What escapes me is, how does the implementation of the methods that was written for the EJB Object (in the implementation Bean Class) is stuffed into this plain Stateless bean picked up on the fly to service the incoming request.
An EJB container creates many classes for an EJB that the application programmer does not create. The code that implements the interfaces of the bean does not contain the code of the implementation class of the bean. The code of the interface classes contain the logic to communicate with the container and execute the bean implementation object that was extracted from the pool. The implementation object never leaves the container.
Business logic is executed by the implementation object inside the EJB container.
Business logic is NOT executed by the interface object which communicates with the client object. [ December 16, 2008: Message edited by: James Clark ]
0
