Niclas Hedhman wrote: > This article > http://www.infoq.com/news/2007/08/scalability-patterns > > leads to this > http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf
That was a truly great paper! Here are some random conclusions from it that I drew: * what I have been calling "Loading Policy" should probably be renamed "Usecase" and then include more information, such as the CAP (Consistency, Availability, Partitioning) settings for the Usecase. A UnitOfWork is something that *is occuring* wheres the Usecase would be the metainfo about what should hold every time a Usecase is executed (which includes LoadingPolicy information, but there's more than that) as a UoW. A UnitOfWork may or may not be associated with a Usecase (there's always a Usecase for a UnitOfWork though, but it may be a default one). This will make it easier to do some things such as rendering a list of info about some entities, since that Usecase can often be marked as "Not consistent, Available", i.e. it's ok for it to use old data (=can use cached data), but it must always be possible to do it. This could significantly improve performance in clustered situations. * We really need to defined Aggregates, which relates directly to what he says about entities (=Aggregates) being transaction boundaries. Having an Aggregate root Entity will make it easy to know how to manage UoW's and we can also let Entities in the Aggregate have fine-grained methods, since we will know that only the root is going to access them, locally. The Aggregate, however, exposes coarse-grained business methods, which will make it in effect encapsulate its inner state. If we use the key-suggestions, i.e. entities within an Aggregate has the root Entity key as prefix, it becomes easier to ensure that entities in an aggregate are all stored in the same place. Removing Aggregated Entities also becomes easy. When thinking about "size" this means that Aggregates are gerneally "big" and Entities are generally "small" (=it's ok to have lots of them). * How will his idea of messages and entities impact our ideas about Messaging? Should messages have Entities (or even more strictly, Aggregate roots) as senders/receivers? What he says about Activity (=keeping track of messages from different Entities) should be made into a mixin most likely that can be reused. * The discussion of alternate indices seems to really validate the idea of having query indexes as separate from the entities themselves! Meaning, an Aggregate root (=Entity in the paper) is existing within one machine, but an index may be spread out over the set of machines (="not existing within one single scope of serializability"). Here is the specific sentence about it: "The only logical alternative is to do a two step lookup. First, we lookup the alternate key and that yields the entity-key. Second, we access the entity using the entity- key." The text also validates the idea that secondary indices (RDF query in our case) may be temporarily out of sync (in the sub-second range moste often), so that queries may return results which are invalid. The rest of the paper is equally important. Everyone should read it! To conclude, I think taking heed of the the conclusions might make Qi4j one of the first "new middleware or platforms which provide automated management of these applications and eliminate the scaling challenges for applications developed within a stylized progamming paradigm". /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
