On 2011-01-23 22.56, Marc Grue wrote:
+1!!!
Are you planning to make more tests demonstrating how you manage
replay of events and the like? That would be really helpful to learn
from, although I'm now trying to see how you have done in
Streamflow.
Yeah, the longterm goal is to have local EventSource capture, then Atom
feed producer+consumer, and then replay. With that you can build any
type of replication infrastructure you want (master/slave, multimaster,
staging servers with production data, backups, etc.). I got the "REST In
Action" book which explains exactly how to do the Atom parts, so that
should be relatively easy.
I'm thinking of doing:
1) receive HandlingEventRegistrationAttempt via some web interface 2)
call @DomainEvent createdHandlingEvent(
HandlingEventRegistrationAttempt ) 3) have a listener to
(asynchronously) inspect the Cargo upon a HandlingEvent creation
event.
Does this sound reasonable as a better alternative than using JMS
messaging? (Or is it two different things? I'm new to both...)
Sounds reaonable, but would have to take a look at it more closely to
say for sure. The devil is in the details with domain stuff.
Is it correct that - from this approach - you would get the benefit
of creating the handling event independently of inspecting (and
updating the Delivery History) of the Cargo? In the DDDsample they
don't want to involve the bigger cargo aggregate everytime series of
Handling Events are registered. Maybe it's not even a problem in the
way Qi4j stores data? (now I'm on deep water).
I haven't looked at the domain, so I can't really say for sure. But in
general, the EventSourcing feature opens up for all sorts of
asynchronicity, in a relatively easy way, without having to go the JMS
route. I would say this is going to replace a lot of uses of JMS, and is
a much much simpler solution technically speaking, and a lot more
flexible as well due to it being webbased (proxies and scalability is
"built-in").
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
