Trinity Pattern

TrinityPattern is a pattern described in DesignPatternsForDistributedObjects. This page is presently a discussion page, and will become more formalised over time. The name will almost certainly be changed :-).

Intent

Build a BagOfJumpingBeans by implementing an interface in the server, in the proxy, and in the cache.

Description

Trinity is not a great name for this pattern, but it's an emotive word that is under-utilised in computing. I use it to mean a situation where three objects which look similar co-operate to implement a grand design.

---

It's the ContainerTriplets??

And the Observer pattern could be changed to Voyeur :-)

Yes the client application proxy interface and the server implementation interface are the same. But isn't this assumed in the MiddlewareWrapper pattern? Why implement an application proxy calling the CORBA proxy and a server stub (called from the CORBA server skeleton) if you're not going to make the remoting transparent to the client and server application code? Maybe the concept deserves a simple note in the MiddlewareWrapper pattern?

I get the impression that we're talking about a container interface, and we're caching content instances for performance reasons. So the point of this pattern is that the cache of objects is also a container, and can have the same interface as the container itself -- right? The "distribution" aspect doesn't seem to be a necessary part of this pattern, is it?

Without distribution, I think you can still get three identical interfaces:

1. The non-caching server implementation has the container interface.
2. The cache itself could have the same interface as the container.
3. Another object, used by the client, implements the container interface and manages the cache and the implementation objects listed above.

Personally, I'm not convinced that the hidden cache object should have the same interface as the other objects. Does it really need to support all operations needed by the client? -- JeffGrigg

---

Of all the patterns, this one has had the most support from the other developers on the project ("oh, if only we'd done this in the first place"), so I am sure it deserves more than a footnote. I am thinking about it to try to figure out the essential details.

--JohnFarrell

---

Perhaps it would help to focus on the caching aspect:

ConsistentCacheInterface?:

Forces: Fetching objects through OS service or remote interface is costly, so you wish to cache objects. What should be the interface to the cache?

Resolution: The cache should support the same interface as the costly object-producing service; the consistency will improve understanding and reduce training problems.

Does this help? -- JeffGrigg