I just had one thing to add and so I've deleted the rest. I agree with all of Gregg's comments...as usual :-).
...deleted... >> 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. Sean
