Bag Of Jumping Beans
Bag Of Jumping BeansBagOfJumpingBeans is a pattern implemented by Jumping Beans(R) ( see http://www.JumpingBeans.com ) and was described in DesignPatternsForDistributedObjects. This page is presently a discussion page, and will become more formalized over time.
Intent
The real point of the pattern is that massive efficiency gains can be made by transporting a whole object. Not all objects in a distributed system need to be distributed objects. Use serialization to pass ValueObject(s), but give access to their container by reference.
Description
It's easy to get carried away with distributed objects. But some objects just don't need to be distributed.
A Jumping Bean is such an object. It needs to be centrally administered in a distributed system, but doesn't need to provide a distributed interface.
A bag of Jumping Beans is a proper distributed object which centrally manages a set of these Jumping Beans.
Related patterns:
Is a Jumping Bean the same thing as a ValueObject? -- RalphJohnson
I don't think so, but it looks related to simple PassObjectByValue? to me. -- JeffGrigg
Sounds like the same thing as a DataTransferObject.
It's a ValueObject once you've received it, but since it's possible for the value others will get in the future to be different, it's not really in the same spirit as ValueObject.
The ValueObject examples are of very small objects. I was thinking of jumping beans as being larger, but I'm not quite sure what the distinction is.
Yes, the pattern does use PassObjectByValue?, but in particular it's passing an object by value in a context where many objects are distributed objects and hence are passed by reference. So there are connotations that it's almost a lightweight distributed object.
Example:
Consider an on-line TV store using proprietary client software. When the user opens a page to look at a particular model of TV, there are two things the system could do. It could represent each TV as a distributed object, and query separately for its price, an image, manufacturer logo, technical specs in separate RPCs. Or, it could retrieve the whole TV object in one hit, and have the parts ready to display as the user navigates. Obviously if the user goes back to the TV store later, they may not get the same price for the TV, so the TV object is not immutable in that sense. But within one session no details of the TV change, so it is immutable in that sense. The real point of the pattern is that massive efficiency gains can be made by transporting the whole object.
A TV is not a ValueObject. It's a BusinessObject (ReferenceObject) -- a real entity from your application domain (that may have values as attributes).
After some or all of a Jumping Bean object's state is copied to another system, you might use HalfObjectPlusProtocol or some kind of observer to keep the copies' states coordinated, or impose restrictions on changes, or allow the objects to get out of sync (...as you mentioned in the pattern).
I wonder if the pattern is losing focus by trying to cover different ways of synchronizing (and not synchronizing) state changes. -- JeffGrigg
I think to some extent the pattern sits beside HalfObjectPlusProtocol as an alternative, i.e. used when there are different forces. HOPP is useful when there is significant functionality required at both ends of the distributed object, and significant requirements to keep in sync. BOJB is useful when the functionality is required almost solely at the client, and there are no or minimal requirements to keep in sync. Both are variations on the RemoteProxy pattern. --JohnFarrell
I agree with whoever asserted above that it sounds similar to KyleBrown's DataTransferObject. I HaveThisPattern, and I call it DomainObjectStateHolder.
EditText of this page
(last edited January 26, 2005)
or FindPage with title or text search