Rickard Öberg wrote: > Niclas Hedhman wrote: > >> Yes, that is roughly a Qi4j picture of what he talks about. >> >> The real challenge is to find a decent way for "EndPoints" to be able >> to locate an Aggregate effectively. An extra network lookup sounds >> slow. Having a local copy of the location of all Aggregates sounds >> like a "sync" nightmare. Constructing Identities with location meaning >> sounds stupid. >> > > Can't we do it as in real-life? I keep a record of your phone nr, and > almost all the time that works. If I get a "this nr has been > discontinued" I look it up in the phonenr-catalogue, store it for future > use, and then call you. > > So, we only need a local copy of the locations of Aggregates that have > been used by local Aggregates. If we try to send a message to an > Aggregate and we get "wrong nr"(=404), then we look it up centrally to > get the new location, or even brute force iterate through all servers if > no central lookup exists. Even with the brute force method the server > being checked can say "it's not here, but I know from my record that > it's over here" (permanent redirect, 301), so the brute force check can > be fairly short. > > The local "address book" can be size-limited on a LRU basis too. > Assuming that not all Aggregates talk to all Aggregates, this should be > fine. > > This way Aggregates should be able to repartition at any time without > problems. > > Makes sense? > A slight variation inspired by the Jini lookup-cache and ServiceDiscoveryManager ( http://java.sun.com/products/jini/2.1/doc/api/net/jini/lookup/ServiceDiscoveryManager.html) is to maintain the aggregate locations continuously (or periodically to be exact) to minimize latency.
This will incur more network traffic just to ping aggregates or their "homes" but again, the nature of the application determines if this is worth the price. I would think that this scenario isn't very common but worth having in mind. The assumption here is that aggregates can change location, but this should be an exceptional case right? If we acknowledge the benefit of "shared nothing" architectures they should ideally talk to co-located aggregates only (knowing that this is far from realistic in many cases). /Niklas > /Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > > _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
