Niklas Uhrberg wrote: > This is indeed a very interesting approach, I have thought about it > but sort of ruled it out as "too advanced" to happen in real life. > I hope I'm wrong...
Well, maybe it is. But what if we take the really hard parts (such as communicating over a network), and turn it into something really simple (creating messages locally). If the basic rules that application code deals with is dead simple it can be ok that the implementation of that is supercomplicated. > I note that the outset here seems to be "aggregates cooperating" > rather than agents/services operating on data. Yes, at least that's where we started. > A common scenario in the second approach is that the agent is > co-located with one set of data (read entities) during the first stage > of a computation, then in a second step the agent can change location to > a second set of data residing elsewhere. > The important thing is that the data being serialized is just the > representation of the result of the first step of the computation. > > This scenario (which is very useful for massive calculations in > multiple steps) seems to be a different one than a few aggregates > collaborating to perform some state changes, right? > > I think it's useful to contrast the two scenarios here. Ideally you > would like to address both. I agree. With aggregates talking to aggregates, that is mostly happening in the domain layer. As for the agent oriented approach, that is more related to the application layer of an application, which is basically stateless as it contains no entities, which can create "visitors" of aggregates in order to work on a collection of entities. If entities are spread out on many machines it definitely makes sense to think of the visitors as mobile agents, in the way you describe. There are many separate yet overlapping problems here, but it seems to me that many of them are becoming simpler to solve since we have the benefit of a solid base, and then great papers such as the Amazon one to help define what works and what doesn't. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
