river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Landis" <sean.lan...@gmail.com>
Subject Re: Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.
Date Sun, 31 Aug 2008 16:10:26 GMT
I just had one thing to add and so I've deleted the rest. I agree with
all of Gregg's comments...as usual :-).


>> Something bothering me about JavaSpaces entries is they force public
>> fields/variables. To me they should operate off the same assumptions
>> JavaBeans and serialization operate. EJBs work this way as well. Truly
>> those things should be compatible thus true encapsulation can
>> take place. I haven't figured out why entries differ from the other
>> specifications.

Gregg gave a fine explanation of why this is so. I would turn that
around and ask, "Why do you care if a transfer object is transparent?"

At first blush, it might seem like a nice idea to use business objects
as entries in a JavaSpace but I would argue that is a bad idea. Just
as it is a bad idea to pass BOs across web service boundaries, or
other distribution technology boundaries.

If you do so, you quickly increase fragility in the system because
end-points must agree on the model and this is burdensome from many
perspectives. I'll give one example but there are many others. Our
Product Object, in it's complete form (from a DB field perspective)
has over 150 fields. This is too big to pass across the wire.
Furthermore, most uses of this object only care about a small subset
of this object. Further furthermore, we don't want certain of that
information to leak out to clients.

We use transfer objects to resolve this problem. Transfer objects are
in the class of objects that exist merely for their state and contain
no interesting behavior. Here, encapsulation losses its value and
merely is unnecessary overhead.

So I don't think the transparency of JavaSpace entries is a problem
from an OO design perspective.


View raw message