Chapter 3 - HF Sark study group

[Marc Peabody]

For discussion of Head First EJB's Chapter 3.

Other Chapter discussions:
1 2 3 4 5
[ February 18, 2005: Message edited by: Marc Peabody ]

[Marc Peabody]

Question about the isIdentical() method of EJBObject:

Could the same functionality be accomplished by getting the Handle from each EJB object and using the equals() method?

update -
I see know that the book brings up the same topic but considers the equals() method of the stub rather than the handle's equals() method. (141-143)
The answer the book gives is that we don't know how the vendor implements the equals() method.

I figured the equals method could handle the RMI junk internally but that really isn't the intent of the method I guess.
[ February 07, 2005: Message edited by: Marc Peabody ]

[Marc Peabody]

To reemphasize the chapter's warnings...

KNOW PAGES 129 AND 137 LIKE THE BACK OF YOUR HAND!

[gayle craig]

Why does the Home interface that we write (the one that implements EJBHome) have to define a no-arg create() method? I mean, why didn't they just put that in EJBHome so that our Home doesn't have to define the same exact thing every time? (similar to the way EJBObject defines a no-arg remove() method for us).

[gayle craig]

Page 119 - Sharpen Your Pencil

InitialContext - javax.naming
AdviceHome - headfirst
PortableRemoteObject - javax.rmi
RemoteException - java.rmi
Advice - headfirst
CreateException - javax.ejb

Are we seriously supposed to just know what's in java.rmi vs. javax.rmi?

Why are there two different packages so closely named anyway? (jerks)

Does anyone have any ideas on how to keep straight stuff in the java vs. javax RMI packages?

[gayle craig]

Page 132 - Sharpen your Pencil

Are these right?

1. True (b/c there's only a no-arg create)
2. True (missing import of CreateException)
3. False
4. True
5. True
6. False
7. True

[gayle craig]

Q: Why do AdvideHomeImpl (page 128) and AdviceImpl (page 136) have remove methods with different signatures? What do they each do?

A:
1) EJBObject.remove()
- For ENTITY beans: Delete the entity from persistent store (is this the same as what #3 does essentially?)
- For SESSION beans: Tell the sessioin bean that you're done with it. (is this the same as whast #2 does essentially?)

2) EJBHome.remove(Handle h)
- Remove a bean that came from this home (the one represented by Handle)

3) EJBHome.remove(Object key)
- For ENTITY beans only: This method removes a bean that came from this home.

[gayle craig]

Originally posted by Marc Peabody:
[QB]Question about the isIdentical() method of EJBObject:

I was initially confused about this isIdentical() method too. My questions (which I later answered) were as follows:

