Head First EJB

What has to change inside the bean class?

We’ve seen how the interfaces change, and how the client code has to change, when you go from a Remote to local client view. But what about the bean class itself? What do you think? Does the bean code need to change, if you’re going to deploy it with a local client view instead of a Remote client view? What if you plan to deploy it with both a local and Remote client view?

For now, let’s assume that the only method that matters is the bean’s business method. Here’s how it looks in the original bean class:

public String getAdvice() {
    System.out.println("in get advice");
    int random = (int) (Math.random() * adviceStrings.length);
    return adviceStrings[random];
}

Do you see anything in that method that looks specific to a Remote client view? Would you need to do anything different with a local client?

No, don’t think so.

Anything that works as a return type or argument for a Remote method is guaranteed to work for a local method as well, so we’re OK there. (Kind of a no-brainer when the return type is String, though.) OK, there is one exception—remember, according to Bean law you must not return a bean’s Remote interface from a local interface method.

So it looks like (at least with this bean) we should never have to know or care. We should be able to deploy the bean as written, and the bean should be kept unaware of whether its clients are Remote or local.

Sounds good, doesn’t it? Simple, clean, object-oriented.

But think about it some more. Imagine ...