Q: So, I’m still not clear if the bean MUST always know if the client is Remote or local.
A: It’s not that the bean must, but rather that the bean might have to know. If it matters that the bean is working on a the caller’s object, (via a copy of the caller’s reference) as opposed to a copy of the caller’s object, your bean code might have to change. And that goes for return values too. If it matters that the calling method gets back a copy of a reference vs. a copy of an object, the bean code might have to change.
Q: But I thought that choosing to deploy a bean with local vs. Remote client views was just a matter of switching a switch at deploy time.
A: NO! NO! NO! Let’s imagine that you did write two sets of interfaces, one for a local client view and one for a Remote client view. It is true that at deployment you could decide which of the two views you wanted to expose (or both). But that works only if the bean code doesn’t care where the client is. A bean method with no arguments or return values might be safe regardless of how the client is accessing it.
One solution might be to write the bean code assuming the bean is always getting a copy, and then if the client is local, have ...
With Safari, you learn the way you learn best. Get unlimited access to videos, live online training,
learning paths, books, interactive tutorials, and more.