Q: Does EJBObject.isIdentical() only compare the object references? Or the contents of the objects?
A: Compares the object itself for if they are "meaningfully equivalent" (defined further by the Q & A's below)

Q: This should never be true on session beans then, right?
A: STATEFUL: this will never be true. STATELESS: will be true if reference came from the same Home.

Q: Who cares if this returns true on entity beans? When would that even be useful information?
A: True on entity beans if stubs refer to entities with the same primary key.

[Marc Peabody]

132 reply:

I think 1 is false because the rule is that a Stateless cannot have an arged create() method. The second bullet (star) of page 125 says, "Stateful session beans can have multiple, overloaded create() methods, and do NOT need to have a no-arg create()." This implies that it is still ok for a stateful session bean to have only the no-arg create.

[gayle craig]

Brain Power - page 161

What has to change inside the bean class?
....
Can you think of <i>anything</i> that the bean might want to treat differently if it knew the client were local instead of Remote?

My answer: Local beans aren't specifically limited by HAVING to have parameters that are "shippable" (i.e. primitives, Serializable, Collections of primitives or Serializable, or Remote) right? I.e. you could have non-shippable parameters in a Local bean? Or is that still expressly forbidden by the spec?

[Marc Peabody]

Originally posted by gayle craig:
Why does the Home interface that we write (the one that implements EJBHome) have to define a no-arg create() method? I mean, why didn't they just put that in EJBHome so that our Home doesn't have to define the same exact thing every time? (similar to the way EJBObject defines a no-arg remove() method for us).

If it did, we could not override it and add our own application exceptions to the throws clause. Also, we would be forced to cast and narrow because it would return Object (although doing so would be consistent with everything else.

There are probably other reasons for it as well.

[gayle craig]

Coffee Cram - p 170-171

Question 3: Given a remote client "R" that has valid references to session beans "A" and "B", and given that A is a local client to B, which statements are true?

I wasn't sure about answers A and B. I thought either both would be true, or both would be false. The explanation for B says "You can't give a remote client a local reference, A sees B through a local reference."

How, then, can R pass his reference for A to B? Isn't the reference that R has for A still "remote reference" which would mean nothing to B?

[Joe OBrien]

I agree with Marc on the first one for page 132.

The rule states that it CAN have more and does not HAVE to have a no-arg.

Just wanted to make it look like I was trying as well :-)

[Joe OBrien]

Originally posted by Marc Peabody:


If it did, we could not override it and add our own application exceptions to the throws clause. Also, we would be forced to cast and narrow because it would return Object (although doing so would be consistent with everything else.

There are probably other reasons for it as well.

------------------------------------------------------

I agree with Marc on the return type of this, but I think the answer might be even simpler. We use the same interface (EJBHome)for stateful and statless session beans. If it defined no-arg create, we would have to implement it for the stateful session.

Although this by no means I agree with this implementation ...

[gayle craig]

The examples they use about serializing, save to disk, move to different computer, deserialize and continue shopping, that seems unrealistic
- How would you get into the code to get the object and serialize it if you didn't write the code?
- And if you did write the code, then you're probably not a "user"?
- When in real-life apps would you need to do this really?

[Marc Peabody]

Discussion on isIdentical

[Subhash Bhushan C]

An analogy of EJBObject's "isIdentical()" method works:

Stateless Session Beans:- The workers in a supermarket
Stateful Session Beans:- The Shopping Cart
Entity Beans:- Items in a supermarket

It does not matter you which worker in the supermarket, serves your request, as long he does service you and he belongs to one of the staff of the supermarket(belong to a single home). So, if you call isIdentical() on the workers, they will return true as long as they work in the same supermarket.

The shopping cart is unique to each client, based on his needs and item list. Two different people may never want to buy the same exact things from the supermarket. So, calling isIdentical() on the shopping carts of two people, will always return false, since they both are never guaranteed to buy the same exact things in the same order.

The items in the supermarket are branded uniquely with a computer code. The repository is maintained by scanning the computer code of each of the product into the system. If a shopper buys an item, then the same is recorded and removed from the repository. So, if you call isIdentical() on the items, to return true, you should be referring to the same exact item in the supermarket.

[Subhash Bhushan C]

The examples they use about serializing, save to disk, move to different computer, deserialize and continue shopping, that seems unrealistic
- How would you get into the code to get the object and serialize it if you didn't write the code?
- And if you did write the code, then you're probably not a "user"?
- When in real-life apps would you need to do this really?

Imagine you own an online grocery store on the internet. And you host the whole array of products that are available in any general supermarket, from a matchbox to a lawn-mower. Users who use your store, usually find it easy and profitable (of course, you do give discounts on major buys, dont you? ) to order all the provisions required for a whole month, at once.

And the list of provisions required for a whole month, is usually very large and long. So, you have been requested by a number of users to implement the "remember my shopping cart contents" feature, so that they can always come back later to an unfinished shopping cart and complete it. They are willing to install a small application on their PCs to help you out.

So, you build a small client, which gets the handle of the EJBObject from the server, once the shopping starts, and keeps it until the shopping ends.

If the user has to go out on an errand, or if the power goes down in his area (and he has only a 20 min backup UPS), he can always return back, runs the client that you have supplied (you can make that auto-runnable too, when he reconnects to your website) and continues his shopping.

Does this satisfy you?

[Subhash Bhushan C]

Coffee Cram - p 170-171

Question 3: Given a remote client "R" that has valid references to session beans "A" and "B", and given that A is a local client to B, which statements are true?

I wasn't sure about answers A and B. I thought either both would be true, or both would be false. The explanation for B says "You can't give a remote client a local reference, A sees B through a local reference."

How, then, can R pass his reference for A to B? Isn't the reference that R has for A still "remote reference" which would mean nothing to B?

For R, both beans A and B are remote EJB Objects. So, he has some way of getting a reference to the EJB Object, to save for future use, or to pass on another object. By way of the getHandle() method. So, he does not face any difficulty in getting the EJB Object of the bean A and passing the same through a method to bean B. The bean B can then use the handle to establish the connection to bean A.

But A, who sees bean B as a local EJB Object, does not have any way of getting a reference to the EJB Object to pass to another object. Because, the getHandle() method does not have meaning when we are considering EJBLocalHome and EJBLocalObject.

Whats important here is to understand that bean B is exposing his functionality through both remote and local views.
[ February 16, 2005: Message edited by: Agni Vartula ]

[Marc Peabody]

Originally posted by Agni Vartula:
[/b]
...
Does this satisfy you?

I think Gayle was referring to page 139's comment, "Ask the bean for a handle, serialize it, email it to yourself, then deserialize it on your work machine."

I'll have to admit that my gag reflexes kicked in when I read that. The statement is far from practical.

[Subhash Bhushan C]

Yep, I thought so too. I tried to imagine how it could be done. I thought maybe we have a client application that has the option of serializing the objects it has.. etc etc. But I found that explanation to be unsatisfactory. What I meant by asking if Gayle was satisfied, was to know whether my example sounded practical enough.

"Does this satisfy you?" --> "Is my example good enough".

To tell the truth, I am not completely satisfied with this example too...
[ February 16, 2005: Message edited by: Agni Vartula ]