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.
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.
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.
- SplitTreeFromLeaves - has a more general form of this pattern, where "parts" of an object can jump between systems.
- HalfObjectPlusProtocol - static allocation of responsibilities between systems, assuming that some functionality of the object exists simultaneously on the different systems.
Is a Jumping Bean the same thing as a ValueObject
I don't think so, but it looks related to simple PassObjectByValue?
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
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.
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
) -- 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.
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
I agree with whoever asserted above that it sounds similar to KyleBrown
. I HaveThisPattern
, and I call it DomainObjectStateHolder