Wade, In order to understand the deeper and sometimes counter-"intuitive" (which I often find to be negative conditioning) reasons why things in Jini are the way they are, I found it very helpful to go straight to the sources, researching back all the way to 1998. I know this is not a popular approach anymore, but in this case it is helpful and saves from having to poke around in idea-space "guessing" for motivations and reasons which only lead to stray conclusions.
A particularly helpful resource for this is an interview series at Atima called "A Conversation with Ken Arnold" which can be found on http://www.artima.com/intv/. Part 4 (Sway with JavaSpaces) has an in-depth explanation and should help understand the reasons for this approach. You are not *supposed* to have that additional logic on what you call "transfer objects"; the core issue does not revolve around behaviour, but *identity* - one of the three defining aspects of objects as defined by OO (state, behaviour, identity). For distribution in scenarios with partial failure (not assuming a closed-world / single-system image [1]), you *must* let go of the identity. Once you understand that, you will realize that the behavioural aspect becomes a potential problem instead of a desirable property, and that is why it is missing from Entries. Different may not imply better, but better always mandates different. :) Holger [1] I wanted to add a looong paragraph about "transparent" identity-perserving clustering ala Terracotta but that would go way off-topic.
