This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
By the way, I read a good article on AOP recently and I think it helped me to better understand this chapter. I think a lot of the motivations are similar (though handled differently) for AOP and the EJBObject. Makes me wonder if the functionality of the EJBObject might someday become replaced by AOP.
Maybe there are other parts of EJB similar to the AOP concept that I missed. Here's the article. I recommend reading all of Part 1 and at least the first two pages of Part 2.
Joined: Oct 29, 2001
Page 96 - Sharpen Your Pencil
"... Number the arrows in the order in which they occur..."
1. Client --> Home Stub: Client tells the stub that he wants to create the bean. 2. n/a, done for us 3. Home Object --> EJB Object: Ejb object is created (by the Home?) 4. Home Object --> Services: Services kick in (whatever that means) 5. Services --> Bean: Bean is created (by the services?) 6. Home --> Home Stub: EJB object is returned (to the home stub?) 7. Home Stub --> Client: EJB OBject is returned to the client. 8. Client --> Component Stub: Client calls business method(s) on component stub. 9. Component Stub --> EJB Object: Stub calls business method(s) on the EJB Object. 10. EJB Object --> Services: ?? 11. Services --> Bean: ??
Joined: Oct 29, 2001
Page 104 - Sharpen Your Pencil
#6 on the True/False is True. Can anyone explain why though? [ January 31, 2005: Message edited by: gayle craig ]
Gayle, your page 96 exercise I have the 3 and 4 swapped. The services "kick in" before the EJBObject is created. In fact, the diagrams on 100 and 101 imply that the services are responsible for creating the EJBObject.
(Note the confirmed errata below)  steps 5 and 6; The order of creation is wrong (and inconsistent with the order as present later in the book): The EJBObject is created BEFORE the bean is created. Steps 5 and 6 are really 3 steps: Now the services kick in and 5: the EJBObject is created 6: the bean is created 6b: the EJBObject stub is returned to the client.
I did not initially agree with #6 on page 104 either: There must be one stateless session bean per client, for as long as the client is in the middle of a business method invocation on the bean. (T)
The best I can figure is that the statement intended to say, "If a client needs a stateless session bean and all of the beans in the pool are busy, the client does not need to wait her turn because a new bean is created for her." or "If there are n clients concurrently asking for stateless bean work, then n beans are put to work." [ February 02, 2005: Message edited by: Marc Peabody ]
However, could someone help explain tonight the idea of sending another remote object in the method call like they talk about on page 74-75.
Joined: Oct 06, 2004
As I'm looking at this, I would have to disagree with it also. I thought this is up to the vendor implementation. We can't concurrently call the same method, but whether or not we have to wait, or have another bean created ... I thought ... was up to the vendor.
My take: A scenario to explain the SharpenYourPencil #6 (from page 104) question-
Imagine we have a Stateless session bean called "ClientTotal" bean, which finds out (somehow) the number of clients present in the specified network (the network will be supplied to the bean in the form of an argument to the bean methods, either a class 3 IP or the domain name). All this querying and calculating takes some amount of time. There is a memory shortage on the server (assumption), and the container is able to create and maintain only one object of the ClientTotal bean in the bean pool.
Lets imagine Client 1 calls the ClientTotal bean and asks it to calculate the number of clients in the Java-Developer domain. While the bean is making the queries, another client, Client 2, calls the bean and asks it to calculate the number of clients in the Java-Tester domain. Since, there is only one bean in the pool, and since its in the middle of a method (a business method), Client 2 will have to wait until the bean finishes its task with Client 1. Once the bean finishes with the calculations and services the Client 1, it can go back and service Client 2.
So, there will be a stateless session bean existing per client, for the time period that the business method takes to complete.
Please let me know if I am stating something wrong here.
P.S -> Great work, Marc. Though I am a little behind you guys (the Sark study group), I promise to catch up in the coming days So, if you find the answers or questions, coming in a little late, please adjust.