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.
Cheers Niclas On Thu, Sep 11, 2008 at 7:28 AM, Rickard Öberg <[EMAIL PROTECTED]> wrote: > Hey, > > Here are a few thoughts on the research paper from Amazon on > infinite-scalability that Niclas referenced some time ago. I found it > very interesting, and have been thinking about how the ideas presented > in the paper could be implemented in Qi4j. > > First of all, terminology. What is called "entity" in the paper would be > an "aggregate entity" for us (an indivisible and fully locally "located" > thing), and what they call "object" is an entity or value object in Qi4j. > > It seems like a good idea to start with the basic assumptions. First of > all, assume that we are building an almost-infinitely scalable system. > This means a lot of entities in the system, partitioned over a set of > computers. Assume that locally communication almost always works and > services almost always complete requests (disk i/o is reliable etc.). > Assume also that network communication almost never works, and there is > no way to know if a call over the network will make it. > > From these assumptions the paper concludes that synchronous requests > can be made within an Aggregate without much error handling, and that > for one Aggregate to talk to another it must use asynchronous messaging. > To coordinate things each aggregate keeps track of what conversations it > is currently having with other Aggregates so as to manage resends and > response actions. > > In Qi4j the Activities concept could be implemented as a mixin on the > root Aggregate, which would have a > ManyAssociation<Qualifier<Entity,Conversation>> collection to keep track > of who it is currently talking to (see, Qualifiers are neat!). > > To send a message from one Aggregate to another we could use the > Messaging ideas already outlined, meaning, to send a message the > application code would create an EntityComposite which contains the > to-header and body (minimally), and the EntityStore would then trigger a > send of it to the recipient. > > In this case the to-header would simply be set to another Aggregate id > in the same system. The sending mechanism would send the Message Entity > to the server where the receiving Aggregate resides (which could be the > same machine, or on the other side of the planet), and there it would be > consumed by the Aggregate itself rather than some message processing > code, as outlined in the paper. Responses would be created and handled > in the same way. > > There's a whole lot to be said of how to implement this, for example > using RESTful ideas, but this is at least a rough outline of how the > ideas presented in the paper could map to our "world". I think it would > be very useful, and would provide a toolbox for people who want to > relatively easily create almost-infinitely scalable systems. What I like > about the model is that there is relatively little error handling going > on in the application code, since all operations are assumed to almost > always work (since both local calls and message creation is local). > > Thoughs and comments on this? > > /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
